Strangeness with Record Permission field
Where to begin...
We have a Manual Record Permission field Preparer in an Application that is configured as follows:
All Users - READ - YES
Record Creator - READ - YES, DEFAULT - YES
There are 2 Rules for this RP field:
Read Only based on Overall Status
READ - YES
Condition: IRA Status Contains IRA Pending Review, IRA Completed, IRA Cancelled, Due Diligence Pending
Update based on Overall Status
READ - YES
UPDATE - YES
Condition: IRA Status Contains IRA Pending Completion, IRA Pending Follow-up
For some reason, the user identified by this field is able to create a record and edit the record prior to first Save. After first Save, the Edit button is disabled and the user is unable to edit the record. The user is assigned only the General User role. They are not assigned to any other groups that might confuse their "actual" access. General User has CRU rights to this application.
I really believe this field is configured correctly. So what I'm trying find out is if there's another way that the Edit button can be disabled. I know Rules/Action can't disable the Edit button. We have no custom objects that would disable it.
I am totally at a loss. Other RP fields aren't working as well, even though they are configured identical to our Production version of this Application.
It sounds like they only have CR access to the application.
You might use the Access functionality to review the permissions of the user.
This should allow you to confirm the module permission and content permission. The Details may shed some light as well.
That also sounds to me like a calculation issue. Especially as after save the rules started to work.
Try to do the full manual recalc from the application and if does not help, change the order of the RP in the calculations.
Also, if these issues happened AFTER you had records and then did changes to the RP configs, then:
We experienced the same issue when an Apply Conditional Layout event is configured on a calculated field,to resolve this we updated the rule to evaluate the Calculated field containing "No Selection or Default value".
But the same technique is not applying to evaluate Manual record permission field.
@keith In your case may be you need to drive "Create a New record" differently.
-If its a child application record then you can disable "New Record" link from Navigation Menu and enable the "Add New" link in Parent Application on Conditional basis.
-Else,try with a custom object to hide Save, Save and Close Buttons when Tracking Id is Empty and Overall Status default value.
We can not check against Record Status field as it stays in "New" until at least VL is modified.
Let us know if you have any thoughts
I figured it out. This was caused by a record permissions field being higher in the Calculation order than the Calculated field that was used in the Record Permission Rule. I'm not sure why Archer doesn't automatically put Record Permission fields at the bottom of the Calculation order. Is there ever a situation where the Record Permissions should be calculated before the calculated fields?
Yeah, RP fields are considered as standard calculated fields from Archer point of view. Thus they are placed in the order of creation.
There could be some special cases when you need to manually control the RP calc order though. And for the better flexibility the order of the calculation is left on a user to decide. If all moves down to the bottom automatically, user will lose such freedom.