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). This gives you more control of 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:
- Check Remove missing users to delete non-system users not present in the imported dataset
- Check Do not remove a user from Newsletter/Recipient group to exempt users who are members of that group from deletion
- Check Only delete users from groups that are imported to if you want to be able to import and update select groups without deleting everyone else.
- Check Generate passwords for users to generate a password for an imported user. The generated password will be used if:
- The user is being imported for the first time, and no mapping for the password column is set
- The user is being imported for the first time, and there is a mapping, and the input is either NULL or "" (empty string)
- The user is being updated, and there is a mapping for the password, and the input is either NULL or "" (empty string)
- Check encrypt passwords to make newly generated passwords encrypted
- Check Remove missing groups to delete any non-system groups not present in the imported dataset.
- Check use email for username to, well, have the username field set to the same value as the email address field
- Select a specific destination group to add your dataset to
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. Specify a subject, a sender email and select or create an email template to use.
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.
Relations between virtual tables should be handled manually by mapping the fields described in the introduction.