- internally, the entity remove the addressLocation when the
personLocation is set, and vice-versa;
- this commit add a migration which may solve the case when both case
happens (priority to personLocation + keep the history)
- add a constraint on the database to avoid such situation
* filters call static entity method
* add renderString option to manage add_children
* add tests on new entity method getDescendantsWithThisFor..()
* rename function in repository
* rename 'Select2..' classes by 'Pick..' and replace all occurences
Each time a step is changed on an history, a record is stored in a
dedicated table.
When the acp's opening date is moved, the first row is adapted to match the new opening's date. This
mechanisme does not work if the opening date is move beyon the first end
date (if any), nor on the closing date.
In a ManyToMany relationship, doctrine does take care only of the owning
side of a relationship to inspect changes.
([see
documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/current/reference/unitofwork-associations.html#important-concepts))
This commit mark as "internal" the methods add/removeSocialAction on the
inversed side (`Evaluation`) and let the methods add/removeEvaluation
on the owning side (`SocialAction`) update the inversed side.
The usage is also adapted into SocialWorkMetadata's importer.
In a ManyToMany relationship, doctrine does take care only of the owning
side of a relationship to inspect changes.
([see
documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/current/reference/unitofwork-associations.html#important-concepts))
This commit mark as "internal" the methods add/removeSocialAction on the
inversed side (`Evaluation`) and let the methods add/removeEvaluation
on the owning side (`SocialAction`) update the inversed side.
The usage is also adapted into SocialWorkMetadata's importer.