Rattail of course includes the concept of a “user” account. In general the purpose this serves is 2-fold:
restrict access to certain parts of the app
provide attribution, e.g. “who did what (and when)”
Rattail has a User table, which contains the basic account record. It is quite minimal but a User can relate to a Person, and then indirectly a Customer etc.
User records then are associated to a great many other things, e.g. when a user creates a new batch, their user account is associated with that batch.
User accounts do not themselves, directly, have “permission” to do anything. But a User may belong to zero or more Roles, which then grant it permission to do things. (Even if zero, the special “Authenticated” role may automatically grant some permissions; more on that below.)
Authentication (aka. Login)¶
Normally each person who “logs in” to Rattail must already have a User account. The login succeeds if they supply correct username and password, both of which are stored in the User account (with the password being encrypted).
Additionally, the User account may be marked “inactive” by the admin; if so then login will not be allowed for that user.
Customization is possible, for instance to check credentials against Active Directory or your POS system etc. User accounts may even be auto-created on first login etc.
Syncing Users & Roles¶
Users and roles are closely related, but how (and/or whether) they are synced across app nodes, is handled differently.
By default all users are synced across all nodes; simple as that.
But only the user proper is synced, and not the roles they belong to (see next section for that).
When making a new user account it’s possible to mark it as “local only” - which causes it to not be synced to other nodes. It should exist only in the node where it was created.
By default no roles are synced across nodes; each is “local only” effectively.
However you can mark a role as “synced” - which will cause it to be synced across all nodes. There are two flags you can set:
“Sync Attrs & Perms” is the flag you would set in order to cause the role to be synced at all, in the first place. As the name implies this will sync the role proper as well as its permission list.
“Sync Users” is the flag to set if you want the role’s user list to be synced as well.
Role names must be unique within each system. If you have 2 nodes and they each have e.g. a “Manager” role defined (separately), and then you turn on sync for one of them, there will be an error.
Instead rename the one you don’t want to keep, then turn on sync for the one you do.
In a multi-node system it is likely that there are different “types” of nodes. In such a system it may be useful to sync certain roles, but have them only “apply” to certain node types. (The roles must exist in all nodes for sync to work properly, but need only apply to certain nodes.)
The main use case here is in a multi-store setup, where you have one “host” node and two or more “store” nodes. You can create a role with node type of “store” and flag it for sync. The role will be synced to all nodes, but will only be actually used on the store nodes.