User Provider
The User Provider allows you to import and export user and user group data in a more straightforward manner than the Dynamicweb provider allows - this is achieved by abstracting a separation of users, addresses and groups at the provider level.
User data has been abstracted into these three virtual tables:
- AccessUserGroup contains user group data. A tree structure is defined by using the AccessGroupParentGroupName field. An empty node means the group is placed in the root of the tree, otherwise we match on AccessGroupGroupName
- AccessUser contains data on individual users. Mapping to groups is done on the field AccessUserGroups which in your import file should be a comma separated list of group names
- AccessUserAddress contains secondary addresses for users. Mapping to the individual user is done on the field AccessUserAddressUserID, which should be mapped to what you have selected as the key value (defaults to username). If for instance you have picked AccessUserExternalId as you key column, then this is the value you would use for column AccessUserAddressUserID.
- AccessUserSecondaryRelation is used for users who can impersonate. Mapping to the individual users is done on the fields AccessUserSecondaryRelationUserID and AccessUserSecondaryRelationSecondaryUserID which should contain either the user Id, username, customer number, or email.
Below, you will find information on using the User Provider as a source provider (i.e. when exporting user data) and as a destination provider (i.e. when importing user data).
Used as a source provider
When using the User Provider as the source provider, you will have access to only a few settings (Figure 2.1).
You can either limit the export to include only:
- Users created or edited since the last export
- Users created or edited after a particular point in time
If none of these are checked, all users will be exported.
Used as a destination provider
When used as a destination provider, you have access to much more extensive settings (Figure 3.1), which give you more control over the user data you import.
First of all you must specify a user key field, which is the field that will be used as the identifier for the record. It determines whether imported user data is created as a new user, or is used to update an existing user. If the e-mail address is unique in your dataset, you can select that column to be the primary key, and users that already exist with a given email in the database are updated instead of being added again.
Additionally, you can use the following options:
Option |
Description |
Interacts with |
Remove missing users |
When this option is ON, non-system users not in the source data are removed |
None |
Deactivate missing users | When this option is ON, all users which are not present in the source data are set to inactive (AccessUserActive = false) | |
Generate passwords for users |
Generates a password for imported users, provided that the user is new (not already in the Dynamicweb database) and the source data contains either no password or a NULL or empty string in the password column. |
None |
Encrypt passwords |
Encrypts passwords present in the source data, and passwords generated for new users using the Generate passwords for users option |
If Generate passwords for users is ON, they are also encrypted |
Remove users group membership, if group is not in import |
If Remove missing users is ON, and you import to a user group, users which are not in that user group will be removed |
Only used in conjunction with Remove missing users – otherwise ignored |
Remove missing groups |
Removes user groups not present in the source data |
None |
Remove missing impersonation rows | Removes impersonation rows not present in the source data | None |
Remove missing adresses | Removes adresses not present in the source data | None |
Remove missing rows after import in the destination tables only | Deletes rows not present in the import source - excluding related tables | |
Use email for username |
When this option is ON, newly imported users will use the value from AccessUserEmail as the AccessUserUserName.
Existing users will not have their user names updated, and will be updated only if the username field is empty. |
None |
Remove missing rows after import in the destination tables only | ||
Discard duplicate key rows |
When ON, duplicate rows are ignored |
None |
Use email for username | Assigns email adresses as usernames for all imported users. | |
Persist successful rows and skip failing rows | Checking this box allows the activity to do partial imports by skipping problematic records and keeping the succesful ones. |
You can use the destination group setting select a group to add the importes users to - check the Replace current group membership checkbox to force the imported users to only belong to the destination group(s) selected.
If you generate (and encrypt) passwords for new users on import, you can use the email configuration fields to set up automatic notifications to newly created users:
- Provide an email subject,
- Enter sender email
- Select or create an email template to use - you can use both Razor and html based templates.
In the Update index repositories field, you can select which lucene repositories you want to be updated by the integration activity. All repositories build in the Dynamicweb.Ecommerce.Indexing.ProductIndexBuilder are visible here. It is possible to select multiple repositories by shift-clicking them.
Which tables & columns?
The User Provider uses the AccessUser table, but abstracts this data into AccessUser and AccessUserGroup.
For the virtual tables the following restrictions apply:
- AccessUserGroup – Group names must be unique as the tree structure depends on name matching. Group names cannot contain commas as the group membership of a user is defined in a comma separated list
- AccessUser – Each user must have a unique value in a field - we recommend using unique usernames (AccessUserUserName)
Additionally, you can access addresses in the AccessUserAddress table and impersonation rules in the AccessUserSecondaryRelation table.
The user provider also supports import and export of SystemFields used by e.g. the Avalare tax provider - they are located in the SystemFieldValue table, with metadata in the SystemField table.
Relations between virtual tables should be handled manually by mapping the fields described in the introduction.
Automatic table sorting
When a job using the User provider as either source or destination is run, the table imports are automatically executed in the following order:
- AccessUserGroup
- AccessUser
- AccessUserAddress
- AccessUserSecondaryRelation
Any manually defined order different to this sequence will be overwritten to maintain proper data relations.