- Issue created by @MegaKeegMan
- πΊπΈUnited States MegaKeegMan
I did just notice the description on the public access policy type:
"Do not restrict view access. Control edit and delete access with permissions."So it is starting to sound like maybe this is a matter of me just not understanding something.
In case this issue should actually be a support request, and that I am just trying to use this module incorrectly, I just want to have an access policy that allows everyone to view, but only specified users (via a field on a piece of content) to edit. I thought this was going to be very easy when I started, but then got blocked very quickly when I saw that I could not add access rules to a public access policy.
- πΊπΈUnited States partdigital
Hi MegaKeegMan
This is by design. Public policies are limited to just permissions and not access rules. The idea being that, in most cases, only internal users will be allowed to create public content and they will have their own role (e.g Employee).
Each policy type (Public, Private, Group etc) is a plugin so you can define your own if you like. In your case it might look like this:
/** * Public access policy type with access rules. * * @AccessPolicyType( * id = "public_with_rules", * label = @Translation("Public with access rules"), * weight = -3, * operations = { * "view" = { } * "view all revisions" = { * "permission" = true, * "rules" = true, * }, * "update" = { * "permission" = true, * "rules" = true, * }, * "delete" = { * "permission" = true, * "rules" = true, * }, * "view unpublished" = { * "permission" = true, * "rules" = true, * }, * "manage access" = { } * "rules" = true, * }, * } * ) */ class PublicWithAccessRules extends AccessPolicyTypeBase { }
Note that for each operation you can define how you want to restrict it. You can use permissions or rules or both (or neither).
Another approach you can do is to simply use the Group policy type, grant all users the view operation and exclude the View operation from the access rules.
- Status changed to Closed: works as designed
11 months ago 8:12pm 2 January 2024 - πΊπΈUnited States MegaKeegMan
Very cool. I was more and more realizing that my attempt was not as the module intended. Thanks again for the help! I may try this approach, but for now I think I am just going to go ahead and use a toggle field rather than a separate access policy (though part of me thinks that the separate access policy is a better idea).
though I am running into some further complication. I currently have the widgets showing in the access tab, which in a way feels nice because they show up in the same place as the access policy selection, and because the fields that display are dependent on which access policy is selected. That is very good. However, the access policy cannot be set until after the node has been created, and the access policy selection is only available on the access tab. While I like the tab for many reasons, I sort of wish that users had a little more control over the access policy during creation.
I have considered that I can actually achieve all of my goals with a single access policy. Rather than have "Public" and "Private" policies, I could just have one, and then allow a field control whether the content is public or private. This way I could choose not to display any of this on the access tab, and actually not even expose the access tab, defaulting to the one access policy. The only thing I don't like about this approach is that the visible fields would not display conditionally based on the value in the "public or private" field, in the same way they do based on access policy. I suppose I could always introduce conditional fields module haha. Anyway will link this to the support request.