Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
The three types of field permissions are likely candidates for plugins, which would simplify much of the code, and allow other modules to implement additional permission handling.
The current types are:
- Public (no access handling)
- Private (never displayed, only editable by the author and admins)
- Custom (per-operation permission configuration)
Comment | File | Size | Author |
---|---|---|---|
#23 | 2757267-23.patch | 55.89 KB | jhedstrom |
Comments
Comment #2
jhedstromHere's a start. I'd like to pull further permission-type-specific logic into the individual plugins, but the field report makes it difficult.
I've left the 'public' permission type hard coded since it basically means to ignore the field as far as this module is concerned, so firing up a plugin for that seemed like overkill.
Comment #3
jhedstromThat patch was missing an interface.
Comment #8
jhedstromNot sure why these are failing.
Comment #11
jhedstromThese tests continue to be green locally.
Comment #14
jhedstromThe test fails have something to do with plugin discovery. I'm adding some kernel tests to try and figure out why these only fail on Drupal CI.
Comment #17
jhedstromThe issue seems to be that the CI can't find the plugins. I'd guess this has to do with overlooked case-sensitivity, but I can't see any. This patch changes how the custom plugin manager is declared (similar to the Filter plugin manager in core).
Comment #20
jhedstromAdding a unit test to try and suss out the bizarre failures here. I am still unable to replicate these locally.
Comment #23
jhedstromI think it was indeed a case-sensitivity issue. Can't believe I didn't catch this sooner.
Comment #25
jhedstromDone and done.