Lock unauthorized permissions from update

[laritakr]

Fixes #3166

Allowed permission maintenance:

• 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.

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.

@samvera/hyrax-code-reviewers

[stale]

This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs within 14 days. Thank you for your contributions.

[cjcolvar]

@laritakr Is this ready for review?

[laritakr]

It was complete, but there was some question whether the behavior I put in was actually wanted after all. I assumed the PR was dead.

Before merging this, be sure to discuss it with @no-reply

[cjcolvar]

Thanks for the background. I know you spent a lot of effort on this and no one had reviewed it before stale-bot closed it so I brought it up during the weekly PR review time and we couldn't remember if it was considered done or not. I'll try to get a review in soon but I'll talk with @no-reply about timeline if it should be a part of 3.0 or post-3.0.

[laritakr]

I think the problem is that there wasn't consensus whether the change in behavior is desired. The assigning of permissions via admin sets and collections does not apply permissions beyond initial creation of the collection, and there isn't consensus on whether this should be changed.

It is more than just an issue of timing, so I gave up on trying to get it reviewed.

[stale]

This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs within 14 days. Thank you for your contributions.

[no-reply]

bumping this since it's assigned to me.

[stale]

This issue has been automatically marked as stale because it has not had activity for 30 days. It will be closed if no further activity occurs within 14 days. Thank you for your contributions.