Hello World,
//Variables----------------------------------------------------------------
//If the edit is on DEFAULT we need to check the user groups
var p = Portal("https://xxxxxxxxxxxx/portal");
//Get the user full object
var u = getUser(p);
//Get the user groups
var groups = u.groups;
//Check if the user is in the correct group
var insuperusergroup = (Find("<NameOfTheGroup>",groups) > 0 );
// If value of Checkfield = Yes. Disable that this object can be edited,
var Akkoord = ($originalFeature.Checkfield == 'Ja');
//Action------------------------------------------------------------------
// If user is in: insuperusergroup: This Attribute Rule should do nothing.
if (insuperusergroup) {
return true }
// this attribute rule should check what the value of Checkfield is. no? the user must be able to modify the object. Yes? The user may no longer be able to change anything to this object, and will receive an error.
else {
if (!Akkoord) {
return true }
else {
return {"ErrorMessage":" Sorry! You cannot edited this object"}
}
}
The code is correct, but unfortunately it turns out to be a BUG.
When Person 'A' is logged in and triggers the AR, the system recognizes Person 'A' with associated rights. Unfortunately, it seems that person 'B' & 'C', (both logging in from their own IP / User account) can edit with the rights of person 'A'.
In other words, the trigger reacts once upon recognizing a profile and keeps it for others users to the same product. Only after resetting the service does the situation seem to have reset.
Bug has been reported to Esri. No solution is know yet (02-12-2021).
Hey Manniej, can you share the bug number? we can follow up if you are still running into this issue.
@HusseinNasser2 Thank you for your response. The case has been escalated, but to our knowledge it has not yet been resolved. It concerns: #02923240.
@HusseinNasser2 @Manniej Has this bug been resolved? I believe we are also running into the same behavior on Enterprise 11.3
This bug has been addressed under BUG-000154445 in 11.1 , and ported to 10.9.1 patch 5,
11.3 should have this fix. If you have a repro case on 11.3 it could be a different bug, I suggest submitting a case. msg me the case number so I can follow up
I submitted a case (#04136845). Support then gave me two other bug numbers:
https://support.esri.com/en-us/bug/attribute-rule-in-arcgis-pro-does-not-detect-the-portal-bug-00018...
(the second bug is not an issue in my case)
Thanks for the case number. I read the case details.
Can you try the following? it looks like you are assigning the group to the user while the service is running. After assigning the group, restart the feature service and try again and see if it fixes it.
Thank you. All tests I just did, are successful and gave the correct result.
I'm still a bit unsure about all this, because I am very sure I restarted the service yesterday as well. I did that to remove the lock on the feature class, to be able to change the attribute rule. I did that several times, because I thought the issue was in my attribute rule.
But maybe I didn't restart the service after removing users from groups and adding them to other groups.
Maybe I started the service, started testing and then made changes to users and groups, without restarting.
Hopefully just restarting the service after changing the assigned groups is the solution.
Thank you for our help.
Glad it worked.
The getUser, which returns the current user full json definition, is expensive. So we cache it in the SOC that serviced the edit. If you then made a change to the user details, assign a group, add a role, the cached entry is out of date. Restarting the service picks up the new definition, roles, and groups.
The reason that why it may worked sometimes without restarting the service, is if your new edit happened to land on a SOC process that didn't cache the getUser call, which will result in a fresh call to retrieve the new data.