User can remove (repo admin or any user) permission in Sharing tab on work #3166
Closed
4 tasks done
Comments
|
@vantuyls @chrisdaaz @no-reply ping! |
|
Also, I just tested adding an editor to the work, then revoking the editor and that worked as expected. |
julesies
changed the title
|
@julesies would removing this row from the "Currently Shared With" table satisfy the issue?
i believe admins should always have edit access to all works in the repository. it doesn't seem useful to show the user that admins have edit access to the work they deposited, let alone showing them options to edit or revoke that access. |
|
yeah agree it seems odd to display admin access on the work view but it does go beyond admins. We have 3 groups from using role mapper, for example and the user can "remove" any user or group who has access granted to them another way. Since currently the only way to remove an individual users listed on the admin set is by visiting each work, I'm thinking you would have to show that to managers, admins, (or what ever group has the right to edit permissions on works). here is an example: (tab bug reported here #3175)
|
|
could we add this to the issue? @julesies Done looks like
|
|
yes, but add something like only show those groups to admins, managers, editors? and change to groups and individuals from admin sets or collections. (this seems right, what do you think) |
|
@julesies okay, i added that stuff to the issue to make it more actionable, but i hope it's not too complicated. take a look and add any clarifications if necessary. |
|
After talking with @julesies my understanding is
|
|
While working on this issue, it became apparent that this change as requested could be very confusing and misleading to a work's editor. A work can be in more than one collection, and if so, we wouldn't know which collection affected the permissions, because we don't track that. And permission changes on a collection don't carry through to a work, at least not at this point. So the tie between the collection and the work's permissions is tenuous at best. Admin set permissions always carry through to the work when it is created. Collection permissions only do if you create a new work from the button off of the collection's show view. Creating a work and adding it to a collection while you create it does not change permissions, nor does adding an existing work to a collection. So a work could have been created, and the depositor/editor could have given it permissions that they can now not change because it just happens to be the same permissions as the collection had. They also could add or attempt to add a permission which would appear to not be working because that permission is also on the collection or admin set. I would recommend showing all permissions but limiting the edit and delete access to them, and optionally showing something to identify the collection which is limiting the ability to change those permissions. So the changes I intend to implement to the work's permissions view are:
(note: An editor could still change these rights by removing the work from the collection, removing the rights, and adding it back to the collection, because the inheritance of permissions only happens during the work's creation.) @julesies Does this sound like what we discussed as the best option? |
laritakr
pushed a commit
that referenced
this issue
Sep 13, 2018
#3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. The shared partial, `currently_shared.html.erb` embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays.
laritakr
pushed a commit
that referenced
this issue
Sep 13, 2018
#3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. The shared partial, `currently_shared.html.erb` embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays.
jeremyf
pushed a commit
that referenced
this issue
Sep 3, 2020
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Oct 7, 2020
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
|
@jeremyf It looks like this is still happening and it seems like good changes to make to clarify that Sharing view and prevent that action of removing permission when you can’t actually remove that permission. How aged is @laritakr's code changes? Is this something that is feasible to include in Hyrax 3.0 release? I don't know that it is worth adding to the list of things for Hyrax 3.0 if it extends the timeline for the release. Would it work better as a Hyrax 3.1 change to incorporate? |
jeremyf
pushed a commit
that referenced
this issue
Oct 12, 2020
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Oct 12, 2020
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
jeremyf
pushed a commit
that referenced
this issue
Jan 25, 2021
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Jan 25, 2021
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
jeremyf
pushed a commit
that referenced
this issue
Feb 2, 2021
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Feb 2, 2021
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
jeremyf
pushed a commit
that referenced
this issue
Feb 3, 2021
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Feb 3, 2021
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
jeremyf
pushed a commit
that referenced
this issue
Feb 5, 2021
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Feb 5, 2021
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
jeremyf
pushed a commit
that referenced
this issue
Feb 23, 2021
Fixes #3166 - user is permitted to update any work permissions coming from collections they manage - user is permitted to update non-manager permissions from any Collections - user is permitted to update any non-collection permissions Process used: - find all of the work's collections a user can manage - find all of the work's collections a user cannot manage - find all of the other managers of collections a user can manage - find all of the other managers of collections a user cannot manage who are not also managers in collections that the user CAN manage. This gives us the permissions the user is not authorized to update. EditPermissionsService embeds all of the above logic and uses it to display all of the work or file set's permissions in either a fixed or editable format. The new shared partial results in a slight reformat of the display of these permissions, as there were previously minor differences between the two displays. Additionally, a new partial was created for batch edit, as the above rules cannot be enforced at a batch level. Dealing with batch editing sharing issues is beyond the scope of this issue. Restrict user from changing managers which are in both authorized & unauthorized collections
jeremyf
added a commit
that referenced
this issue
Feb 23, 2021
Given we are expecting a specific hash structure, favor `fetch` over `[]` access. This prevents a null-pointer. Also, re-arrange the operands for the boolean test. The `permission_hash.fetch(:access)` is cheaper/quicker than the other include test. This is a small tweak that helps conserve a bit of computation. I believe it is important to capture some of @laritakr's intentions. While this may not be the correct commit to associate, it's close to the work. Larita had the [following comment][1]: > While working on this issue, it became apparent that this change as > requested could be very confusing and misleading to a work's editor. > > A work can be in more than one collection, and if so, we wouldn't know > which collection affected the permissions, because we don't track > that. And permission changes on a collection don't carry through to a > work, at least not at this point. So the tie between the collection and > the work's permissions is tenuous at best. > > Admin set permissions always carry through to the work when it is > created. Collection permissions only do if you create a new work from > the button off of the collection's show view. Creating a work and adding > it to a collection while you create it does not change permissions, nor > does adding an existing work to a collection. > > So a work could have been created, and the depositor/editor could have > given it permissions that they can now not change because it just > happens to be the same permissions as the collection had. They also > could add or attempt to add a permission which would appear to not be > working because that permission is also on the collection or admin set. > > I would recommend showing all permissions but limiting the edit and > delete access to them, and optionally showing something to identify the > collection which is limiting the ability to change those permissions. > > So the changes I intend to implement to the work's permissions view are: > > - No one can view admin permissions on the work, because they should > always exist and we don't want to allow them to be edited > - no one can edit a work's permissions which inherit from the manager > role of a collection/admin set unless they are also a manager of that > collection/admin set. these permissions will show on the work but not be > editable, and the collection which causes them to be frozen from change > will be identified > - other permissions may be edited on the work by anyone with edit rights > > (note: An editor could still change these rights by removing the work > from the collection, removing the rights, and adding it back to the > collection, because the inheritance of permissions only happens during > the work's creation.) [1]:#3166 (comment)
dlpierce
added a commit
that referenced
this issue
Mar 1, 2021
…ions_from_update Lock unauthorized permissions from update
|
Tested locally and regular user can no longer remove (or see) admin access and repo-admin user can still see the regular user's work and make edits. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Descriptive summary
Hyrax 2.1. We are testing permissions for our go live of hyrax and came across this bug which I confirmed on nurax today.
A user/depositor can remove any person/role via the Sharing tab in the UI including the repo admin. We tested adding a work and having the depositor remove access to the repo admin, which was allowed. The repo admin could still access the work and edit it, but on visiting the sharing tab, the role was not visible.
Expected behavior
depositor can only see, remove roles/permissions that they added. permissions that are removed, are actually removed.
Steps to reproduce the behavior
Done looks like
adminand any groups that exist as participants in the work's admin set or collectionadminand all users and groups that have edit access to the work (for example, if User A is listed as a Manager of a collection, User A can go to any work in that collect, clickEdit, view theSharingtab, and see a table that lists all users and groups that have edit access to that work and act according to the settings of the admin set or collection containing that work).The text was updated successfully, but these errors were encountered: