Snapsection/code access to UI fields

Discussions related to custom development with Select.
Post Reply
ckootg
Posts: 122
Joined: Fri Jan 06, 2012 6:10 pm

Snapsection/code access to UI fields

Post by ckootg »

We locked down the contact fields to the end user. Permissions are as seen below.

Image
Image

In the past -- I'm going to guess.....as late as version 3.010520.1135 -- our snapsection code could add/edit/delete contacts and persons. Since version 3.010520.1150, it seems as if they has changed, where our code has to honor the permissions set above and can no longer add/edit/delete those objects. Can anyone confirm/deny this?

If this is true, is there any workaround to allow our snapsection code/custom code to add/edit/delete contacts/persons, but still lock it down for the end user?
BobRichards
Posts: 1376
Joined: Wed Jan 15, 2014 3:50 pm
Location: Raleigh, NC
Contact:

Re: Snapsection/code access to UI fields

Post by BobRichards »

Sorry but your images are not available to us. Could you please repost without using images?

Thanks.
Bob Richards, Senior Software Developer, SoftPro
ckootg
Posts: 122
Joined: Fri Jan 06, 2012 6:10 pm

Re: Snapsection/code access to UI fields

Post by ckootg »

The permissions are:

Code: Select all

Category: ProForm\Order\General\Order Contacts\Non-buyer/seller contacts

Permission                              Summary       User          Group
"Fee transfer ledger" field             None          Not granted   Not granted
"Include on revenue reports" field      None          Not granted   Not granted
"Lookup code" field                     None          Not granted   Not granted
"Reference #" field                     None          Not granted   Deny: Edit
All other fields                        None          Not granted   Not granted
Non-buyer/seller contacts               Add, Delete   Not granted   Grant: Add, Delete
Tax fields                              None          Not granted   Not granted

Category: ProForm\Order\General\Order Contacts\Non-buyer/seller contacts\People

Permission                              Summary       User          Group
"Lookup code" field                     None          Not granted   Not granted
All other fields                        None          Not granted   Not granted
Person                                  Delete, Edit  Not granted   Grant: Delete, Edit
And if I wasn't clear in the original post...
Previously, the custom snapsection code seem to have admin access to all fields.
Now, it looks as if the custom snapsection code has the same access/rights as the user.
Phil Barton
Posts: 54
Joined: Wed Sep 24, 2008 2:37 pm
Location: Raleigh, NC
Contact:

Re: Snapsection/code access to UI fields

Post by Phil Barton »

All permissions are enforced through the API and the business logic within the API using the current user as its context. Thus, whatever the permissions are for the current client-side user, that is what the API and business rules will enforce. Further, there does not exist an impersonation mechanism that will allow a client-side application, snap-section, or integration to set data on behalf of another user or different session other than the current. Therefore, the only way to set data that has permission-based guards it to either have the user belong to a group where that permission is granted or to grant the permission directly to the user.
Phil Barton
Software Architect
SoftPro
mlevi
Posts: 53
Joined: Mon Dec 01, 2014 2:33 pm

Re: Snapsection/code access to UI fields

Post by mlevi »

Is this possible through custom order rules or the server side package?
mlevi
Posts: 53
Joined: Mon Dec 01, 2014 2:33 pm

Re: Snapsection/code access to UI fields

Post by mlevi »

Or has anything changed in the API in the past few years?
Phil Barton
Posts: 54
Joined: Wed Sep 24, 2008 2:37 pm
Location: Raleigh, NC
Contact:

Re: Snapsection/code access to UI fields

Post by Phil Barton »

Nothing has changed regarding the API in the past few years, other than what is documented in the release notes. A server-side package may not give you what you want because any remote call will run under the context of the user making the call. A server-side job would run under the context of the server and may be able to modify the value. Additionally, an automation process may be able to change the value. A custom rule may work, too. However, you would have to know which aspect of the property (i.e. ReadOnly, Locked, etc.) to modify.

However, I must say that these practices should have a thorough discussion of the implications (both technological and business). For example, using a job or an automation process will create a loss of accountability. The order history will only say that "System" or "Automation" made the change(s) to the order. If a custom order rule is created, that effectively overrides the underlying business logic. This is then baked into every order that is created with that rule. If there is a bug in the custom rule, those orders created with that rule will have that bug ad infinitum. Further, if the rule is written in an inefficient way (e.g. making server-side requests during execution), it could introduce performance degradation. So, as parting advice, I would just say: Look hard at the business case for what it is you're trying to accomplish and test thoroughly! :)
Phil Barton
Software Architect
SoftPro
mlevi
Posts: 53
Joined: Mon Dec 01, 2014 2:33 pm

Re: Snapsection/code access to UI fields

Post by mlevi »

On Overlay Order Functionality does SoftPro take into account user permissions when overlaying contacts?
We are noticing that the overlay order functionality can create/edit contacts where as the API is not allowing our code to do it due to permissions settings on the user.
mlevi
Posts: 53
Joined: Mon Dec 01, 2014 2:33 pm

Re: Snapsection/code access to UI fields

Post by mlevi »

I have an additional question:
The only permissions we have given most of our users is to edit the LookupCode field and add contacts.
Most Contacts populate properly when we create them via the API on the shell package with these permissions
The one contact type that is giving us problems is the "Other" Contact.
I noticed that via the API you need to first Create the Other Contact and then give it a type. Only after that you can add the LookupCode and its information populates properly.
Like this:
IList contacts = this._order["Contacts"] as IList;
IOrderItem contact = this._order.CreateNew("Other");
contacts.Add(contact);
contact.SetValue("OtherType","Flipper");
contact.SetValue("LookupCode", "FLIPPER");

But it only populates in properly when i have full permissions to edit all fields on All Contacts (That are not Buyer/Seller).
But because we want to lock down permissions for most of our users.
If i try to fill in Other Type on the Other Contact - i get an Member Access Denied message because this field is locked down and the only field i have access to is the LookupCode.
What is interesting is that if you try populating the "Other" contact from the UI on the contacts screen, you can choose a LookupCode and that is all you need - it populates properly. From the API you first need to add in the Other Type. Why is this?
Is there a workaround we can do and still keep our permissions in place?
Post Reply