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).

When using the User Provider as the source provider, you will have access to only a few settings (Figure 2.1). 

Figure 2.1 When used as a source provider, these are the settings available to you

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.

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.

Figure 3.1 When used as a destination provider you have more options available to you

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.

If the user is already in the database and has NULL or an empty string as a password, a password will also be generated.

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. 

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.

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.