Permissions based on field value

[ebruchez]

Use case: permissions based on workflow state (but can also be any data).

• FB: permissions UI must support value-based permissions
• eXist
  • support via XQuery
• relational
  • search must be fast
  • probably require shredding of specific fields (similar/same to #649/#966)
• must work with all persistence layers

This should also enable handling Form Builder permissions without custom logic (but still using form-builder-permissions.xml for backward compatibility), except some FB-specific UI aspects.

Extension: standard way of storing workflow-state, workflow-id.

[avernet]

The Form Builder permissions UI

Completely change to match the structure of the XML, which is more flexible:

• 4 tabs: Create | Read | Update | Delete
• In each tab
  • [x] Same as: ⊙ Create ⊙ Read ⊙ Update ⊙ Delete [if checked, the remainder is greyed out]
  • [x] Anyone can perform [if checked, the remainder is greyed out]
  • Repeat with way to group/nest items with and/or:
  • [x] Must be the owner of the data [enabled only if Create isn't selected]
  • [x] Must be in the same group as the owner [enabled only if Create isn't selected]
  • [x] Must have role: ▭ [text field for now, can then be extended to allow and/or on roles]
  • [x] Must have value in field: ▼[select field] Value: ▭ [could be repeated, but for now we can have just one]

A constraint on a field value translates in the same constraint used right now by the summary page when doing a search on a field.

Persistence

• Checking on the value will be done with an extractValue(), as we already do right now for the search API. (In the future, we can imagine storing the values we want to search on in separate columns; also see #1571.)
• The implementation of the CRUD API will perform this same test, just like it is done right now for owner/group-based permissions.

[avernet]

+1 from customer

[ebruchez]

With #649 implemented, performance should not be an issue, as long as the index includes values on which permissions depend.

If permissions are defined in the form definition itself, this is easy to figure out, but if permissions are defined and changed via properties, a reindex might be needed, OR the permissions will not work.

[ebruchez]

The syntax for #1860 will also need to support checking on values.