Share via

BUG: @mention in comments for a list item changes permissions

matt howell 3,511 Reputation points
2023-08-31T21:58:35+00:00

If a user is @mentioned on an item in a folder with unique permissions, the original permissions are dislodged. Example:

Item is submitted to a list which can initially only be accessed by an admin group

The list has a folder with unique permissions which are edit and granted to UserA, and full control granted to admin group

Admin moves the item to the folder for UserA and normally this results in the item inheriting the folder permissions so UserA now has edit rights to the item.

But if admin @mentions UserB and moves the item to the folder for UserA, the item no longer inherits the folder permissions and item permissions are changed so that now UserB  has edit rights and UserA has "none"

This can't be the intended result of @mentioning someone. The only way it would make any kind of sense is if the intended permissions are respected and an @mentioned user is ADDED to the permissions. And even then, there should be a choice offered in the options panel that opens that lets you decide how permissions will be handled. Arbitrarily changing permissions with no notification to an admin is asinine.

Microsoft 365 and Office | SharePoint | For business | Other

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

4 answers

Sort by: Most helpful
  1. Anonymous
    2023-09-05T07:54:45+00:00

    Dear webbrewers,

    Thank you for the reply.

    Based on my test, you should move the item first before you @mention the user to meet your requirements.

    About this behavior, we do understand the inconvenience it caused for you. We recommend that you submit requirements for this feature in this SharePoint Feedback portal and many members who have the same requirement as you will vote for it in the future.

    Appreciate your understanding.

    Sincerely,

    Jazlyn | Microsoft Community Moderator

    Was this answer helpful?

    0 comments No comments
  2. matt howell 3,511 Reputation points
    2023-09-01T19:56:55+00:00

    And by the way, why does Msft assume if you @mention someone you want to give them edit access to the item? The default should be at most "read", and there should be an option to not give any access. How did this idea ever get approved at Msft?

    Was this answer helpful?

    0 comments No comments
  3. matt howell 3,511 Reputation points
    2023-09-01T14:12:17+00:00

    Ok, so the order that you do things has a different effect on permissions? What a strange idea - which no matter how hard we try to retrain users, will never be complied with. To simplify things, if I want the original permissions to remain intact except for the addition of the @mentioned user, I should move the item first?

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2023-09-01T07:16:05+00:00

    Dear webbrewers,

    Good day! Thank you for posting your query in our community.

    About your concern, I tested it on my side. Below are screenshots of my test results, and my understanding is: since @ a user for a item in a list, it will stop inheriting permission from its parent automatically and assign unique permission for this item.

    If you @ a user first, and then move to the folder, since this item already has its own unique permission, its permissions are independent, and even if it is moved to a different location with different permissions, it will not inherit the permissions of that location.

    If you move the item first, and then @ user, it will first inherit the parent permission of the new location, while under the "inherit the parent permission" situation. So when you @ a user, it will stop inheriting permissions based on the already inherited parent permissions, and then assign new permissions.

    Sincerely,

    Jazlyn | Microsoft Community Moderator

    Image

    @ first, and then move to the folder:ImageBefore @ user:

    Image

    After @ user:

    Image

    Was this answer helpful?

    0 comments No comments