[ENH] describe relations

https://avan.tech/item10397-Tiki26-Describe-the-relation

Describe relations

Purpose of this MR is to add metadata to existing relations (mainly tracker field Relations) and work together with @benoitg to implement his plan of action.

Some vocabulary so we are talking about the same thing:

• objectInstanceA (the source object of the relationship)
• objectClassA (the source object class: page, Tracker (a specific trackerA))
• objectInstanceB (the destination object of the relationship)
• objectClassB (basically we would use this at all if the low level relationship is directional and we emulate bidirectional relationships on top)
• tiki_object_relationC (the database table row for the relation above in the tiki_object_relation table)
• relationShipTrackerD (the relationship tracker used by the relation above.)
• relationShipTrackerItemE (the relationship tracker used by the relation above. It's fields contain whatever data qualifies the relation)
• relationshipBehaviourList A structure in the code, or generated by the code (if we want the user to define custom behaviour in tiki extensions or something) whose key is something like "BLOCKS". System wide, there is only one.
• relationshipBehaviourF A specific relationship behaviour. Probably has labels and description so the admin can chose it, and has things SQL code will need to know about the relations (directionality, cardinality). One limitation of this idea is that there is no obvious way to easily map things like per-tracker end user help, minimum approvers, etc. except maybe by naming conventions.

Now, we need to link:

1. objectInstanceA *:* objectInstanceB
2. tiki_object_relationC 1:1 to relationShipTrackerItemE (to store the relationship)
3. objectClassA *:1 to relationShipTrackerD (so we know how to create new relations). For trackers, that would be a an additional option in tracker fields.
4. relationShipTrackerD to relationshipBehaviourF (so the code knows what to do with the relation)
5. tiki_object_relations.source_fieldId which should map to tiki_tracker_tiem_fields.fieldId, so we can quickly get all relations for an item and field pair.

(note: TrackerA, TrackerB, .... describe individual relation types; items inside describe the relation objects (tiki_object_relations))

Is did not plan that we could chose multiple relationship types for the same relations field in a tracker. For example, if we have tickets that BLOCK others, and we also want tickets that have subtickets, those would have to be different fields. On the other hand a user could create a tracker for the relation that has an options field (Lets say "bug", "feature", "refactoring", "documentation") and the end user would be presented with a select box. But there could not be code that acts differently for specific values of that field.

relationshipBehaviourList example:

['BLOCKS' => ['cardiality' => MANY_TO_MANY,
'directional' => true],
'GENERIC_DIRECTINAL' => ['cardiality' => MANY_TO_MANY,
'directional' => true],
'GENERIC_NON_DIRECTIONAL' => ['cardiality' => MANY_TO_MANY,
'directional' => false]
'GENERIC_ONE_TO_MANY' => ['cardiality' => ONE_TO_MANY,
'directional' => true]
]

Next actions

1. Extend the raw data format of tracker relations to allow storing the id of tiki_object_relation from the source tracker, as that is the only way to manipulate the relationship in tiki. It has no permission or api of it's own, it basically writes through hooks on relations fields as far as I can tell. And it would be silly to do a round trip to the server to to a full index scan of the tiki_object_relation to try to find if there is a relationship matching that source - destination pair. Impossible now that could semantically be more than one relation for the same pair.
2. Figure out wow we handle security? The link to metadata itself is safe, but as there is a new tracker item created for every relationship in the system, trackers used for that purpose will need special permission handling, so not every user can change the value of the fields, but any user that have access to change the source relation field can. Is anything else in tiki currently doing something similar (inheriting permissions from other "owner" objects)?
3. Figure out a system so we can map specific meaning known to the code (suck as BLOCKS, SUBTASK, REQUIRES, etc.) to specific values of specific fields in the metadata tracker item
4. Write a minimal UX for the mapper, and saving the metadata tracker items describing the relationships.