-
Notifications
You must be signed in to change notification settings - Fork 5
Description
What?
The ADO rules config entity + its helper friends the ADO Rule Plugins will allow Rules based on ADO very specific data to be executed. The combination of multiple plugins running and defined/configured inside one of this entities, will return TRUE or FALSE. (maybe "NULL" too for a bypass?")
We will start by building some very simple to use Rule Plugins
- File Rule -> Allows to define a Type of File and File Specific Constraints (size, for PDF, number of pages, etc). CMNY/RGB. Because it works on
as:filetype
structures, and those are well managed by archipelago, all input (form for configuring) will be UX friendly/select boxes and checkboxes. - Bundle Rule -> If Digital Object, Digital Object Collection, Finding AID, etc
- Role Rule -> What Role the user has.
- User ID Rule -> An exact User ID (cool).
- The Permission Rule -> User has a specific Permission?
- Metadata Rule -> An Abstract class Plugin for Conditions based on Metadata
- ADO Type Rule -> Uses
Metadata Rule
logic to match a "type" with a checkbox allowing "type" everywhere inside the JSON - JMESPath Rule -> Bit more advanced *sorry UI. Allowing a JMESPath expression to be run against the whole JSON
- The Embargo Rule
- ADO Type Rule -> Uses
- The Path Rule -> URL based
- The Argument Rule -> any Queries?
- The Flavor Rule -> The ADO has Flavors? Like does it have OCR? Maybe mL? (will run a Solr query though... but we will cache ok?)
Any other rules missing? We can build more in the future
Rules can be combined using AND/OR. The combination makes one ADO Rules Entity Configuration.
Why in this module? BC Format Strawberry Field will use it for the ADO Type to View Mode Mapping. But... I can see how we can also use this in "blocks", in "strawberry runners"... even in access conditions? Oh.. we could use it in webform selection too? If Something -> use this webform, if not, use another. Handy!