Developer forum

Hi Scott

Just to understand: If Dave's RV logs in by him self, he can order, but if Jane Doe impersonates, she cannot create orders?

So it is kind of permissions on impersonation? So you almost impersonate the account?

BR Nicolai

Hi Nicolai,

We don't let people log into the Customer account directly. We don't give out the passwords and we throw an error if they attempt to do that. So, in the example above, only the Jane Doe Login has a useful username/password. 

So, if Jane Doe logs in, she will be presented with two choices of accounts to manage (Dave's RV and Mike's Camping World). She must select one (we also remember the last choice). For Mike's camping world, she can view prices and place orders, but for Dave's RV, she can only view prices. She can't place orders.

> So it is kind of permissions on impersonation? So you almost impersonate the account?

Yes, exactly, except that it's not 'almost' (or did you mean 'always'). Every login always impersonates an account. Neither a login or customer can be used by itself. 

Scott

Hi Scott

Gotcha.

So, would it not be possible to use a group permission on the users? Make Mike member of group "Placeorders" and Dave not...?

BR Nicolai

Hi Nicolai,

Yes, and I'll even create group membership from the settings in AccessUserSecondaryRelation. But, I prefer the property method because the data is so much easier to maintain and trust.

For example, let's say that you perform an update from integration from an ERP, you can confidently update a boolean flag and be certain that it's absolutely correct. But, group membership is more fragile because usually it's additive and it doesn't take care of removing stale group assignments. Users can often but in multiple groups for different reasons, like for permissions, or for organization, or for assortments, or other reasons, and I find that their state starts to drift if it's backed by integration mapping jobs. So, I end up storing the original values as a property so that the groups can be audited. So, this situation falls into the same. I prefer properties for integration, and groups as a bonus for when we want to use something in the platform that can benefit from being in a group.

I figure that using AccessUserSecondaryRelations is a nice many-to-many database structure to maintain permissions between a login and a customer user.

Scott

There are other scenarios besides permissions where it's useful to store data on the relationship. Consider, for example, buyers. A buyer is a single person in the real world that can order on behalf of multiple companies (customers of our customers) and as such exists as multiple contacts for different customers in the ERP. Then in Dynamicweb the user is created as a single login with impersonation rights for each associated customer. In a recent example we used the Email address to link the multiple records. In order to to send the original contact ID to the ERP when an order is placed, we need to be able to save it somewhere. Directly on the user doesn't work as it's a many to many relationship. The SecondaryRelation table is perfect for this. Here's a concrete example.

Imagine the following ERP data:

Customer 1 (Cust1)
  Imar (imar@buyer.com, ID: CT123 ==> AccessUserID 1)
  John (john@customer1.com, CT456 ==> AccessUserID 2)

Customer 2 (Cust2)
  Imar (imar@buyer.com, ID: CT987 ==> AccessUserID 1)
  Jane (Jane@customer2.com, CT222 ==> AccessUserID 3)

Notice how I exist as two contacts under the two companies but only as a single user in Dynamicweb because of the shared email address. When saving this in the AccessUserSecondaryRelation table you can store this today (ignoring the mapping to AccessUser IDs for the customers):

Note how my two contacts in the ERP () are collapsed into a single user with an ID of 1. At this point, I no longer have access to the original Contact ID. I could store them as comma separated fields on the user but then I still don't know which ID I should use when impersonating a customer. If I was able to store data in custom fields on the relationship itself, I can do this:

Now when my account (ID: 1) is impersonating customer 2, I can see that the associated Contact ID in the ERP is CT987. This in turn can drive pricing, delivery and what not. To me, this makes perfect sense as this Contact ID is part of the actual relationship between a contact and a customer, and differs for each relationship.

In this particular scenario, we also need to store the user's email address on the relation table to handle deltas and changes of the email address in the ERP. Happy to explain this further but it's a pretty advanced scenario.

We solved all of the above by directly extending the AccessUserSecondaryRelation table with additional fields and then using the Dynamicweb provider and tons of TableScripts. With custom fields supported out of the box in the User Provider, a lot of this would be a lot simpler.

Hope this helps,

Imar