Open MegaKeegMan opened 5 months ago
The story described in this issue is actually already met, I have just discovered. However, I found that while a user that does not belong to a group cannot associate that group with content, they are able to remove the group from the association. I suspect that they should not be able to remove access from groups that they do not belong to? In which case, do we need to hide those values, and somehow indicate that they exist? Or do we want to keep those group's displayed, despite that they appear in the listing as "Restricted access". Another option would be to disable the "Remove" button. It is a bit awkward though to be unable to remove groups that you don't belong to—just about as awkward as it is to be able to remove a group without being able to distinguish it.
Technically, it seems that someone who does not belong to that group could give that group access to nodes simply by copying the string in that field. In fact, I was able to just enter 1 (8)
and save the form, since the field value basically just needs to contain the taxonomy term id in parens. I wonder if there is a better way to format this field.
Checkboxes will not work. If someone who does not belong to several groups that have been associated with the node by someone else attempts to save the node, those associations are broken, since those values do not exist in the field anymore.
In order to associate content with a group, a contributor must be a member of that group. At the time of writing, any groups are available for selection in the groups with view access field.