Snapsection/code access to UI fields
Snapsection/code access to UI fields
We locked down the contact fields to the end user. Permissions are as seen below.
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?
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?
-
- Posts: 1376
- Joined: Wed Jan 15, 2014 3:50 pm
- Location: Raleigh, NC
- Contact:
Re: Snapsection/code access to UI fields
Sorry but your images are not available to us. Could you please repost without using images?
Thanks.
Thanks.
Bob Richards, Senior Software Developer, SoftPro
Re: Snapsection/code access to UI fields
The permissions are:
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.
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
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.
-
- Posts: 54
- Joined: Wed Sep 24, 2008 2:37 pm
- Location: Raleigh, NC
- Contact:
Re: Snapsection/code access to UI fields
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
Software Architect
SoftPro
Re: Snapsection/code access to UI fields
Is this possible through custom order rules or the server side package?
Re: Snapsection/code access to UI fields
Or has anything changed in the API in the past few years?
-
- Posts: 54
- Joined: Wed Sep 24, 2008 2:37 pm
- Location: Raleigh, NC
- Contact:
Re: Snapsection/code access to UI fields
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!
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
Software Architect
SoftPro
Re: Snapsection/code access to UI fields
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.
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.
Re: Snapsection/code access to UI fields
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?
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?