Open MegaKeegMan opened 10 months ago
MegaKeegMan
commented
9 months ago commit 382fd3b enables giving view/edit access to a group. In particular, the fields are "Users with edit access" and "Users with view access", which is mostly accurate, except for the fact that the "Users with edit access" field also gives view access. So I guess the question is whether the fields should have different names, or which kind of access each field should actually give.
MegaKeegMan
commented
9 months ago Also noting, that currently "View published node" permission is given to all roles, which should probably be undone. Without removing this permission from some roles, the "Group visibility" field does not do anything (as it is meant to determine whether a group should be public or private)
MegaKeegMan
commented
9 months ago Additionally, it looks like using access_by_ref requires that you remove the "view published nodes" permission from authenticated users so that you can give access via the fields you configure. Ben suggests that there is a module that will allow us to configure view permissions per node, which would help with this.
MegaKeegMan
commented
9 months ago Having an issue where the function access_by_ref_node_access, which I would assume is a hook implementation, does not get called. I seem to only be having this issue on PECE, and have not yet identified why this is (or is not) occurring.
MegaKeegMan
commented
9 months ago I am disappointed to report that I don't think access_by_ref works well enough to use. Somehow in my initial testing, I did not run into all of the problems I am running into now. The main problem is just that there seem to be many times that the hook implementation I mentioned above does not get invoked. I have now run into this on more sites than just PECE. I have been unable to deduce exactly what causes this issue, but looking around I get a sense that I am not the only one having issues.
MegaKeegMan
commented
4 months ago Suggestions from Partdigital on best path forward for access policy to have better group management workflow: https://www.drupal.org/project/access_policy/issues/3419012
from what we discussed, there is no need for group specific content, as content does not need to be managed by a group as much as groups need to be given view/edit access by the owner of the content.