This subclass provides specialized I/O procedures which allow implicit management of m:n object mappings. For example this can cover the person member assignments of a midgard_group. The mapping class used is configurable, thus it should be adaptable to any standard m:n relationship.
The member objects used to construct this mapping must be fully qualified DBA objects where the user owning the master object has full control, so that the objects can be updated accordingly. It is recommended to make the member objects children of the master objects. In addition, edit, delete and create rights should always go together.
To work properly, this class needs various information: First, there is the name of the member class used to do the mapping. In addition to this, two fieldnames of that class must be supplied, one for the GUID of the master object, the other for the identifier of the membership.
Optionally, you can set the class to use the master object ID in case of the GUID, this is there for legacy code ("midgard_members") which do not use GUIDs for linking yet. The linked object ("membership") is always referenced by the key selected in the corresponding widget.
An additional option allows you to limit the "visible" member key space: You specify query constraints. When updating members, only member records matching these constraints will be taken into account. This is quite useful in case you want to split up a single selection into multiple "categories" for better usability. The constraints are taken into account even when saving new keys so that all load and save stays symmetrical. If you use this feature to separate multiple key namespaces from each other, make sure that the various types do not overlap, otherwise one type will overwrite the assignments of the other.
When starting up, the type will only validate the existence of the mapping class. The members specified will not be checked for performance reasons. In case something wrong is specified there, it will surface during runtime, as invalid mapping entries will be silently ignored (and thus saving won't work).
This type should be set to a null storage location
Available configuration options:
ASC, lower scores will be displayed first. If this is set to
DESC, higher scores will be displayed first.
DESCis default, since then new member objects will be left at the end of the line rather than appearing first. This field is not case sensitive and string can be extended e.g. to
(These list is complete, including all allowed options from the base type. Base type options not listed here may not be used.)
Option Callback class
See base type.
This class essentially extends the select type, rewriting its I/O code to suite the needs of a member management type.
Therefore, we force-override a few settings to ensure operability: allow_other will always be false, while allow_multiple always be true.
This overrides the base types I/O code completely.
This is either the ID or the GUID of the master object, depending on the $master_is_id member.
|var||Foreign key for the master field in the mapping table.|
May only be called if a storage object is defined.
'constraints' => array ( array ( 'field' => 'username', 'op' => '<>', 'value' => '', ), ),
Holds the name of the DBA class used for the mapping code
Holds the fieldname containing the (GU)ID of the master object in the mapping table.
Holds the fieldname containing the membership keys in the mapping table.
This is false by default for mn relations, since by its nature this is intended for dynamic searches.
This will affect the way chooser widget will act and how the results will be presented. If the sorting feature is enabled,
Which direction should metadata.score force the results. This should be either
It is indexed by membership record guid. It will be populated during startup, when the stored data is loaded. During save, this list will be used to determine the objects that have to be deleted.
Only objects matching the constraints will be memorized.