Skip to main content
Solved

ROLE: VIEW ONLY Access on Screen/Form allows ACTIONs to process

  • 20 October 2022
  • 1 reply
  • 480 views

 

User Is set to View ONLY Access for Several Workspaces but still is able to Perform Actions on a Item

Use Case: 

Set ROLE Access for a Screen/Form to ‘View Only’ Ex: Purchases Orders 

from ‘Access Right by Role” 

 

It is assumed that for Purchase Orders this ROLE/USER can only VIEW PO’s but not Edit them.

By default all FIELDS and ACTIONs within the FORM are set to INHERITED. 

 

However, the ACTIONs on the PO are still Available and can be utilized: for example, an open PO can Receipted or be Put on HOLD.  Since this is VIEW ONLY access shouldn’t ACTIONS also be VIEW ONLY? And this inadvertently gives ACTIONABLE / EDIT access to user that should be VIEW ONLY.
 

This is a security Flaw and Has been caught in client Compliance AUDITs 

The only way I’ve been able to counter this is at the FORM Access Level is to REVOKE the ACTION ITEMS

 

Is there any way around this?   Shouldn’t VIEW ONLY apply to ACTIONs as view only also? 

IS this a BUG?   Shouldn't this be fixed?   

 

NOTE: This applies to ALL FORMS Access across all Workspaces. 

Best answer by bobstephens42

NEW RELATED ISSUE:   By setting REVOKE on the Action Items on the ROLE that was supposed to be View Only, I caused another issue. A different user assigned to the View Only role with the Revoked Actions, also was assigned another ROLE where same screen (in this case Purchase Orders) was set to DELETE.  However, since REVOKE was “hardcoded” on one role and DELETE was Inherited on the other role, the USERs access or those Action items was REVOKEd.   Note: in the ‘Access Roles by User’ form the Action Items show as DELETE.   BUT in this case REVOKE is overriding Inherited DELETE access.   The work around was in the DELETE inherited role to HARDCODE/Force the Action items to be DELETE instead of INHERITED.  Interestingly enough I selected DELETE but they changed to EDIT when I hit save.  That hardcoded selection resolved the issue.  

View original
Did this topic help you find an answer to your question?

NEW RELATED ISSUE:   By setting REVOKE on the Action Items on the ROLE that was supposed to be View Only, I caused another issue. A different user assigned to the View Only role with the Revoked Actions, also was assigned another ROLE where same screen (in this case Purchase Orders) was set to DELETE.  However, since REVOKE was “hardcoded” on one role and DELETE was Inherited on the other role, the USERs access or those Action items was REVOKEd.   Note: in the ‘Access Roles by User’ form the Action Items show as DELETE.   BUT in this case REVOKE is overriding Inherited DELETE access.   The work around was in the DELETE inherited role to HARDCODE/Force the Action items to be DELETE instead of INHERITED.  Interestingly enough I selected DELETE but they changed to EDIT when I hit save.  That hardcoded selection resolved the issue.  


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings