User administration
Each web browser session can be associated with a single user by logging in. The method of logging in is arbitrary, although the standard behaviour is to secure the user with a password and log in via a web form.
Account membership
A user can be associated with any number of accounts. Account membership is partitioned into a set of relationships. The "member" relationship is used to collect together accounts that a web session can make use of to display account-specific pricing, or to place orders against. A single account from this set can be nominated as the default account; when a user logs in, their session will automatically use this account.
Other relationships can be added through system configuration, for use in custom functionality. For example, telesales employees may make use of a "sales rep" relationship that represents the list of accounts they have contact with.
Attribute data
User attribute data falls into one of three different types:
- simple strings — for example, the user's email address or name could be stored in the attributes "email" and "name" respectively.
- attribute sections — collections of strings that contain multiple properties (such as addresses). Each separate section can have its own value for a single attribute, e.g. "postcode".
- account-specific attributes — these attributes can have a different value for each account the user can apply to their session. A good example of this would be a company with multiple sales offices, each one having its own account on the system with a selection of delivery addresses. A user could choose a default delivery address for each account which could be used to pre-select delivery options on a new order.
All individual attribute values are input as simple strings, and so can conceivably store any text. It is possible to configure the system to validate the input, so that an attribute named "email" can only store valid email addresses.
<section name="users">
<section name="custom-sections">
<value name="Accounts">/admin/user-accounts</value>
</section>
<section name="attributes">
<!-- expected attributes will always be listed, with placeholders if necessary -->
<value name="expected">name,email</value>
<!-- other attributes will be selectable for addition, and will only be displayed if set -->
<value name="others">site,preferred-currency,category-set</value>
<!-- hidden attributes will not be displayed even if set
(used to hide specific data controlled by sources other than the administrator) -->
<value name="hidden">none</value>
<section name="validation">
<value name="email">email</value>
</section>
<section name="attribute-section-previews">
</section>
</section>
<section name="account-attributes">
<value name="others">default-address-id</value>
<value name="hidden">requisition-level</value>
</section>
<value name="account-relationships">rep,account admin</value>
</section>
Attachments
Attribute data can be preprocessed by implementation code and stored against the user in a custom object called an "attachment". Attachments can be used to provide different ways of looking at the data rather than its raw attribute form, which if provided from an external source may not be entirely human-readable. They can also cache the processed results, making them more efficient to use than a repeated calculation.
Using attachments means JTP templates do not need to contain complex, slightly opaque processing code and can instead just contain a meaningful property name, making them easier to maintain.
As attachments are custom code they cannot be modified through the administrator, but must be setup in the main system configuration.
User access control
While a user has a password, they can be used to log in. It is possible to disable a user in one of two ways.
- The user's password can be removed. This will stop the user from logging in, and can also be used to prevent them from using any "forgotten password" feature to restore their access. This technique should be used if someone is abusing the system and must be blocked.
- The user can be disabled entirely. This also prevents access, but also frees up the login so it can be re-used by someone else. This should be considered when a user wishes to leave the site, especially if their login name is not owned by them in the way an email address is. It can also be applied to any administrators who no longer require access; alternatively their administrator permissions can be revoked.
Note that neither of the above methods actually deletes the user from the database. The user object is referenced from other parts of the system — for example placed orders — and so must be kept even if it is no longer relevant.