Principles
Content imposition is an extension of the content declination in projects. The specificity is to create a strong link between source and declinations, resulting in automatic synchronizations at each source modification.
Note | This functionality is intended for certain very specific cases of content declination. This section will describe a set of functional concepts leading to very specific conditions of use. It is therefore advisable to control them well and be very careful when using them. |
Technical requirements for imposition
Content imposition requires the same prerequisites as the content proposal and:
the object to be declined must include the
virtualobjectfield (child to the same nature)
Note | Any object with the virtualobject field is eligible for the imposition functionality. If the field value is specified, it indicates that the object is imposed and its source is the pointed object. |
Operation
The creation of the strong link between declination is schematized in this way:
In the same languages, each version of the entity shall be regarded as a declination.
The English versions of projects 1 and 2 depend on the off-project version. Their life cycle depends on it. In fact, with every modification of the "off-project" version, projects 1 and 2 versions are changed.
It should be noted that the English version of Project 3 is not dependent, it is quite possible to impose a declination on certain projects but to leave the declinations free in others.
Configuration
Customizable fields
Updating of project contents is done after modification of the content source via a Wedia core, com.wedia.wxm.database.trigger.SlaveManager.
Even if all the information is to be carried over to the required instances, some fields must remain unchanged such as language, group or project identifier (media).
Thus, in addition to the product fields, we allow you to declare yourself "contextual" fields to your project that should not be impacted when updates. To make these fields "not imposed", you must apply them the tag wxm_not_imposed_property.
For example, you impose an article on several project trees. The link information on the tree structure is project-specific. You will need to apply the tag to this information.
The properties report is done field by field, so you can apply a tag to a collection field for example. In this case, the elements collections will not be included in the required declinations.
Caution | In the case of collections, the application of the tag on an field of the structure in collection is not taken into account: the update of the imposed declinations requires the deletion and re-creation of the set objects the collection. |
Important | The application of the wxm_not_imposed_property tag does not have the following properties impact on the declination wizard configuration step. Any field with the tag wxm_manual_forced_value must have the following properties also of wxm_not_imposed_property otherwise the changes would be deleted in the next update. |
Security and modification of objects
The application of the wxm_not_imposed_property tag has no impact on contribution forms or security.
You must therefore plan and develop specific facets to apply to an imposed object.
You should also review your safety rules accordingly.
Secure the possibility of imposing
We don’t have a specific security domain to test to know if a user has the right to impose content on a project or not.
On the other hand, the display of the choice impose content depends, in addition to the presence of the virtualobject field, of a variable of boolean type in request: canImposeContent.
Initialized by default to true in the wizardpushcontent action, you are free to modify it in a personal role/object and to condition its value according to your personal criteria.
...