You are not authorised to move this entity
Hi all,
I am receiving an error with one of the numbered lists - "You are not authorised to move this entity".
ONLY non- workspace admins are getting this error.
They are able to add items to the list but they cannot put the Parent against the Parent field.
I have checked the action and the Parent field is being correctly mapped in the action - as mentioned in this thread.
The user has access to the source module view and is able to see the data that is being used for Parent mapping. The user also has access to the list in Roles -> List section and the Roles-> Actions section for the action being run.
Also, this numbered list has a parent/child relationship and the top ancestor list in this chain has selective access. The user has Total Company access WRITE access to this ancestor (Top level element) list.
Can anyone identify the issue if they have seen this before?
Answers
-
Is the parent that is being mapped a new parent that is being created or an already existing one?
Have you tried to split the multiple actions in one process into more smaller processes?
Thanks,
Usman
0 -
It is likely to be something to do with selective access on the Parent, but the best bet here is to log a support call so they can look into the specifics
If you get an answer, could you post the resolution/reason here?
David
0 -
I think this error is being caused because non-workspace admins cannot create orphans in the list. Basically the last action in your process is creating members in the list which do not have a parent assigned to it
Can you please check if the members being added to the numbered list which are causing errors have the valid parent correctly mapped
Regards,
Anirudh
1 -
Hi @anirudh,
The non-workspace admins are able to create list items using the last action in the screenshot (i.e. orphans are being created). However, the orphans are supposed to land under their parent as part of the same action which is not happening. The parent does exist and we are using CODE of the parent for the mapping in this child list action.
Like I said, I being a workspace admin can put the parent in the parent field (using the action) however when a user runs the same action, the action creates list items but doesn't fold into the parent.
0 -
Hi @usman.zia
I have actually tried removing the process all together and let the user run that single action from a dashboard button.
It still leads to the same error.
I gave the user FULL ACCESS instead of the role and it still doesn't work.
Only Workspace admins can perform it (Full Access or Role Access both).
0 -
Try this, with the same access as the user (so take your WSA off), go to the module, open the view and see if the parent is supplied in the line item. If it is, then you most likely have a security issue where the WSA has access but the users don't. If the parent is not defined in the line item, then you have could have a different security issue at the module level or Selective Access like David stated above.
Hope this helps,
Rob
0 -
Thanks for the comment.
I have tried this as well. I opened the module/view on the user's account to see if they are seeing data in all the line items needed. He was able to see all that's needed to fold the list.
0 -
Ok, now that you know the information is correct, look under Users and go to the Roles-> List tab and see if their role is checked for that list. Lastly, any Selective Access on the list?
Rob
0 -
Hi,
Yes, they have all the Roles-> List, Roles-> Module access.
In fact, it doesn't even work with him having FULL ACCESS.
It has something to do with Workspace Admin OR Single Sign On. These two are the only things that are different between the user and myself.
0 -
@shreyak.gargIf I'm understanding you correctly; you have a numbered list with selective access enabled. There are also orphans in the numbered list. The action which is causing errors is mapping parents to these orphans.
Anaplan correctly denies access to orphans in a list with selective access enabled to non-WSA users. This is why the action is causing the error.
I suggest either mapping the parent in the same action that is currently creating the orphans. Or alternatively, the orphans being created currently should be mapped to a temporary dummy parent. This will allow all users access to the orphans and the last action should successfully remap the 'orphan' to the desired parent
Hope this helps!
Regards,
Anirudh
4 -
Hey Shreyak
Is this happening to ALL elements that are needing a parent reassignment, or only specific items? Could you create a view with a single record that has the issue and test it?
Also, have you tried turning off selective access altogether and tested it?
1 -
Hi Adam,
Is this happening to ALL elements that are needing a parent reassignment, or only specific items?
Yes, all of the ~1100 list items get created as orphans, with their properties populated correctly except for the PARENT field.
Could you create a view with a single record that has the issue and test it?
Yes, this could be tested. We did test with a new view and action (with all items) and it didn't work.
Also, have you tried turning off selective access altogether and tested it?
Selective access is at one of the ancestor lists - #Project (very high level). We didn't remove the selective access at the Project level.
0 -
Hi all,
I am getting the same error.
I have four hierarchical lists with the top list having selective access.
I am trying to import the list from a module as a non WSA. I have set the role to full access and given write access to top level item of the parent list.
When i run the process the first list(top parent) gets imported. However the next 3 subsequent lists throw an error "You are not authorized to move this entity".
The action used to import the child lists have parents mapped to them in the same action.
But still i am getting the same error for all the next 3 lists(child lists)
Thanks in advance
0 -
Hi Preethi,
The steps you have mentioned look identical to the issue we had.
To my knowledge, it is still an unresolved issue. I will confirm with the support team if there has been further progress.
0 -
@shreyak.garg We too are facing the same issue. Just to further shortlist the two differences between you and the user - in our case both the user and the WA have SSO enabled. So, essentially, everything else being equal - being WA seems to resolve this issue.
Please do update this thread in case you happen to find the cause/solution.0 -
@prakashnishtala - We had tried to check with both SSO and non-SSO for the WA whereas the user was always SSO enabled. The error still persisted.
This was for a client and I don't think it has been resolved yet.0 -
@shreyak.garg Revisiting this thread to check if you were able to get any solution for this. It is still an issue for us as of now.
0 -
Hi Prakash,
Is it possible that the user running the action does not have access to the parent that the child is currently at.
Example here:
The user I'm testing with does not have access to P3, the parent of C6 and is also not a WSA
When this user runs an action to update the parent of C6 as below he will receive the "Unauthorized to move this entity" error
The difference between my original answer and this is that the problem child is not because it is an orphan but because it is currently mapped to a parent which the user cannot access. When the user tries to remap any child to any other parent, irrespective of whether he has access to the destination parent, he will be unauthorized to make the change.
Regards,
Anirudh
0 -
Hey all,
I just helped a customer dealing with this same issue, so I figured I would give a general overview of what is happening in this situation. Hopefully this resolves all current and future questions people have.
There are two main factors at play in this situation:
1. Why it does not happen to Workspace Admins:
During an import, Workspace Admins have a special ability to affectively 'ignore' Selective Access on the target. This is intended - there are situations in which a Workspace Admin should have limited view access (with sensitive data like HR salary information) however the base data still needs to be imported. A user does not have this ability, so in general if they try to import items without the correct Selective Access, those items will fail.
2. What is happening that causes this error for Users:
This error and ones like it are completely caused by List level Selective Access. As a test, if you remove Selective Access from all lists in your model then have the user attempt the action, they will be guaranteed to not see this error. But obviously Selective Access is necessary, so here is how to understand what is happening:
This error can occur when creating a new item or modifying existing ones:
A. "You are not authorised to move item to parent: <X>" - when the Parent specified for the parent is one that the user does not have Selective Access to.These errors only occur when the item already exists:
B. "You are not authorised to update this entity" - when they do not have Selective Access to the existing item and are trying to change something other than Parent.
C. "You are not authorised to move this entity" (the one in question in this post) - when they do not have Selective Access to the existing item and are trying to change the Parent value.The lack of Selective Access described here can be caused by not having access to the item itself, or the item's parent, or if the item has no parent.
Even though we cannot obtain the same error exactly as a Workspace Admin (due to reason #1), we can still troubleshoot - set your Selective Access to be the same as the User, and view the list dimension somewhere in a module or dashboard (NOT in the settings area, as this will display all items regardless of Selective Access). You will not be able to see whatever item or parent the user is attempting to update. That is the root cause of the issue - figure out how to either A. give access to the appropriate item, or B. not include that item in the users import.
One thing to note: The last two errors cannot occur when creating a new item. If you thought that the item did not exist or had been deleted or something but the non Admin user is receiving this error, then go to the settings area and search the list for that item - what is most likely is that the item still exists and has become an orphan item because the parent was deleted. They are displayed at the very bottom of the item list, and do not role up to the 'Top Level' item. If Selective Access is in place then end users will not be able to modify records that do not have Parents in a hierarchy, causing the error. In this case, it may be good to have an automated 'Delete from List' action that removes any objects that do not have parents or something similar.
As a summary - the error message is not an Anaplan bug but intended behavior when Users try to update or move items to which they do not have Selective Access. A Workspace Admin will not see this error because they have an intended exception to standard access rules when running imports into lists with Selective Access.
That should help clarify this issue for others encountering it. If you are still encountering issues or confusion with this error, please open an Anaplan support ticket and include a link to this article/comment as reference.
9 -
We have a situation where we ended up in the same point as in your last comment - after going through all the steps mentioned above, everything seems to be mapped correctly and the only difference between users getting the error or not is the workspace admin selection.
Is there another reason that you were able to identify in your process?
Thank you!
Madalina
0
