* the role CREATE is now transformed to CREATE_ACCOMPANYING_COURSE or
CREATE_PERSON when the subject is, respectively, a course or a person;
* the button at the list of activities is now labeled "create"
* the role FULL give access to both role
acTIVITY_CREATE_ACCOMPANYING_COURSE and ACTIVITY_CREATE_PERSON, but not
ACTIVITY_CREATE directly.
* check that transition can be applyied in menu;
* change organisation for activityVoter, and check for authorization in
Activity Controller
* fix label 'create' in accompanying course document
* minor fix in accompanying course document voter
* change color when course is closed and show old user, and startdate /
enddate
adding an updateHack in store, and a watcher in component.
* updateHack increment a value in the lpop,
* the watcher detect when value changes
* and $forceUpdate
improve layer checkbox legend refresh and rebuild
Use centerResolverDispatcher to normalize a person's center
# Description of changes
There is a normalizer for a person, which include a property "center":
```json
{
"type": "person",
"id": 4362539,
"text": "Diakite BAH",
"firstName": "Diakite",
"lastName": "BAH",
"center": {
"id": 475,
"type": "center",
"name": "Nord Vendée"
},
"phonenumber": "",
"mobilenumber": "",
"altNames": [ ],
"gender": "woman",
"gender_numeric": 1,
// ...
}
```
Previously, the center was the center attached to the person in the database.
But since September, version 2.0 allow to resolve the center dynamically, for instance with the usage of address. This resolution is done through `CenterResolverDispatcher`.
This `CenterResolverDispatcher` is now used into person normalization.
As a consequence, the center may now be:
* null;
* a center;
* an array of center;
Thoses case are taken into account into `PersonRenderBox` in Vue.
# Issues related
Any issue related.
# Tests
Any new tests.
See merge request Chill-Projet/chill-bundles!205
- a new getter count links by node. before exclude person, check first if node has others visible links
- links id are rewrote to serve count links getter
- unfold and expand only folded person
Bugfixes/tasks list
# Description of changes
<!--
describe here the change of your MR. It can be either a text, or a bullet list
for changes
-->
* different title for task list and my title
* fixes link to tasks in alert
# Issues related
<!--
list the issues related to this MR.
It may be client issues, or dev issues
-->
no issues related
# Tests
The tests for listing task does apply
See merge request Chill-Projet/chill-bundles!200
by address reference
* add a one-to-many link between address and address reference;
* update AddAddress.vue to add information on picked address reference;
* add an HouseholdACLAwareRepository, with a method to find household by
current address reference
* add an endpoint to retrieve household by address reference
* + tests
When using displayBadge=true, you need to pass buttonText=string with badge content.
Limitation: onTheFly cannot use directly PersonRenderBox to display badge,
because it don't have person object in props !
edit context: display country for existing address
new context: repair editPane, load countries
note: adding id for country and postcode in address endpoint json
re-implements searching
* add geographic function ST_CONTAINS
* add a link between the current valid address and person, optimized on
database side;
* update PersonACLAwareRepository for re-using methods elsewhere.
The controller now register data from a previous post on the form, and
register it in the session.
The next post compare the data with previous one and, if yes, show a
review page if there are "alternate persons.
- an evaluation type can be repeated multiple times on the same action;
- in vue, evaluation are listed by key, not id,
- adding an evaluation make appears directly in "edit" mode;
- ...
i18n is managed by root component:
* ok for person and household implementation (=> they use Address root component)
* but must be imported in vue i18n file if called from another component
submitAddress is emit to parent, it allow to control final action:
* casting final submitNewAddress with POST requests (for person or household entity);
* or dispatching changes from store, casting only payload to be used.
remove and simplify some options: backurl is always used with person/household,
and never if called from another vue component.
note: span.chill-entity tag is replaced by section.chill-entity tag.
because some cases are not valid html :
* span.chill-entity > div
* span.badge > div.chill-entity
* chill: chill theme entrypoint
* lib: local libs, called in several place but don't have entrypoint
* module: local libs with specific entrypoints
* page: pages with specific entrypoints
* vuejs: vue components with specific entrypoints
remove local libs jquery and select2, they already exists in node_modules
remove duplicate fonts
* add context for accompanying period, if indicated in a query
parameter;
* expand automatically household suggestion, if indicated in a query
parameter
We use box-shadow instead of border
to avoid to manage border double-width
when blocs are resized for small screen !
Then we can simulate border-collapse: collapse (table)
* vue css and js loaded from layout.html.twig
* rename 'show' template to 'edit' template
* overwrite js block for 'edit' template (load all component, not only banner)
1. Fix call to `::getOpenParticipationContainsPerson` instead of `::getParticipationsContainsPerson`.
2. Use early returns to reduce cyclomatic complexity.
3. Avoid storing variable that are used only once.
selectAndSuggested method in store getter, is callable in all components,
and make union of two arrays: suggested and selected
* we need to have selected in last position (required for isChecked method to work well)
* but we want to display selected in first position (for better ux)
then, we use double inversion to obtain good behaviour
Modal component is an hybrid solution between :
- Vue3 modal implementation
=> with 'v-if:showModal' directive:parameter, html scope is added/removed not just shown/hidden
=> with slot we can pass content from parent component
=> some classes are passed from parent component
- Bootstrap 4.4 _modal.scss module
=> using bootstrap css classes, the modal have a responsive behaviour,
=> modal design can be configured using css classes (size, scroll)
See
* https://v3.vuejs.org/examples/modal.html#modal-component
* https://github.com/bootstrap-vue/bootstrap-vue/issues/5196
Two new routes:
* `GET /{_locale}/person/api/1.0/accompanying-course/{parcours_id}/show.json`: get a json representation for a course
* `POST /{_locale}/person/api/1.0/accompanying-course/{parcours_id}/participation.json`:
add a particitipation to course. Usage:
`curl -v --cookie "PHPSESSID=fed98aa23e40cb36e630f84155aea3bb;" -X
POST --data '{ "id": 481 }'
http://localhost:8001/fr/person/api/1.0/accompanying-course/270/participation.json`
Will add the person with id "481" to the course.
fixes : A new entity was found through the relationship 'Chill\PersonBundle\Entity\AccompanyingPeriodParticipation#accompanyingPeriod'
that was not configured t o cascade persist operations for entity: Chill\PersonBundle\Entity\AccompanyingPeriod@0000000002b1d44a000000002510e4e2.
To solve this issue: Either explici tly call EntityManager#persist() on this unknown entity or configure
cascade persist this association in the mapping for example @ManyToOne(..,cascade={"persist"}). If you cannot find out which entity causes the problem
implement 'Chill\PersonBundle\Entity\AccompanyingPeriod#__toString()' to get a clue.
Note:
* move flex in root composer.json (otherwise it is not read)
* webpack-encore-bundle needed to use twig function {{ encore_entry_script_tags() }}
* flex recipe add new 'assets' dir
We create a level into the "installation" directory, and create an index file into this directory.
This will also be more consistent with the "developer" part.
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to
* [Semantic Versioning](https://semver.org/spec/v2.0.0.html) for stable releases;
* date versioning for test releases
## Unreleased
<!-- write down unreleased development here -->
## Test releases
### test release 2021-12-11
* [main] add order field to civility
* [main] change address format in case the country is France, in Address render box and address normalizer
* [person] add validator for accompanying period with a test on social issues (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/76)
* [activity] fix visibility for location
* [origin] fix origin: use correctly the translatable strings
* /!\ everyone must update the origin table. As there is only one row, execute `update chill_person_accompanying_period_origin set label = jsonb_build_object('fr', 'appel téléphonique');`
* [person] redirect bug fixed.
* [action] add an unrelated issue within action creation.
* [origin] fix origin: use correctly the translatable strings
* /!\ everyone must update the origin table. As there is only one row, execute `update chill_person_accompanying_period_origin set label = jsonb_build_object('fr', 'appel téléphonique');`
* [main] change order of civilities in civility fixtures (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/191)
* [person] set min attr in the minimum of children field (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/191)
* [person] add marital status date in person view (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/191)
* [person] show number of children + allow set number of children to null (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/191)
* [person] show acceptSMS option (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/191)
* [person] add death information in person render box in twig and vue render boxes (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/191)
* [asideactivity] creation of aside activity category fixed (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/262)
* [main] address: use search API end points for getting postal code and reference address (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/316)
* [main] address: in edit mode, select the encoded values in multiselect for address reference and city (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/316)
* [person search] fix bug when using birthdate after and birthdate before
* [person search] increase pertinence when lastname begins with search pattern
* [activity/actions] Améliore la cohérence du design entre
* la page résumé d'un parcours (liste d'actions récentes et liste d'activités récentes)
* la page liste des actions
* la page liste des activités (contexte personne / contexte parcours)
* [household] field to edit wheter person is titulaire of household or not removed (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/322)
* [activity] create work if a work with same social action is not associated to the activity
* [visgraph] improve and fix bugs on vis-network relationship graph
* [bugfix] posting of birth- and deathdate through api fixed.
* [suggestions] improve suggestions lists
* [badge-entity] design coherency between badge-person and 3 kinds of badge-thirdparty
* [AddPersons] suggestions row are clickable, not only checkbox
* [activity] improve show/new/edit templates, fix SEE and SEE_DETAILS acl
* [activity][calendar] concerned groups items are clickable with on-the-fly modal, create specific badge for TMS column
### Test release 2021-11-19 - bis
* [household] do not allow to create two addresses on the same date
* [activity] handle case when there is no social action associated to social issue
* [activity] layout for issues / actions
* [activity][bugfix] in edit mode, the form will now load the social action list
### Test release 2021-11-29
* [person] suggest entities (person | thirdparty) when creating/editing the accompanying course (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/119)
* [activity] add custom validation on the Activity class, based on what is required from the ActivityType (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/188)
* [main] translate multiselect messages when selecting/creating address
* [main] set the coordinates of the city when creating a new address OR choosing "pas d'adresse complète"
* Use the user.label in accompanying course banner, instead of username;
* fix: show validation message when closing accompanying course;
* [thirdparty] link from modal to thirdparty detail page fixed (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/228)
* [assets] new asset to style suggestions lists (with add/remove item link) (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/258)
* [accompanyingCourseWorkEdit] improves hyphenation and line breaks for long badges
* [acompanyingCourse] improve Resume page
* complete all needed informations,
* actions and activities are clickables,
* better placement with js masonry blocks on top of content area,
* [activity/calendar] on show page, concerned groups of persons table adapt itself to isVisibles options
* [activity] remove the "plus" button in activity list
* [activity] check ACL on activity list in person context
* [list for accompanying course in person] filter list using ACL
* [validation] toasts are displayed for errors when modifying accompanying course (generalization required).
* [period] only the user can enable confidentiality
* add an endpoint for checking permissions. See https://gitlab.com/Chill-Projet/chill-bundles/-/merge_requests/232
* [activity] for a new activity: suggest and create on-the-fly locations based on the accompanying course location + location of the suggested parties
* [calendar] for a new rdv: suggest and create on-the-fly locations based on the accompanying course location + location of the suggested parties
## Test releases
### Test release 2021-11-22
* [activity] delete admin_user_show in twig template because this route is not defined and should be defined
* [activity] suggest requestor, user and ressources for adding persons|user|3rdparty
* [calendar] suggest persons, professionals and invites for adding persons|3rdparty|user
* [activity] take into account the restrictions on person|thirdparties|users visibilities defined in ActivityType
* [main] Add currentLocation to the User entity + add a page for selecting this location + add in the user menu (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/133)
* [activity] add user current location as default location for a new activity (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/133)
* [task] Select2 field in task form to allow search for a user (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/167)
* remove "search by phone configuration option": search by phone is now executed by default
* remplacer le classement par ordre alphabétique par un classement par ordre de pertinence, qui tient compte:
* de la présence d'une string avec le nom de la ville;
* de la similarité;
* du fait que la recherche commence par une partie du mot recherché
* ajouter la recherche par numéro de téléphone directement dans la barre de recherche et dans le formulaire recherche avancée;
* ajouter la recherche par date de naissance directement dans la barre de recherche;
* ajouter la recherche par ville dans la recherche avancée
* ajouter un lien vers le ménage dans les résultats de recherche
* ajouter l'id du parcours dans les résultats de recherche
* ajouter le demandeur dans les résultats de recherche
* ajout d'un bouton "recherche avancée" sur la page d'accueil
* [person] create an accompanying course: add client-side validation if no origin (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/210)
* [person] fix bounds for computing current person address: the new address appears immediatly
* [docgen] create a normalizer and serializer for normalization on doc format
* [person normalization] the key center is now "centers" and is an array. Empty array if no center
* [accompanyingCourse] Ability to close accompanying course (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/296)
* [task] Select2 field in task form to allow search for a user (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/167)
* [list result] show all courses, except ones with period closed
* [accompanyingCourse] improve banner with small carousel to display slide social-issues or slide associated persons (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/69)
### Test release 2021-11-15
* [main] fix adding multiple AddresseDeRelais (combine PickAddressType with ChillCollection)
* [person]: do not suggest the current household of the person (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/51)
* [person]: display other phone numbers in view + add message in case no others phone numbers (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/184)
* unnecessary whitespace removed from person banner after person-id + double parentheses removed (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/290)
* [person]: delete accompanying period work, including related objects (cascade) (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/36)
* [address]: Display of incomplete address adjusted.
* [household]: improve relationship graph
* add form to create/edit/delete relationship link,
* improve graph refresh mechanism
* add feature to export canvas as image (png)
* [person suggest] In widget "add person", improve the pertinence of persons when one of the names starts with the pattern;
* [person] do not ask for center any more on person creation
* [3party] do not ask for center any more on 3party creation
## Test releases
### Test release 2021-11-08
* [person]: Display the name of a user when searching after a User (TMS)
* [person]: Add civility to the person
* [person]: Various improvements on the edit person form
* [person]: Set available_languages and available_countries as parameters for use in the edit person form
* [activity] Bugfix: documents can now be added to an activity.
* [tasks] improve tasks with filter order
* [tasks] refactor singleControllerTasks: limit the number of conditions from the context
* [validations] validation of accompanying period added: no duplicate participations or resources (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/60).
* [renderbox] If gender of person is not defined, no icon is displayed instead of neuter-icon (https://gitlab.com/champs-libres/departement-de-la-vendee/accent-suivi-developpement/-/issues/129).
* [confidential information] module added to blur confidential information (https://gitlab.com/champs-libres/departement-de-la-vendee/chill/-/issues/248).
* refactor `AuthorizationHelper` and `UserACLAwareRepository` to fix constructor, and separate logic for parent role helper into `ParentRoleHelper`
* [main]: filter location and locationType in backend: exclude NULL names, only active and availableToUsers
* [activity]: perform client-side validation & show/hide fields in the "new location" modal
* [person]: normalize person with CenterResolverDispatcher and handle case where center is null or multiple in PersonRenderBox
* [docstore] voter for PersonDocument and AccompanyingCourseDocument on the 2.0 way (using VoterHelperFactory)
* [docstore] add authorization check inside controller and menu
* [activity]: fix inheritance for role `ACTIVITY FULL` and add missing acl in menu
* [person] show current address in search results
* [person] show alt names in search results
* [admin]: links to activity admin section added again.
* [household]: endDate field deleted from household edit form.
* [household]: View accompanying periods of current and old household members.
* [tasks]: different layout for task list / my tasks, and fix link to tasks in alert or in warning
* [admin]: links to activity admin section added again.
* [household]: household addresses ordered by ValidFrom date and by id to show the last created address on top.
* [socialWorkAction]: display of social issue and parent issues + banner context added.
* [DBAL dependencies] Upgrade to DBAL 3.1
### Test release 2021-10-27
* [person]: delete double actions buttons on search person page
* [person]: accompanying course work: remove creation date display the list of work + handle case when end date is null
* [main]: Add new pages with a menu for managing location and location type in the admin
* [main]: Add some fixtures for location type
* [calendar]: Pass the location when transforming a calendar item (rdv) into an activity
* [calendar]: Add a user menu for "my calendar"
### Test release 2021-10-18
* [3party]: french translation of contact and company
* [3party]: show parent in list
* [3party]: change color for badge "child"
* [3party]: fix address creation
* [household members editor] finalisation of editor
* application vue (souvent spécifique à une page) -> préfixé par `vue_`;
* code js/css qui est réutilisé à plusieurs endroits:
* ckeditor
* async_upload (utilisé pour un formulaire)
* bootstrap
* chill.js
* ...
=> on préfixe `mod_`
* code css ou js pour une seule page
* ré-utilise parfois des "foncitionnalités": ShowHide, ...
=> on préfixe `page_`
Arborescence:
```
# Sous Resources/public
- chill/ => theme (chill)
- chillmain.scss -> push dans l'entrypoint chill
- lib/ => ne vont jamais dans un entrypoint, mais sont ré-utilisés par d'autres
- ShowHide
- Collection
- Select2
- module/ => termine dans des entrypoints ré-utilisables (mod_)
- bootstrap
- custom.scss
- custom/
- variables.scss
- ..
- forkawesome
- AsyncUpload
- vue/ => uniquement application vue (vue_)
- _components
- app
- page/ => uniquement pour une seule page (page_)
- login
- person
- personvendee
- household_edit_metadata
- index.js
```
## Organisation des feuilles de styles
Comment s'échaffaudent les styles dans Chill ?
1. l'entrypoint **mod_bootstrap** (module bootstrap) est le premier niveau. Toutes les parties(modules) de bootstrap sont convoquées dans le fichier ```bootstrap.js``` situé dans ```ChillMainBundle/Resources/public/module/bootstrap```.
* Au début, ce fichier importe le fichier ```variables.scss``` qui détermine la plupart des réglages bootstrap tels qu'on les a personnalisés. Ce fichier surcharge l'original, et de nombreuses variables y sont adaptées pour Chill.
* On veillera à ce qu'on puisse toujours comparer ce fichier à l'original de bootstrap. En cas de mise à jour de bootstrap, il faudra générer un diff, et adapter ce diff sur le fichier variable de la nouvelle version.
* A la fin on importe le fichier ```custom.scss```, qui comprends des adaptations de bootstrap pour le préparer à notre thème Chill.
* ce ```custom.scss``` peut être splitté en plus petits fichiers avec des ```@import 'custom/...'```
* L'idée est que cette première couche bootstrap règle un partie importante des styles de l'application, en particulier ce qui touche aux position du layout, aux points de bascules responsive, aux marges et écarts appliqués par défauts aux éléments qu'on manipule.
2. l'entrypoint **chill** est le second niveau. Il contient le thème Chill qui est reconnaissable à l'application.
* Chaque bundle a un dossier ```Resources/public/chill``` dans lequel on peut trouver une feuille sass principale, qui est éventuellement splittée avec des ```@imports```. Toutes ces feuilles sont compilées dans un unique entrypoint Chill, c'est le thème de l'application. Celui-ci surcharge bootstrap.
* La feuille chillmain.scss devrait contenir les cascades de styles les plus générales, celles qui sont appliquées à de nombreux endroits de l'application.
* La feuille chillperson.scss va aussi retrouver des styles propres aux différents contextes des personnes: person, household et accompanyingcourse.
* Certains bundles plus secondaires ne contiennent que des styles spécifiques à leur fonctionnement.
3. les entrypoints **vue_** sont utilisés pour des composants vue. Les fichiers vue peuvent contenir un bloc de styles scss. Ce sont des styles qui ne concernent que le composant et son héritage, le tag ```scoped``` précise justement sa portée (voir la doc).
4. les entrypoints **page_** sont utilisés pour ajouter des assets spécifiques à certaines pages, le plus souvent des scripts et des styles.
## Taguer du code html et construire la cascade de styles
L'exemple suivant montre comment taguer sans excès un élément de code. On remarque que:
* il n'est pas nécessaire de taguer toutes les classes intérieures,
* il ne faut pas répéter la classe parent dans toutes les classes enfants. La cascade sass va permettre de saisir le html avec souplesse sans alourdir la structure des balises.
* souvent la première classe sera déclinée par plusieurs classes qui commencent de la même manière: ```bloc-dark``` ajoute juste la version sombre de ```bloc```, on ne met pas ```bloc dark```, car on ne souhaite pas que la classe ```dark``` de ```bloc``` interagisse avec la même classe ```dark``` de ```table```. On aura donc un élément ```bloc bloc-dark``` et un élément ```table table-dark```.
```html
<divclass="bloc bloc-dark mon-bloc">
<h3>mon titre</h3>
<ulclass="record_actions">
<li>
<aclass="btn btn-edit"></a>
</li>
<li></li>
<li></li>
</ul>
</div>
```
Finalement, il importe ici de définir ce qu'est un bloc, ce qu'est une zone d'actions et ce qu'est un bouton. Ces 3 éléments existent de manière autonome, ce sont les seuls qu'on tagge.
Par exemple pour mettre un style au titre on précise juste h3 dans la cascade bloc.
```scss
div.bloc{
// un bloc générique, utilisé à plusieurs endroits
&.bloc-dark{
// la version sombre du bloc
}
h3{}
ul{
// une liste standard dans bloc
li{
// des items de liste standard dans bloc
}
}
}
div.mon-bloc{
// des exceptions spécifiques à mon-bloc,
// qui sont des adaptations de bloc
}
ul.record_actions{
// va uniformiser tous les record_actions de l'application
li{
//...
}
}
.btn{
// les boutons de bootstrap
.btn-edit{
// chill étends les boutons bootstrap pour ses propres besoins
}
}
</style>
```
## Render box
## URL
### Nommage des routes
:::warning
Ces règles n'ont pas toujours été utilisées par le passé. Elles sont souhaitées pour le futur.
:::
Les routes sont nommées de cette manière:
`chill_bundle_entite_action`
1. d'abord chill_ (pour tous les modules chill)
2. ensuite une string qui est identique, par bundle
3. si le point est un point d'api (json), alors ajouter la string `api`
4. ensuite une string qui indique sur quelle entité porte la route, voire également les sous-entités
5. ensuite une action (`list`, `view`, `edit`, `new`, ...)
Le fait d'indiquer `api` en 3 permet de distinguer les routes d'api qui sont générées par la configuration (qui sont toutes préfixées par `chill_api`, de celles générées manuellement. (Exemple: `chill_api_household__index`, et `chill_person_api_household_members_move`)
Si les points 4 et 5 sont inexistants, alors ils sont remplacés par d'autres éléments de manière à garantir l'unicité de la route, et sa bonne compréhension.
### URL
Les URL respectent également une convention:
#### Pour les pages html
:::warning
Ces règles n'ont pas toujours été utilisées par le passé. Elles sont souhaitées pour le futur.
:::
Syntaxe:
```
/{_locale}/bundle/entity/{id}/action
/{_locale}/bundle/entity/sub-entity/{id}/action
```
Les éléments suivants devraient se trouver dans la liste:
1. la locale;
2. un identifiant du bundle
3. l'entité auquel il se rapporte
4. les éventuelles sous-entités auxquelles l'url se rapport
5. l'action
Ces éléments peuvent être entrecoupés de l'identifiant d'une entité. Dans ce cas, cet identifiant se place juste après l'entité auquel il se rapporte.
Exemple:
```
# liste des échanges pour une personne
/fr/activity/person/25/activity/list
# nouvelle activité
/fr/activity/activity/new?person_id=25
```
#### Pour les API
:::info
Les routes générées automatiquement sont préfixées par chill_api
:::
Syntaxe:
```
/api/1.0/bundle/entity/{id}/action
/api/1.0/bundle/entity/sub-entity/{id}/action
```
Les éléments suivants devraient se trouver dans la liste:
1. la string `/api/` et puis la version (1.0)
2. un identifiant du bundle
3. l'entité auquel il se rapporte
4. les éventuelles sous-entités auxquelles l'url se rapport
5. l'action
Ces éléments peuvent être entrecoupés de l'identifiant d'une entité. Dans ce cas, cet identifiant se place juste après l'entité auquel il se rapporte.
## Règles UI chill
### Titre des pages
#### Chaque page contient un titre
Chaque page contient un titre dans la balise head. Ce titre est normalement identique à celui de l'entête de la page.
Astuce: il est possible d'utiliser la fonction `block` de twig pour cela:
```htmlmixed=
{% block title "Titre de la page" %}
{% block content %}
<h1>
{{ block('title')}}
</h1>
{% endblock %}
```
### Utilisation des `entity_render`
#### En twig
Les templates twig doivent toujours utiliser la fonction chill_entity_render_box pour effectuer le rendu des éléments suivants:
* User
* Person
* SocialIssue
* SocialAction
* Address
* ThirdParty
* ...
Exemple:
```
address|chill_entity_render_box
```
Justification:
* des éléments sont parfois personnalisés par installation (par exemple, le nom de chaque utilisateur sera suivi par le nom du service)
* pour rationaliser et rendre semblable les affichages
* pour simplifier le code twig
A prevoir:
* toujours trois positions:
* inline
* block
* item (dans un tableau, une ligne)
> block et item sont en fait la même option passée au render_box: render: bloc. Il y a aussi ‘raw’ pour le inline, et ‘label’ pour une titraille configurable avec des options.
> quand on passe l’option render: bloc, on peut placer le render_box dans une boucle for plus large qui fonctionne avec la classe flex-table ou la classe flex-bloc, ce qui donnera un affichage en rangée (table) ou en blocs. [name=Mathieu]
#### En vue
Il existe systématiquement une "box" équivalente en vue.
#### Lien vers des sections
A chaque fois qu'on indique le nom d'une personne, un parcours, un ménage, il y a toujours:
* un lien pour accéder à son dossier (pour autant que l'utilisateur ait les droits d'accès);
* à moins qu'il ne soit indiqué dans une phrase, l'icône de son dossier avant ou après (donc un bonhomme pour la personne, une maison pour le ménage, un fa-random pour les parcours);
Ces éléments sont toujours proposé par des `render_box` par défaut. Des options permettent de les désactiver dans des cas particuliers
> à discuter, quelques réflexion:
> quelle est la logique qui domine pour les boutons ? on a symbolisé les 4 actions du crud par des couleurs: bleu(show) orange(edit) vert(create) et rouge(delete).
> Est-ce que c'est ça qui prime, et comment ça s'articule avec la logique des pictos ?
> Par exemple, il pourrait être logique d'utiliser l'oeil bleu pour voir l'objet, qu'il s'agisse d'une personne ou d'un parcours, ce serait plutôt le contexte, et l'infobulle (title) qui préciserait le contexte.
> Je pense que les pictos de boutons doivent faire référence à l'action, mais pas à l'objet. Autrement dit je n'utiliserais jamais l'icone du ménage ou du parcours dans les boutons.
> Pour représenter les ménages et les parcours, je pense qu'il faudrait trouver autre chose que forkawesome. Si c'est des pictos, trouver un motif différents et de tailles différente. Réfléchir à un couplage picto-couleur-forme différent, qui exprime le contexte et qui se distingue bien des boutons.
> Idem pour les badges, il faut une palette de badge qui couvre tous les besoins: socialIssue, socialActions, socialReason, members, etc. [name=Mathieu]
### Formulaires
#### Vocabulaire:
Utiliser toujours:
* `Créer` dans un `bt bt-create` pour les **liens** vers le formulairep pour créer une entité (pour parvenir au formulaire);
* `Enregistrer` dans un `bt bt-save` pour les boutons "Enregistrer" (dans un formulaire édition **ou** création);
* `Enregistrer et nouveau`
* `Enregistrer et voir`
* `Modifier` dans un `bt bt-edit` pour les **liens** vers le formulaire d'édition
* `Dupliquer` (préciser là où on peut le voir)
* `Annuler` pour quitter une page d'édition avec un lien vers la liste, ou le `returnPath`
#### Retour après un enregistrement
Après avoir cliqué sur "Créer" ou "Sauver", la page devrait revenir:
* vers le returnPath, s'il existe;
* sinon, vers la page "vue".
### Bandeaux contenant les boutons d'actions
Les boutons sont toujours dans un bandeau "sticky-form" dans le bas du formulaire ou de la page de liste.
Si pertinent:
* Le bandeau contient un bouton "Annuler" qui retourne à la page précédente. Il est obligatoire pour les formulaires, optionnel pour les listes ou les pages "résumés"
A chaque fois qu'un élément est créé par un formulaire, un message flash doit apparaitre. Il indique:
> "L'élément a été créé"
Le nom de l'élément peut être remplacé par quelque chose de plus pertinent:
> * L'activité a été créée
> * Le rendez-vous a été créé
> * ...
#### A l'enregistrement d'une entité
A chaque fois qu'un élément est enregistré, un message flash doit apparaitre:
> * Les données ont été modifiées
>
#### Erreur sur un formulaire (erreur de validation)
En tête d'un formulaire, un message flash doit indiquer que des validations n'ont pas réussi:
> Ce formulaire contient des erreurs
Les erreurs doivent apparaitre attachée au champ qui les concerne. Toutefois, il est acceptable d'afficher les erreurs à la racine du formulaire s'il était complexe, techniquement, d'attacher les erreurs.
### Liens de retour
A chaque fois qu'un lien est indiqué, vérifier si on ne doit pas utiliser la fonction `chill_return_path`, `chill_forward_return_path` ou `chill_return_path_or`.
* depuis la page liste, vers l'ouverture d'un élément, ou le bouton création => utiliser `chill_path_add_return_path`
* dans ces pages d'éditions,
* utiliser `chill_return_path_or` dans le bouton "Cancel";
* pour les boutons "enregistrer et voir" et "Enregistrer et fermer" => ?
### Assets pour les listes de suggestion
Créer une liste de suggestions à ajouter (tout l'item est cliquable)
```html
<ul class="list-suggest add-items">
<li>
<span>item</span>
</li>
</ul>
```
Créer une liste de suggestions à enlever (avec une croix rouge cliquable, l'ancre a est vide)
```html
<ul class="list-suggest remove-items">
<li>
<span>
item
<a></a>
</span>
</li>
</ul>
```
Créer un titre enlevable (avec une croix rouge cliquable, l'ancre a est vide)
```html
<div class="item-title">
title
<a></a>
</div>
```
Les classes `cols` ou `inline` peuvent être ajoutées à côté de `list-suggest` pour modifier la disposition de la liste.
$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
note left: <b>Membership</b> relie les groupes aux\npersonnes. Chaque membership a un\n <b>role</b>, le rôle est à choisir\nparmi ceux possibles pour le <b>type</b> de <b>groupe</b>
class Group {
- type
- memberships
- name
- center
}
note left: Un groupe a un type qui est défini à sa création.
class Type {
- roles
}
note right: Les types de groupe qu'il est possible de créer \nsont définis dans l'interface d'administration.\nExemple de type: "famille", "groupe de parole", "stage", ...
class Role {
- name
}
note right: Pour chaque <b>Type</b> on définit des rôles\npossibles pour ce type de groupe. Par exemple, pour le\ntype "famille" on peut avoir les rôles <i>parents</i> et <i>enfants</i>.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._activity-bundle:
Activity bundle
###############
This bundle provides the ability to record people in the software. This bundle is required by other bundle.
..contents:: Table of content
:local:
Entities provided
*****************
..todo::
Describe the entities provided.
Configuration options
*********************
Those options are available under `chill_activity` key.
Example of configuration:
..code-block::yaml
chill_activity:
form:
time_duration:
- {label: '12 minutes', seconds:720}
- {label: '30 minutes', seconds:1800}
form.time_duration *array*
The duration which might be suggested when the user create or update an activity. The value must be an array of object, where each object must have a :code:`label` and a :code:`seconds` key. The label provide which is shown to user (the label will be translated, if possible) and the seconds the duration.
Example: see the example above
Default value: the values available are 5, 10, 15, 20, 25, 30, 45 minutes, and 1 hour, 1 hour 15, 1 hour 30, 1 hour 45 and 2 hours.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._custom-fields-bundle:
Custom fields bundle
====================
This bundle provides the ability to add custom fields to existing entities.
Those custom fields contains extra data and will be stored in the DB, along with other data's entities. It may be string, text, date, ... or a link to an existing entities.
In the database, custom fields are stored in json format.
..seealso::
The full specification discussed `here. <https://redmine.champs-libres.coop/issues/239>`_
`JSON Type on postgresql documentation <http://www.postgresql.org/docs/9.3/static/datatype-json.html>`_
The documentation of json type, which is used to store data in the database.
..contents:: Table of contents
:depth:4
:local:
Custom Fields concepts
----------------------
Custom fields are extra data which may be added to entities by user. If a developer implements custom fields on a entity, users will be able to add more fields on this entity.
Example: the `person bundle` allows to record `firstname`, `lastname`, `date of birth` fields. But users need to store information about the kind of house he has (if he owns his house, if he rents it, ...). Custom fields allows to create those fields.
Automatically, those fields are added at the person form. They are also printed in the person view and in exports.
Custom fields and custom fields group
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Custom fields are associated to a custom fields group. When a user want to add custom fields on an entity, he must first create a custom fields group and associate this field with an entity. Then he may add add custom fields to this groups.
Some entities needs a **default** custom fields group. For instance, the default custom fields group will be printed on the main form for person, and will be appended on the main person view. Some bundle does not use this feature (i.e. the `report` bundle).
..note::
In the future of the `person bundle`, other custom fields group will be added in forms accessible from the menu, allowing users to completely customize and separate their entities.
Allow custom fields on an entity
--------------------------------
As a developer, you must allow your users to add custom fields on your entities.
..warning::
For having custom fields, the class of the entity must contain a variable for storing the custom data. **By convention this variable must be called $cFData**
Create a json field on your entity
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Declare a json field in your database :
..code-block::yaml
Chill\CustomFieldsBundle\Entity\BlopEntity:
type:entity
# ...
fields:
cFData:
type:json_array
Create the field accordingly in the class logic :
..code-block::php
namespaceChill\CustomFieldsBundle\Entity;
/**
* BlopEntity
*/
classBlopEntity
{
/**
* @var array
*/
private$cFData;
/**
* You must set a setter in order to save automatically custom
* fields from forms, using Form Component
*
* @param array $cFData
* @return BlopEntity
*/
publicfunctionsetCFData(array$cFData)
{
$this->cFData=$cFData;
return$this;
}
/**
* You also must create a getter in order to let Form
* component populate form fields
*
* @return array
*/
publicfunctiongetCFData()
{
return$this->cFData;
}
Declare your customizable entity in configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This step is necessary to allow user to create custom fields group associated with this entity.
Two methods are available.
The recommended method is to do it in DependencyInjection/Extension class. It is recommended as your bundle will be well set up (for custom field) in every chill installation that use it.
The discouraged method is to declare via the app/config.yml file. This is very quick to set up for a given chill installation but it is not done automatically : in every chill installation that use your bundle, this step has to be performed.
In app/config.yml file (discouraged)
""""""""""""""""""""""""""""""""""""
This method is discouraged but explained first as it helps to undersand the recommended method.
Add those file under `chill_custom_fields` section :
This is the recommended way for declaring customizable classes.
You can prepend configuration of `custom fields bundle` from the class `YourBundle\DependencyInjection\YourBundleExtension`. **Note** that you also have to implements `Symfony\Component\DependencyInjection\Extension\PrependExtensionInterface` on this class to make the `prepend` function being taken into account.
**Example :** the entity `Report` from **ReportBundle** has to pick some custom fields belonging to a group to print them in *summaries* the timeline page. The definition will use the special type `custom_fields_group_linked_custom_field` which will add a select input with all fields associated with the current custom fields group :
Note that `custom_fields_group_linked_custom_fields` does not create any input on `CustomFieldsGroup` creation : there aren't any fields associated with the custom fields just after the group creation... You have to add custom fields and associate them with the newly created group to see them appears.
Rendering custom fields and custom fields group in a template
Each custom field can be `active` or not. Only `active` custom fields has to be dislayed.
For rendering custom fields, two function are available :
*`chill_custom_field_widget` to render the widget. This function is defined on a customFieldType basis.
*`chill_custom_field_label` to render the label. You can customize the label rendering by choosing the layout you would like to use.
*`chill_custom_field_is_empty` indicates if the content of the custom fields is empty (return a boolean)
For rendering custom fields group, a function is available :
*`chill_custom_fields_group_widget` to render the widget. It will display the custom fields of the group in a dd / dt structure.
chill_custom_field_label
^^^^^^^^^^^^^^^^^^^^^^^^
The signature is :
*`CustomField`**$customField** a customField instance
*`array`**params** the parameters for rendering. Currently, 'label_layout' allow to choose a different label. Default is 'ChillCustomFieldsBundle:CustomField:render_label.html.twig'
Examples
..code-block::jinja
{{chill_custom_field_label(customField)}}
chill_custom_field_widget
^^^^^^^^^^^^^^^^^^^^^^^^^
The signature is :
* array **$fields** the array raw, as stored in the db
* CustomField **$customField** a customField instance
* string **$documentType** the type of document. Default to `html`.
Those options are available in the configuration, under the `chill_custom_field` key.
Example :
..code-block::yaml
chill_custom_field:
show_empty_values_in_views:false
show_empty_values_in_views *boolean*:
Allow to hide / show empty values in views. The aim of this configuration parameter is to hide (or show) empty values when :term:`custom fields group` are rendered.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Bundles documentation
###############################
You will find here documentation about bundles working with Chill.
..toctree::
:maxdepth:2
Main bundle <main.rst>
Custom Fields bundle <custom-fields.rst>
Person bundle <person.rst>
Report bundle <report.rst>
Activity bundle <activity.rst>
Group bundle <group.rst>
Event bundle <event.rst>
Ldap bundle (synchronisation between ldap and database) <ldap.rst>
Your bundle here ?
-------------------
The contributors still do not have a policy about those bundle integration, but we would like to be very open on this subject. Please write to us `or open an issue <https://redmine.champs-libres.coop/projects/chill/issues>`_.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._ldap-bundle:
LDAP bundle
###########
This bundle binds the database with an ldap directory.
The bundle synchronize the ldap directory with users in the database. It also
provides a way to check user credentials against the ldap directory.
..contents:: Table of content
:local:
Current limitations
*******************
- The length of the ldap dn must be < 255 characters
- if the username extracted from the ldap is updated, the changes are not reflected in the database and remains the same
Entities provided
*****************
This bundle provides only one entity : :class:`Chill\\LdapBundle\\Entity\\UserLdapBinding`
How the synchronizer works ?
****************************
#. The synchronizer performs a query on :code:`dn` and :code:`query` defined in the :ref:`configuration <configuration>`.
#. For each entry returned by the query, it looks if the :code:`dn` exists in the database
#. If the entry does not exists :
#. the synchronizer looks for user with same username as defined by :code:`username_attr`, and bind it with the :code:`dn` if it exists.
#. else, a user is created with username defined by :code:`username_attr` (if the ldap contains more than one attribute, the first attribute returned is used)
#. if a user exists which is already binded with the :code:`dn`, the entry is ignored.
#. The synchronizer looks for dn existing in database and which were not returned by the query performed in 1.
#. If they exists, those user are set to :code:`enabled=false`: they are not allowed to login.
Installation
************
This bundle requires :
- PHP LDAP ext
-:code:`symfony/ldap` with minimal version 3.1. Note that, currently, Chill uses Symfony 2.8: you should add the dependency on this single package manually
In your composer.json, for stable version :
..code-block::json
"require":{
// .. other dependencies
"symfony/ldap":"~3.1",
"chill-project/ldap":"~1.0"
}
And for dev version :
..code-block::json
"require":{
// .. other dependencies
"symfony/ldap":"~3.1",
"chill-project/ldap":"dev-master@dev"
}
.._configuration:
Configuration
**************
Configuration of the bundle
============================
..code-block::yaml
# Default configuration for extension with alias: "chill_ldap"
chill_ldap:
server:# Required
# the host of the ldap directory
host: ~ # Required, Example:localhost
# the port to reach the ldap directory
port:389
# the version of the ldap directory
version:3
# Is the use of ssl required to establish connection
use_ssl:false
# Is the use of startssl required to establish connection
use_starttls:false
# the user to bind to dn directory. Required for searching existing users.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._person-bundle:
Person bundle
#############
This bundle provides the ability to record people in the software. This bundle is required by other bundle.
..contents:: Table of content
:local:
Entities provided
*****************
..todo::
describe entities provided by person bundle
Search terms
************
The class `Chill\PersonBundle\Search\PersonSearch` provide the search module.
Domain
======
The search upon "person" is provided by default. The `@person` domain search may be omitted.
*`@person` is the domain search for people.
Arguments
=========
*`firstname` : provide the search on firstname. Example : `firstname:Depardieu`. May match part of the firstname (`firsname:dep` will match Depardieu)
*`lastname` : provide the search on lastname. May match part of the lastname.
*`birthdate` : provide the search on the birthdate. Example : `birthdate:1996-01-19`
*`gender`: performs search on man/woman. The accepted values are `man` or `woman`.
*`nationality` : performs search on nationality. Value must be a country code `as described in ISO 3166 <http://www.iso.org/iso/fr/home/standards/country_codes.htm>`_. Example : `nationality:FR`.
Default
=======
The default search is performed on firstname and/or lastname. Both are concatened before search. If values are separated by spaces, the clause `AND` is used : the search `dep ge` will match 'Gérard Depardieu` or 'Jean Depagelles', but not 'Charline Depardieu' (missing 'Ge' in word).
Configuration options
*********************
Those options are available under `chill_person` key.
Example of configuration:
..code-block::yaml
chill_person:
validation:
birthdate_not_after:P15Y
person_fields:
# note: visible is the default config. This key may be omitted if visible is chosen.
nationality:hidden
email:hidden
place_of_birth:visible
phonenumber:hidden
country_of_birth:hidden
marital_status:visible
spoken_languages:hidden
address:visible
birthdate_not_after *string*
The period duration before today during which encoding birthdate is not possible. The period is a string matching the format of `ISO_8601`, which is also use to build `DateInterval classes <http://php.net/manual/en/dateinterval.construct.php>`_.
Example: `P1D`, `P18Y`
Default value: `P1D` which means that birthdate before the current day (= yesterday) are allowed.
person_fields *array*
This define the visibility of some fields. By default, all fields are visible, but you can choose to hide some of them. Available keys are :
* `nationality`
* `country_of_birth`
* `place_of_birth`
* `phonenumber`
* `email`
* `marital_status`
* `spoken_languages`
* `address`
Possibles values: `hidden` or `visible` (all other value will raise an Exception).
Default value : `visible`, which means that all fields are visible.
Example:
..code-block::yaml
chill_person:
person_fields:
nationality:hidden
email:hidden
phonenumber:hidden
..note::
If all the field of a "box" are hidden, the whole box does not appears. Example: if the fields `phonenumber` and `email` are hidden, the title `Contact information` will be hidden in the UI.
..note::
If you hide multiple fields, for a better integration you may want to override the template, for a better appeareance. See `the symfony documentation <http://symfony.com/doc/current/book/templating.html#overriding-bundle-templates>`_ about this feature.
.._person-bundle-macros:
Macros
******
Sticker for a person
=====================
Macro file
`ChillPersonBundle:Person:macro.html.twig`
Macro envelope
:code:`render(p, withLink=false)`
:code:`p` is an instance of :class:`Chill\PersonBundle\Entity\Person`
:code:`withLink`:class:`boolean`
When to use this macro ?
When you want to represent a person.
Example usage :
.. code-block:: html+jinja
{% import "ChillPersonBundle:Person:macro.html.twig" as person_ %}
-f, --from=FROM The person id to delete, all associated data will be moved before
-t, --to=TO The person id which will received data
--dump-sql dump sql to stdout
--force execute sql instead of dumping it
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
-e, --env=ENV The Environment name. [default: "dev"]
--no-debug Switches off debug mode.
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Help:
Move all the associated entities on a "from" person to a "to" person and remove the old person
Move all the entities associated to a person onto another one, and remove the old person.
..warning::
Some entities are ignored and will be deleted:
- the accompanying periods ;
- the data attached to a person entity: name, address, date of birth, etc. Thos should be merge before the move.
It is advised to run first the command with the :code:`dump-sql` option and, then, use the :code:`force` option.
The moving and suppression is executed inside a transaction, ensuring no data loss if the migration fails.
..note::
Using bash and awk, it is easy to use a TSV file (values separated by a tab, not a comma) to create move commands. Assuming our file is named :code:`twins.tsv` and contains two columns: the first one with :code:`from` ids, and the second one with :code:`to` ids:
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Access controle model
**********************
..contents:: Table of content
:local:
Concepts
========
Every time an entity is created, viewed or updated, the software check if the user has the permission to make this action. The decision is made with three parameters :
- the type of entity ;
- the entity's center ;
- the entity'scope
The user must be granted access to the action on this particular entity, with this scope and center.
TL;DR
=====
Resolve scope and center
------------------------
In a service, resolve the center and scope of an entity
// all the method below are used to register roles into the admin part
publicfunctiongetRoles()
{
return[
self::CREATE,
self::SEE,
self::SEE_DETAILS,
self::UPDATE,
self::DELETE
];
}
publicfunctiongetRolesWithoutScope()
{
returnarray();
}
publicfunctiongetRolesWithHierarchy()
{
return['PersonDocument'=>$this->getRoles()];
}
}
From an user point of view
==========================
The software is design to allow fine tuned access rights for complicated installation and team structure. The administrators may also decide that every user has the right to see all resources, where team have a more simple structure.
Here is an overview of the model.
Chill can be multi-center
-------------------------
Chill is designed to be installed once for social center who work with multiple teams separated, or for social services's federation who would like to share the same installation of the software for all their members.
This was required for cost reduction, but also to ease the generation of statistics agregated across federation's members, or from the central unit of the social center with multiple teams.
Otherwise, it is not required to create multiple center: Chill can also work for one center.
Obviously, users working in the different centers are not allowed to see the entities (_persons_, _reports_, _activities_) of other centers. But users may be attached to multiple centers: consequently they will be able to see the entities of the multiple centers they are attached to.
Inside center, scope divide team
--------------------------------
Users are attached to one or more center and, inside to those center, there may exists differents scopes. The aim of those _scopes_ is to divide the whole team of social worker amongst different departement, for instance: the social team, the psychologist team, the nurse team, the administrative team, ... Each team is granted of different rights amongst scope. For instance, the social team may not see the _activities_ of the psychologist team. The administrative team may see the date & time's activities, but is not allowed to see the detail of those entities (the personal notes, ...).
The administrator is responsible of creating those scopes and team. *He may also decide to not define a division inside his team*: he creates only one scope and all entities will belong to this scope, all users will be able to see all entities.
As entities have only one scopes, if some entities must be shared across two different teams, the administrator will have to create a scope *shared* by two different team, and add the ability to create, view, or update this scope to those team.
Example: if some activities must be seen and updated between nurses and psychologists, the administrator will create a scope "nurse and psy" and add the ability for both team "nurse" and "psychologist" to "create", "see", and "update" the activities belonging to scope "nurse and psy".
Where does the ``scope`` and ``center`` comes from ?
Most often, scope and center comes from user's input:
* when person is created, Chill asks the associated center to the user. Then, every entity associated to the user (Activity, ...) is associated to this center;
* when an entity is created, Chill asks the associated scope.
The UI check the model before adding those input into form. If the user hae access to only one center or scope, this scope or center is filled automatically, and the UI does not ask the user. Most of the times, the user does not see "Pick a scope" and "Pick a center" inputs.
Scope and Center are associated to entities through ``ManyToOne`` properties, which are then mapped to ``FOREIGN KEY`` in tables, ...
But sometimes, this implementation does not fits the needs:
* persons are associated to center *geographically*: the address of each person contains lat/lon coordinates, and the center is resolved from this coordinated;
* some would like to associated persons to multiple center, or one center;
* entities are associated to scope through the job reached by "creator" (an user);
* some would like not to use scope at all;
* …
For this reasons, associated center and scopes must be resolved programmatically. The default implementation rely on the model association, as described above. But it becomes possible to change the behaviour on different implementations.
Is my entity "concerned" by scopes ?
------------------------------------
Some entities are concerned by scope, some not.
This is also programmatically resolved.
The concepts translated into code
===================================
..figure:: /_static/access_control_model.png
Schema of the access control model
Chill handle **entities**, like *persons*, *reports* (associated to *persons*), *activities* (also associated to *_persons*), ... On creation, those entities are linked to one center and, eventually, to one scope. They implements the interface `HasCenterInterface`.
..note::
Somes entities are linked to a center through the entity they are associated with. For instance, *activities* or *reports* are associated to a *person*, and the person is associated to a *center*. The *report*'s *center* is always the *person*'s *center*.
Entities may be associated with a scope. In this case, they implement the `HasScopeInterface`.
..note::
Currently, only the *person* entity is not associated with a scope.
At each step of his lifetime (creation, view of the entity and eventually of his details, update and, eventually, deletion), the right of the user are checked. To decide wether the user is granted right to execute the action, the software must decide with those elements :
- the entity's type;
- the entity's center ;
- the entity's scope, if it exists,
- and, obviously, a string representing the action
All those action are executed through symfony voters and helpers.
How to check authorization ?
============================
Just use the symfony way-of-doing, but do not forget to associate the entity you want to check access. For instance, in controller :
The class :class:`Chill\\MainBundle\\Security\\Authorization\\AuthorizationHelperInterface` helps you to get centers and scope reachable by a user.
Those methods are intentionnaly build to give information about user rights:
- getReachableCenters: to get reachable centers for a user
- getReachableScopes : to get reachable scopes for a user
Adding your own roles
---------------------
Extending Chill will requires you to define your own roles and rules for your entities. You will have to define your own voter to do so.
To create your own roles, you should:
* implement your own voter. This voter will have to extends the :class:`Chill\\MainBundle\\Security\\AbstractChillVoter`. As defined by Symfony, this voter must be declared as a service and tagged with `security.voter`;
* declare the role through implementing a service tagged with `chill.role` and implementing :class:`Chill\\MainBundle\\Security\\ProvideRoleInterface`.
..note::
Both operation may be done through a simple class: you can implements :class:`Chill\\MainBundle\\Security\\ProvideRoleInterface` and :class:`Chill\\MainBundle\\Security\\AbstractChillVoter` on the same class. See live example: :class:`Chill\\ActivityBundle\\Security\\Authorization\\ActivityVoter`, and similar examples in the `PersonBundle` and `ReportBundle`.
..seealso::
`How to Use Voters to Check User Permissions <http://symfony.com/doc/current/cookbook/security/voters_data_permission.html>`_
From the symfony cookbook
`New in Symfony 2.6: Simpler Security Voters <http://symfony.com/blog/new-in-symfony-2-6-simpler-security-voters>`_
From the symfony blog
Declare your role
^^^^^^^^^^^^^^^^^^
To declare new role, implement the class :class:`Chill\\MainBundle\\Security\\ProvideRoleInterface`.
..code-block::php
interfaceProvideRoleInterface
{
/**
* return an array of role provided by the object
*
* @return string[] array of roles (as string)
*/
publicfunctiongetRoles();
/**
* return roles which doesn't need
*
* @return string[] array of roles without scopes
*/
publicfunctiongetRolesWithoutScope();
}
Then declare your service with a tag `chill.role`. Example :
4. if the entity is associated to another entity, this entity should be, at least, viewable by the user.
Thats what we call the "autorization logic". But this logic may be replace by a new one, and developers should take care of it.
Then voter implementation should take care of:
* check the access to associated entities. For instance, if an ``Activity`` is associated to a ``Person``, the voter should first check that the user can show the associated ``Person``;
* as far as possible, delegates the check for associated center, scopes, and check for authorization using the authorization logic. VoterHelper will ease the most common operation of this logic.
Due to the fact that authorization model may be overriden, "list" and "index" pages should not rely on center and scope from controller. This must be delegated to dedicated service, which will be aware of the authorization model. We call them ``ACLAwareRepository``. This service must implements an interface, in order to allow to change the implementation.
The controller **must not** performs any DQL or SQL query.
The base implementation should separate the logic to allow an easy reuse. Here, the method ``buildQuery`` build a basic query without authorization logic, which can be re-used. The authorization logic is dedicated to a private method. For ease of user, the logic of adding ordering criterias and pagination parameters (``$start`` and ``$limit``) are also delegated to a public method.
If you are working on a shared bundle (aka "The chill bundles"), you should define your configuration inside the class :code:`ChillXXXXBundleExtension`, using the "prependConfig" feature:
The key :code:`single-collection` with value :code:`single` will add a :code:`/{id}/ + "action name"` (in this example, :code:`/{id}/participation`) into the path, after the base path. If the value is :code:`collection`, no id will be set, but the action name will be append to the path.
Then, create the corresponding action into your controller:
In ManyToOne association, you can add associated entities using the :code:`PATCH` request. By default, the serializer deserialize entities only with their id and discriminator type, if any.
Where this is relevant, this model should be re-used in custom controller actions.
In custom actions, this can be achieved quickly by assembling results into a :code:`Chill\MainBundle\Serializer\Model\Collection`. The pagination information is given by using :code:`Paginator` (see :ref:`Pagination <pagination-ref>`).
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._forms:
Assets
#######
The Chill assets (js, css, images, …) can be managed by `Webpack Encore`_, which is a thin wrapper for `Webpack`_ in Symfony applications.
Installation
************
Webpack Encore needs to be run in a Node.js environment, using the Yarn package manager. This Node.js environment can be set up using a node docker image. The bash script `docker-node.sh` set up a Node.js environment with an adequate configuration. Launch this container by typing:
..code-block::bash
$ bash docker-node.sh
In this NodeJS environment, install all the assets required by Chill with:
..code-block::bash
node@b91cab4f7cfc:/app$ yarn install
This command will install all the packages that are listed in `package.json`.
Any further required dependencies can be installed using the Yarn package. For instance, jQuery is installed by:
..code-block::bash
node@b91cab4f7cfc:/app$ yarn add jquery --dev
Usage
*****
Organize your assets
--------------------
Chill assets usually lives under the `/Resources/public` folder of each Chill bundle. The Webpack configuration set up in `webpack.config.js` automatically loads the required assets from the Chill bundles that are used.
For adding your own assets to Webpack, you must add an entry in the `webpack.config.js` file. For instance, the following entry will output a file `main.js` collecting the js code (and possibly css, image, etc.) from `./assets/main.js`.
..code-block::js
.addEntry('main','./assets/main.js')
To gather the css files, simply connect them to your js file, using `require`. The css file is seen as a dependency of your js file. :
..code-block::js
// assets/js/main.js
require('../css/app.css');
For finer configuration of webpack encore, we refer to the above-linked documentation.
Compile the assets
------------------
To compile the assets, run this line in the NodeJS container:
..code-block::bash
node@b91cab4f7cfc:/app$ yarn run encore dev
While developing, you can tell Webpack Encore to continuously watch the files you are modifying:
..code-block::bash
node@b91cab4f7cfc:/app$ yarn run encore dev --watch
Use the assets in the templates
--------------------------------
Any entry defined in the webpack.config.js file can be linked to your application using the symfony `asset` helper:
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._create-new-bundle:
Create a new bundle
*******************
Create your own bundle is not a trivial task.
The easiest way to achieve this is seems to be :
1. Prepare a fresh installation of the chill project, in a new directory
2. Create a new bundle in this project, in the src directory
3. Initialize a git repository **at the root bundle**, and create your initial commit.
4. Register the bundle with composer/packagist. If you do not plan to distribute your bundle with packagist, you may use a custom repository for achieve this [#f1]_
5. Move to a development installation, made as described in the :ref:`installation-for-development` section, and add your new repository to the composer.json file
6. Work as :ref:`usual <editing-code-and-commiting>`
..warning::
This part of the doc is not yet tested
TODO
..rubric:: Footnotes
..[#f1] Be aware that we use the Affero GPL Licence, which ensure that all users must have access to derivative works done with this software.
To leave the bundle auto-configure the ``chill_main`` bundle, you can `prepend the configuration of the ChillMain Bundle <https://symfony.com/doc/current/bundles/prepend_extension.html>`_:
Some steps may be customized by overriding the default controller and some methods. Here, we will override the way the entity is created, and the ordering of the "index" page:
* we will associate a parent ClosingMotive to the element if a parameter `parent_id` is found ;
* we will order the ClosingMotive by the ``ordering`` property
The bundle person provide some controller and template you can override, instead of the ones present in the mainbundle:
*:code:`Chill\PersonBundle\CRUD\Controller\EntityPersonCRUDController` for entities linked with a one-to-may association to :code:`Person` class ;
*:code:`Chill\PersonBundle\CRUD\Controller\OneToOneEntityPersonCRUDController` for entities linked with a one-to-one association to :code:`Person` class.
There are also template defined under ``@ChillPerson/CRUD/`` namespace.
Those controller assume that:
* the entity provide the method :code:`getPerson` and :code:`setPerson` ;
* the `index`'s id path will be the id of the person, and the ids in `view` and `edit` path will be the id of the entity ;
This bundle also use by default the templates inside ``@ChillPerson/CRUD/``.
# the method name to call in the route. Will be set to the action name if left empty.
controller_action: null # Example: 'action'
# the path that will be **appended** after the base path. Do not forget to add arguments for the method. Will be set to the action name, including an `{id}` parameter if left empty.
path: null # Example: /{id}/my-action
# the requirements for the route. Will be set to `[ 'id' => '\d+' ]` if left empty.
requirements: []
# the role that will be required for this action. Override option `base_role`
The embeddable proposed by Doctrine does not support relationship to other entities. The entity Comment is able to render a user's id, but not an User object.
..code-block::php
$activity->getComment()->getUserId();// return user id of the last author
$activity->getComment()->getUser();// does not work !
Usage into form
===============
Use the :class:`Chill\MainBundle\Form\Type\CommentType` to load the form widget:
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Exports
*******
Export is an important issue for the Chill software : users should be able to :
- compute statistics about their activity ;
- list "things" which make part of their activities.
The `main bundle`_ provides a powerful framework to build custom queries with re-usable parts across differents bundles.
..contents:: Table of content
:local:
..seealso::
`The issue where this framework was discussed <https://git.framasoft.org/Chill-project/Chill-Main/issues/9>`_
Provides some information about the pursued features and architecture.
Concepts
========
Some vocabulary: 3 "Export elements"
------------------------------------
Four terms are used for this framework :
exports
provides some basic operation on the date. Two kind of exports are available :
- computed data : it may be "the number of people", "the number of activities", "the duration of activities", ...
- list data : it may be "the list of people", "the list of activity", ...
filters
The filters make a filter on the date: it removes some information the user doesn't want to introduce in the computation done by export. In other word, filters make a filter...
Example of filter: "people under 18 years olds", "activities between the 1st of June and the 31st December", ...
aggregators
The aggregator aggregates the data into some group (some software use the term 'bucket').
Example of aggregator : "group people by gender", "group people by nationality", "group activity by type", ...
formatters
The formatters format the data into a :class:`Symfony\Component\HttpFoundation\Response`, which will be returned "as is" by the controller to the web client.
Example of formatter: "format data as CSV", "format data as ods spreadsheet", ...
Anatomy of an export
---------------------
An export may be explained as a sentence, where each part of this sentence refers to one or multiple exports element. Examples :
**Example 1**: Count the number of people having at least one activity in the last 12 month, and group them by nationality and gender, and format them in a CSV spreadsheet.
Here :
-*count the number of people* is the export part
-*having at least one activity* is the filter part
-*group them by nationality* is the aggregator part
-*group them by gender* is a second aggregator part
-*format the date in a CSV spreadsheet* is the formatter part
Note that :
- aggregators, filters, exports and aggregators are cross-bundle. Here the bundle *activity* provides a filter which apply on an export provided by the person bundle ;
- there may exists multiple aggregator or filter for one export. Currently, only one export is allowed.
**Example 2**: Count the average duration of an activity with type "meeting", which occurs between the 1st of June and the 31st of December, group them by week, and format the data in a OpenDocument spreadsheet.
Here :
-*count the average duration of an activity* is the export part
-*activity with type meeting* is a filter part
-*activity which occurs between the 1st of June and the 31st of December* is a filter
-*group them by week* is the aggregator part
-*format the date in an OpenDocument spreadsheet* is the formatter part
The result might be :
+-----------------------+----------------------+
| Week | Number of activities |
+=======================+======================+
| 2015-10 | 10 |
+-----------------------+----------------------+
| 2015-11 | 12 |
+-----------------------+----------------------+
| 2015-12 | 10 |
+-----------------------+----------------------+
| 2015-13 | 9 |
+-----------------------+----------------------+
Authorization and exports
-------------------------
Exports, filters and aggregators should not make see data the user is not allowed to see.
In other words, developers are required to take care of user authorization for each export.
It should exists a special role that should be granted to users which are allowed to build exports. For more simplicity, this role should apply on center, and should not requires special circles.
How does the magic works ?
===========================
To build an export, we rely on the capacity of the database to execute queries with aggregate (i.e. GROUP BY) and filter (i.e. WHERE) instructions.
An export is an SQL query which is initiated by an export, and modified by aggregators and filters.
..note::
**Example**: Count the number of people having at least one activity in the last 12 month, and group them by nationality and gender
1. The report initiate the query
..code-block::SQL
SELECTcount(people.*)FROMpeople
2. The filter add a where and join clause :
..code-block::SQL
SELECTcount(people.*)FROMpeople
RIGHTJOINactivity
WHEREactivity.dateISBETWEENnowAND6monthago
3. The aggregator "nationality" add a GROUP BY clause and a column in the SELECT statement:
Each filter, aggregator and filter may collect parameters from the user by providing a form. This form is appended to the export form. Here is an example.
The screenshot show the export form for ``CountPeople`` (Nombre de personnes). The filter by date of birth is checked (*Filtrer par date de naissance de la personne*), which allow to show a subform, which is provided by the :class:`Chill\PersonBundle\Export\Filter\BirthdateFilter`. The other filter, which are unchecked, does not show the subform.
Two aggregators are also checked : by Country of birth (*Aggréger les personnes par pays de naissance*, corresponding class is :class:`Chill\PersonBundle\Export\Aggregator\CountryOfBirthAggregator`, which also open a subform. The aggregator by gender (*Aggréger les personnes par genre*) is also checked, but there is no corresponding subform.
The Export Manager
------------------
The Export manager (:class:`Chill\MainBundle\Export\ExportManager` is the central class which register all exports, aggregators, filters and formatters.
The export manager is also responsible for orchestrating the whole export process, producing a :class:`Symfony\FrameworkBundle\HttpFoundation\Request` to each export request.
The export form step
--------------------
The form step allow to build a form, aggregating different parts of the module.
The building of forms is separated between different subform, which are responsible for rendering their part of the form (aggregators, filters, and export).
..figure:: /_static/puml/exports/form_steps.png
:scale:40%
The formatter form step
-----------------------
The formatter form is processed *after* the user filled the export form. It is built the same way, but receive in parameters the data entered by the user on the previous step (i.e. export form). It may then adapt it accordingly (example: show a list of columns selected in aggregators).
Processing the export
---------------------
The export process may be explained by this schema :
***Line 36**: the ``getType`` function return a string. This string will be used to find the aggregtors and filters which will apply to this export.
***Line 41**: a simple description to help user to understand what your export does.
***Line 46**: The title of the export. A summary of what your export does.
***Line 51**: The list of roles requires to execute this export.
***Line 56**: We initiate the query here...
***Line 59**: We have to filter the query with centers the users checked in the form. We process the $acl variable to get all ``Center`` object in one array
***Line 63**: We create the query, with a query builder.
***Line 74**: We simply returns the result, but take care of hydrating the results as an array.
***Line 103**: return the list of formatters types which are allowed to apply on this filter
Filters
-------
This is an example of the *filter by birthdate*. This filter ask some information in a form (`buildForm` is not empty), and this form must be validated. To performs this validations, we implement a new Interface: :class:`Chill\MainBundle\Export\ExportElementValidatedInterface`:
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Development
###########
As Chill rely on the `symfony <http://symfony.com>`_ framework, reading the framework's documentation should answer most of your questions. We are explaining here some tips to work with Chill, and things we provide to encounter our needs.
..toctree::
:maxdepth:2
Instructions to create a new bundle <create-a-new-bundle.rst>
CRUD (Create - Update - Delete) for one entity <crud.rst>
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Localisation
*************
Language in url
===============
Language should be present in URL, conventionnaly as first argument.
..code-block::none
/fr/your/url/here
This allow users to change from one language to another one on each page, which may be useful in multilanguages teams. If the installation is single-language, the language switcher will not appears.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Routing and menus
*****************
The *Chill*'s architecture allows to choose bundle on each installation. This may lead to a huge diversity of installations, and a the developper challenge is to make his code working with all those possibles installations.
*Chill* uses menus to let users access easily to the most used functionalities. For instance, when you land on a "Person" page, you may access directly to his activities, notes, documents, ... in a single click on a side menu.
For a developer, it is easy to extend this menu with his own entries.
..seealso::
`Symfony documentation about routing <http://symfony.com/doc/current/book/routing.html>`_
This documentation should be read before diving into those lines
`Routes dans Chill <https://redmine.champs-libres.coop/issues/179>`_ (FR)
The issue where we discussed routes. In French.
Create routes
==============
..note::
We recommand using `yaml` to define routes. We have not tested the existing other ways to create routes (annotations, ...). Help wanted.
The first step is as easy as create a route in symfony, and add some options in his description :
label:foolabel#the label shown on menu. Will be translated
otherkey:othervalue#you may add other informations, as needed by your layout
bar:#must also appears in menu named 'bar'
order:500
label:barlabel
The mandatory parameters under the `menus` definition are :
*`name`: the menu's name, defined as an key for the following entries
*`order`. Note: if we have duplicate order's values, the order will be incremented. We recommand using big intervals within orders and publishing the orders in your documentation
*`label`: the text which will be rendered inside the `<a>` tag. The label should be processed trough the `trans` filter (`{{ route.label|trans }}`)
You *may* also add other keys, which will be used optionally in the way the menu is rendered. See
..warning::
Although all keys will be kept from your `yaml` definition to your menu template, we recommend not using those keys, which are reserved for a future implementations of Chill :
*`helper`, a text to help user or add more informations to him
*`access` : which will run a test with `Expression Langage <http://symfony.com/doc/current/components/expression_language/index.html>`_ to determine if the user has the ACL to show the menu entry ;
*`condition`, which will test with the menu context if the entry must appears
Show menu in twig templates
===========================
To show our previous menu in the twig template, we invoke the `chill_menu` function. This will render the `foo` menu :
..code-block::jinja
{{chill_menu('foo')}}
Passing variables
^^^^^^^^^^^^^^^^^
If your routes need arguments, i.e. an entity id, you should pass the as argument to the chill_menu function. If your route's pattern is `/person/{personId}`, your code become :
Of course, `person` is a variable you must define in your code, which should have an `id` accessible property (i.e. : `$person->getId()`).
..note::
Be aware that your arguments will be passed to all routes in a menu. If a route does not require `personId` in his pattern, the route will become `/pattern?personId=XYZ`. This should not cause problem in your application.
..warning::
It is a good idea to reuse the same parameter's name in your pattern, to avoid collision. Prefer `/person/{personId}` to `/person/{id}`.
If you don't do that and another developer create a bundle with `person/{personId}/{id}` where `{id}` is the key for something else, this will cause a lot of trouble...
Rendering active entry
^^^^^^^^^^^^^^^^^^^^^^
Now, you want to render differently the *active* route of the menu [#f1]_. You should, in your controller or template, add the active route in your menu :
* The `args` value are the value passed in the 'args' arguments requested by the `chill_menu` function.
*`activeRouteKey` is the key of the currently active route.
*`routes` is an array of routes. The array has this structure: `routes[order] = { 'key' : 'the_route_key', 'label' : 'the route label' }` The order is *resolved*: in case of collision (two routes from different bundles having the same order), the order will be incremented. You may find in the array your own keys (`{ 'otherkey' : 'othervalue'}` in the example above).
Then, you will call your own template with the `layout` argument :
*`order` (mandatory) : the order in the menu. It is preferrable to increment by far more than 1.
*`label` (mandatory) : a translatable string.
*`helper` (optional) : a text to help people to understand what does the menu do. Not used in default implementation.
*`condition` (optional) : an `Expression Language <http://symfony.com/doc/current/components/expression_language/index.html> `_ which will make the menu appears or not. Typically, it may be used to say "show this menu only if the person concerned is more than 18". **Not implemented yet**.
*`access` (optional) : an Expression Language to evalute the possibility, for the user, to show this menu according to Access Control Model. **Not implemented yet.**
You may add additional keys, but should not use the keys described above.
You may customize menu rendering by using the `layout` option.
.. warning ::
TODO : this part should be written.
.._caveats :
Caveats
=======
Currently, you may pass arguments globally to each menu, and they will be all passed to route url. This means that :
* the argument name in the route entry must match the argument key in menu declaration in twig template
* if an argument is missing to generate an url, the url generator will throw a `Symfony\Component\Routing\Exception\MissingMandatoryParametersException`
* if the argument name is not declared in route entry, it will be added to the url, (example: `/my/route?additional=foo`)
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Database Migrations
********************
Every bundle potentially brings his own database operations : to persist entities, developers have to create database schema, creating indexes,...
Those schema might be changed (the less is the better) from time to time.
Consequence: each bundle should bring his own migration files, which will bring the database consistent with the operation you will run in your code. They will be gathered into the app installation, ready to be executed by the chill's installer.
Currently, we use `doctrine migration`_ to manage those migration files. A `composer`_ script located in the **chill standard** component will copy the migrations from your bundle to the doctrne migration's excepted directory after each install and/or update operation.
..seealso::
The `doctrine migration`_ documentation
Learn concepts about migrations files and scripts and the doctrine ORM
The `doctrine migration bundle`_ documentation
Learn about doctrine migration integration with Symfony framework
Shipping migration files
========================
Migrations files should be shipped under the Resource/migrations directory. You could customize the migration directory by adding extra information in your composer.json:
..code-block::json
"extra":{
"migration-source":"path/to/my/dir"
}
The class namespace should be `Application\Migrations`, as expected by doctrine migration. Only the files which will be executed by doctrine migration will be moved: they must have the pattern `VersionYYYYMMDDHHMMSS.php` where YYYY is the year, MM the month, DD the day, HH the hour, MM the month and SS the second of creation.
They will be moved automatically by composer when you install or update a bundle.
Executing migration files
==========================
The installers will have to execute migrations files manually, running
..code-block::bash
php app/console doctrine:migrations:status #will give the current status of the database
php app/console doctrine:migrations:migrate #process the update
Updating migration files
=========================
..warning::
After an installation, migration files will be executed and registered as executed in the database (the version timestamp is recorded into the :title:`migrations_versions` table). If you update your migration file code, the file will still be considered as "executed" by doctrine migration, which will not offers the possibility to run the migration again.
Consequently, updating migration file should only be considered during development phase, and not published on public git branches. If you want to edit your database schema, you should create a new migration file, with a new timestamp, which will proceed to your schema adaptations.
Every time a migration file is discovered, the composer'script will check if the migration exists in the local migration directory. If yes, the script will compare two file for changes (using a md5 hash). If migrations are discovered, the script will ask the installer to know if he must replace the file or ignore it.
..note::
You can manually run composer script by launching `composer run-script post-update-cmd` from your root chill installation's directory.
Each time you create a migration script, you should ensure that it will not lead to data losing. Eventually, feel free to use intermediate steps.
Generation
----------
You can generate migration file from the command line, using those commands:
*`php app/console doctrine:migrations:diff` to generate a migration file by comparing your current database to your mapping information
*`php app/console doctrine:migrations:generate` to generate a blank migration file.
Those files will be located into `app/DoctrineMigrations` directory. You will have to copy those file to your the directory `Resources/migrations` into your bundle directory.
Comments and documentation
--------------------------
As files are copied from your bundle to the `app/DoctrineMigrations` directory, the link between your bundle and the copied file will be unclear. Please add all relevant documentation which will allow future developers to make a link between your file and your bundle.
Inside the script
-----------------
The script which move the migrations files to app directory `might be found here
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
.._pagination-ref:
Pagination
##########
The Bundle :code:`Chill\MainBundle` provides a **Pagination** api which allow you to easily divide results list on different pages.
A simple example
****************
In the controller, get the :code:`Chill\Main\Pagination\PaginatorFactory` from the `Container` and use this :code:`PaginatorFactory` to create a :code:`Paginator` instance.
..literalinclude:: pagination/example.php
:language:php
Then, render the pagination using the dedicated twig function.
The function :code:`chill_pagination` will, by default, render a link to the 10 previous page (if they exists) and the 10 next pages (if they exists). Assuming that we are on page 5, the function will render a list to ::
Internally, the :code:`$paginator` object has a link to the :code:`Request` object, and it reads the :code:`page` parameter which contains the current page number. If this parameter is not present, the :code:`$paginator` assumes that we are on page 1.
..figure:: /_static/puml/pagination-sequence.png
The :code:`$paginator` get the current page from the request.
Where does the :code:`$paginator` get the number of items per page ?
As above, the :code:`$paginator` can get the number of items per page from the :code:`Request`. If none is provided, this is given by the configuration which is, by default, 50 items per page.
:code:`PaginatorFactory`, :code:`Paginator` and :code:`Page`
The :code:`PaginatorFactory` may create more than one :code:`Paginator` in a single action. Those :code:`Paginator` instance may redirect to different routes and/or routes parameters.
..code-block::php
// create a paginator for the route 'my_route' with some parameters (arg1 and arg2)
The paginator has some function to give the number of pages are required to displayed all the results, and give some information about the number of items per page :
..code-block::php
// how many page count this paginator ?
$paginator->countPages();// return 20 in our example
// we may get the number of items per page
$paginator->getItemsPerPage();// return 20 in our example
A :code:`Paginator` instance create instance of :code:`Page`, each :code:`Page`, which is responsible for generating the URL to the page number it represents. Here are some possibilities using :code:`Page` and :code:`Paginator` :
..code-block::php
// get the current page
$page=$paginator->getCurrentPage();
// on which page are we ?
$page->getNumber();// return 5 in this example (we are on page 5)
$page->getFistItemNumber();// return 101 in our example (20 items per page)
// what is the last item number on this page ?
$page->getLastItemNumber();// return 120 in our example
// we can access directly the next and current page
if($paginator->hasNextPage()){
$next=$paginator->getNextPage();
}
if($paginator->hasPreviousPage()){
$previous=$paginator->getPreviousPage();
}
// we can access directly to a given page number
if($paginator->hasPage(10)){
$page10=$paginator->getPage(10);
}
// we can iterate over our pages through a generator
foreach($paginator->getPagesGenerator()as$page){
$page->getNumber();
}
// check that a page object is the current page
$paginator->isCurrentPage($page);// return false
..warning::
When calling a page which does not exists, the :code:`Paginator` will throw a `RuntimeException`. Example :
..code-block::php
// our last page is 10
$paginator->getPage(99);// out of range => throw `RuntimeException`
// our current page is 1 (the first page)
$paginator->getPreviousPage;// does not exists (the fist page is always 1) => throw `RuntimeException`
..note::
When you create a :code:`Paginator` for the current route and route parameters, the :code:`Page` instances will keep the same parameters and routes :
..code-block::php
// assuming our route is 'my_route', for the pattern '/my/{foo}/route',
// and the current route is '/my/value/route?arg2=bar'
// create a paginator for the current route and route parameters :
$paginator=$paginatorFactory->create($total);
// get the next page
if($paginator->hasNext()){
$next=$paginator->getNextPage();
// get the route to the page
$page->generateUrl();// will print 'my/value/route?arg2=bar&page=2'
}
Having a look to the `full classes documentation may provide some useful information <http://api.chill.social/Chill-Main/master/namespace-Chill.MainBundle.Pagination.html>`_.
Customizing the rendering of twig's :code:`chill_pagination`
The template will receive the :code:`$paginator` as :code:`paginator` variable. Let's have a look `at the current template <https://framagit.org/Chill-project/Chill-Main/blob/master/Resources/views/Pagination/long.html.twig>`_.
Some entity need to be rendered automatically for a couple of times: a person, a user, ...
One can use some twig filter to render those entities:
..code-block::twig
{{person|chill_entity_render_box}}
Define a renderer
=================
By default, the object passed through the renderer will be rendered using the :code:`__toString()` method. To customize this behaviour, you have to define a service and tag it using :code:`chill.render_entity`.
The rendered is implemented using :class:`Chill\MainBundle\Templating\Entity\ChillEntityRenderInterface`. This interface has 3 methods:
*:code:`public function supports($entity, array $options): bool`: return true if the :code:`$entity` given in parameter, with custom options, is supported by this renderer;
*:code:`public function renderString($entity, array $options): string`: render the entity as a single string, for instance in a select list;
*:code:`public function renderBox($entity, array $options): string`: render the entity in an html box.
..warning::
The HTML returned by :code:`renderBox`**MUST BE SAFE** of any XSS injection.
:class:`Chill\MainBundle\Templating\Entity\AbstractChillEntityRender` provides some useful methods to get the opening and closing boxes that should be used.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Routing
#######
Our goal is to ease the installation of the different bundle. Users should not have to dive into complicated config files to install bundles.
A routing loader available for all bundles
===========================================
A Chill bundle may rely on the Routing Loader defined in ChillMain.
The loader will load `yml` or `xml` files. You simply have to add them into `chill_main` config
..code-block::yaml
chill_main:
# ... other stuff here
routing:
resources:
- @ChillMyBundle/Resources/config/routing.yml
Load routes automatically
-------------------------
But this force users to modify config files. To avoid this, you may prepend config implementing the `PrependExtensionInterface` in the `YourBundleExtension` class. This is an example from **chill main** bundle :
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Run tests
*********
In reason of the Chill architecture, test should be runnable from the bundle's directory and works correctly: this will allow continuous integration tools to run tests automatically.
From chill app
==============
This is the most convenient method for developer: run test for chill bundle from the main app.
Those tests needs the whole symfony app to execute Application Tests (which test html page).
For ease, the app is cloned using a :code:`git submodule`, which clone the main app into :code:`tests/app`, and tests are bootstrapped to this app. The dependencies are also installed into `tests/app/vendor` to ensure compliance with relative path from this symfony application.
You may boostrap the tests fro the chill bundle this way:
..code-block::bash
# ensure to be located into the environement (provided by docker suits well)
docker-compose exec --user $(id -u) php bash
# go to chill subdirectory
cd vendor/chill-project/chill-bundles
# install submodule
git submodule init
git submodule update
# install composer and dependencies
curl -sS https://getcomposer.org/installer | php
# run tests
bin/phpunit
..note::
If you are on a fresh install, you will need to migrate database schema.
The path to console tool must be adapted to the app. To load migration and add fixtures, one can execute the following commands:
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Searching
*********
Chill should provide information needed by users when they need it. Searching within bundle, entities,... is an important feature to achieve this goal.
The Main Bundle provide interfaces to ease the developer work. It will also attempt that search will work in the same way accross bundles.
..contents:: Table of content
:local:
..seealso::
`Our blog post about searching (in French) <http://blog.champs-libres.coop/vie-des-champs/2015/01/06/va-chercher-chill-la-recherche-dans-chill-logiciel-libre-service-social.html>`_
This blog post give some information for end-users about searching.
`The issue about search behaviour <https://redmine.champs-libres.coop/issues/377>`_
Where the search behaviour is defined.
Searching in a glance for developers
====================================
Chill suggests to use an easy-to-learn language search.
..note::
We are planning to provide a form to create automatically search pattern according to this language. Watch the `issue regarding this feature <https://redmine.champs-libres.coop/issues/389>`_.
The language is an association of search terms. Search terms may contains :
-**a domain**: this is "the domain you want to search" : it may some entities like people, reports, ... Example : `@person` to search accross people, `@report` to browse reports, ... The search pattern may have **a maximum of one** domain by search, providing more should throw an error, and trigger a warning for users.
-**arguments and their values** : This is "what you search". Arguments narrow the search to specific fields : username, date of birth, nationality, ... The syntax is `argument:value`. I.e.: ` birthdate:2014-12-15`, `firstname:Depardieu`, ... **Arguments are optional**. If the value of an argument contains spaces or characters like punctuation, quotes ("), the value should be provided between parenthesis : `firstname:(Van de snoeck)`, `firstname:(M'bola)`, ...
-**default value** : this the "rest" of the search, not linked with any arguments or domain. Example : `@person dep` (`dep` is the "default value"), or simply `dep` if any domain is provided (which is perfectly acceptable). If a string is not idenfied as argument or domain, it will be present in the "default" term.
If a search pattern (provided by the user) does not contains any domain, the search must be run across default domain/search modules.
A domain may be supported by different search modules. For instance, if you provide the domain `@person`, the end-user may receive results of exact firstname/lastname, but also result with spelling suggestion, ... **But** if results do not fit into the first page (if you have 75 results and the screen show only 50 results), the next page should contains only the results from the required module.
For instance : a user search across people by firstname/lastname, the exact spelling contains 10 results, the "spelling suggestion" results contains 75 names, but show only the first 50. If the user want to see the last 25, the next screen should not contains the results by firstname/lastname.
Allowed characters as arguments
===============================
In order to execute regular expression, the allowed chararcters in arguments are a-z characters, numbers, and the sign '-'. Spaces and special characters like accents are note allowed (the accents are removed during parsing).
Special characters and uppercase
================================
The search should not care about lowercase/uppercase and accentued characters. Currently, they are removed automatically by the `chill.main.search_provider`.
Implementing search module for dev
===================================
To implement a search module, you should :
- create a class which implements the `Chill\MainBundle\Search\SearchInterface` class. An abstract class `Chill\MainBundle\Search\AbstractSearch` will provide useful assertions for parsing date string to `DateTime` objects, ...
- register the class as a service, and tag the service with `chill.search` and an appropriate alias
The search logic is provided under the `/search` route.
..seealso::
`The implementation of a search module in Person bundle <https://github.com/Chill-project/Person/blob/master/Search/PersonSearch.php>`_
An example of implementationhttps://github.com/Chill-project/Main/blob/master/DependencyInjection/SearchableServicesCompilerPass.php
..note::
**Internals explained** : the services tagged with `chill.search` are gathered into the `chill.main.search_provider` service during compilation (`see the compiler pass <https://github.com/Chill-project/Main/blob/master/DependencyInjection/SearchableServicesCompilerPass.php>`_).
The `chill.main.search_provider` service allow to :
- retrieve all results (as html string) for all search module concerned by the search (according to the domain provided or modules marked as default)
// you should implement the `count` function somewhere :-)
'total'=>$this->count($terms)
));
}
}
Values for :code:`$options`
^^^^^^^^^^^^^^^^^^^^^^^^^^^
:code:`$options` is an array with the following keys:
-:code:`SearchInterface::SEARCH_PREVIEW_OPTION` (bool): if the current view is a preview (the first 5 results) or not ;
-:code:`SearchInterface::REQUEST_QUERY_PARAMETERS` (bool): some parameters added to the query (under the key :code:`SearchInterface::REQUEST_QUERY_KEY_ADD_PARAMETERS`) and that can be interpreted. Used, for instance, when calling a result in json format when searching for interactive picker form.
Structure of array `$term`
^^^^^^^^^^^^^^^^^^^^^^^^^^
The array term is parsed automatically by the `main.chill.search_provider` service.
..note::
If you need to parse a search pattern, you may use the function `parse($pattern)` provided by the service.
The array `$term` have the following structure after parsing :
..code-block::php
array(
'_domain'=>'person',//the domain, without the '@'
'argument1'=>'value',//the argument1, with his value
'argument2'=>'my value with spaces',//the argument2
'_default'=>'abcde ef'// the default term
);
The original search would have been : `@person argument1:value argument2:(my value with spaces) abcde ef`
..warning::
The search values are always unaccented.
Returning a result in json
^^^^^^^^^^^^^^^^^^^^^^^^^^
The json format is mainly used by "select2" widgets.
When returning a result in json, the SearchInterface should only return an array with following keys:
-:code:`more` (bool): if the search has more result than the current page ;
-:code:`results` (array): a list of result, where:
-:code:`text` (string): the text that should be displayed in browser ;
-:code:`id` (string): the id of the entity.
Register the service
--------------------
You should add your service in the configuration, and add a `chill.search` tag and an alias.
Example :
..code-block::yaml
services:
chill.person.search_person:
class:Chill\PersonBundle\Search\PersonSearch
#your logic here
tags:
- {name: chill.search, alias:'person_regular'}
The alias will be used to get the results narrowed to this search module, in case of pagination (see above).
Parsing date
============
The class `Chill\MainBundle\Search\AbstractSearch` provides a method to parse date :
..code-block::php
//from subclasses
$date=$this->parseDate($string);
`$date` will be an instance of `DateTime <http://php.net/manual/en/class.datetime.php>`_.
..seealso::
`The possibility to add periods instead of date <https://redmine.champs-libres.coop/issues/390>`_
Which may be a future improvement for search with date.
Exceptions
==========
The logic of the search is handled by the controller for the `/search` path.
You should throw those Exception from your instance of `SearchInterface` if needed :
Chill\MainBundle\Search\ParsingException
If the terms does not fit your search logic (for instance, conflicting terms)
Expected behaviour
==================
Operators between multiple terms
--------------------------------
Multiple terms should be considered are "AND" instructions :
@person nationality:RU firstname:dep
the people having the Russian nationality AND having DEP in their name
@person birthdate:2015-12-12 charles
the people having 'charles' in their name or firstname AND born on December 12 2015
Spaces in default
-----------------
Spaces in default terms should be considered as "AND" instruction
@person charle dep
people having "dep" AND "charles" in their firstname or lastname. Match "Charles Depardieu" but not "Gérard Depardieu" ('charle' is not present)
Rendering
---------
The rendering should contains :
- the total number of results ;
- the search pattern in the search language. The aim of this is to let users learn the search language easily.
- a title
Frequently Asked Questions (FAQ)
================================
Why renderResults returns an HTML string and not structured array ?
It seems that the form of results may vary (according to access-right logic, ...) and is not easily structurable
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Timelines
*********
..contents:: Table of content
:local:
Concept
=======
From an user point of view
--------------------------
Chill has two objectives :
* make the administrative tasks more lightweight ;
* help social workers to have all information they need to work
To reach this second objective, Chill provides a special view: **timeline**. On a timeline view, information is gathered and shown on a single page, from the most recent event to the oldest one.
The information gathered is linked to a *context*. This *context* may be, for instance :
* a person : events linked to this person are shown on the page ;
* a center: events linked to a center are shown. They may concern different peoples ;
* ...
In other word, the *context* is the kind of argument that will be used in the event's query.
Let us recall that only the data the user has allowed to see should be shown.
..seealso::
`The issue where the subject was first discussed <https://redmine.champs-libres.coop/issues/224>`_
For developers
--------------
The `Main` bundle provides interfaces and services to help to build timelines.
If a bundle wants to *push* information in a timeline, it should be create a service which implements `Chill\MainBundle\Timeline\TimelineProviderInterface`, and tag is with `chill.timeline` and arguments defining the supported context (you may use multiple `chill.timeline` tags in order to support multiple context with a single service/class).
If a bundle wants to provide a new context for a timeline, the service `chill.main.timeline_builder` will helps to gather timeline's services supporting the defined context, and run queries across the models.
.._understanding-queries :
Understanding queries
^^^^^^^^^^^^^^^^^^^^^
Due to the fact that timelines should show only the X last events from Y differents tables, queries for a timeline may consume a lot of resources: at first on the database, and then on the ORM part, which will have to deserialize DB data to PHP classes, which may not be used if they are not part of the "last X events".
To avoid such load on database, the objects are queried in two steps :
1. An UNION request which gather the last X events, ordered by date. The data retrieved are the ID, the date, and a string key: a type. This type discriminates the data type.
2. The PHP objects are queried by ID, the type helps the program to link id with the kind of objects.
Those methods should ensure that only X PHP objects will be gathered and build by the ORM.
What does the master timeline builder service ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When the service `chill.main.timeline_builder` is instanciated, the service is informed of each service taggued with `chill.timeline` tags. Then,
1. The service build an UNION query by assembling column and tables names provided by the `fetchQuery` result ;
2. The UNION query is run, the result contains an id and a type for each row (see :ref:`above <understanding-queries>`)
3. The master service gather all id with the same type. Then he searches for the `chill.timeline`'s service which will be able to get the entities. Then, the entities will be fetched using the `fetchEntities` function. All entities are gathered in one query ;
4. The information to render entities in HTML is gathered by passing entity, one by one, on `getEntityTemplate` function.
Pushing events to a timeline
=============================
To push events on a timeline :
1. Create a class which implements `Chill\MainBundle\Timeline\TimelineProviderInterface` ;
2. Define the class as a service, and tag the service with `chill.timeline`, and define the context associated with this timeline (you may add multiple tags for different contexts).
Implementing the TimelineProviderInterface
------------------------------------------
The has the following signature :
..code-block::php
namespaceChill\MainBundle\Timeline;
interfaceTimelineProviderInterface
{
/**
*
* @param string $context
* @param mixed[] $args the argument to the context.
* @return TimelineSingleQuery
* @throw \LogicException if the context is not supported
*/
publicfunctionfetchQuery($context,array$args);
/**
* Indicate if the result type may be handled by the service
*
* @param string $type the key present in the SELECT query
* @return boolean
*/
publicfunctionsupportsType($type);
/**
* fetch entities from db into an associative array. The keys **MUST BE**
* the id
*
* All ids returned by all SELECT queries
* (@see TimeLineProviderInterface::fetchQuery) and with the type
* supported by the provider (@see TimelineProviderInterface::supportsType)
* will be passed as argument.
*
* @param array $ids an array of id
* @return mixed[] an associative array of entities, with id as key
*/
publicfunctiongetEntities(array$ids);
/**
* return an associative array with argument to render the entity
* in an html template, which will be included in the timeline page
*
* The result must have the following key :
*
* - `template` : the template FQDN
* - `template_data`: the data required by the template
The fetchQuery function help to build the UNION query to gather events. This function should return an instance of :code:`TimelineSingleQuery`. For you convenience, this object may be build using an associative array with the following keys:
*`id` : the name of the id column
*`type`: a string to indicate the type
*`date`: the name of the datetime column, used to order entities by date
*`FROM`: the FROM clause. May contains JOIN instructions
*`WHERE`: the WHERE clause;
*`parameters`: the parameters to pass to the query
The parameters should be replaced into the query by :code:`?`. They will be replaced into the query using prepared statements.
`$context` and `$args` are defined by the bundle which will call the timeline rendering. You may use them to build a different query depending on this context.
For instance, if the context is `'person'`, the args will be this array :
'centers'=>[]// an array of \Chill\MainBundle\Entity\Center entities
);
You should find in the bundle documentation which contexts are arguments the bundle defines.
..note::
We encourage to use `ClassMetaData` to define column names arguments. If you change your column names, changes will be reflected automatically during the execution of your code.
This function indicate to the master `chill.main.timeline_builder` service (which orchestrate the build of UNION queries) that the service supports the type indicated in the result's array of the `fetchQuery` function.
The implementation of our previous example will be :
..code-block:: php
namespace Chill\ReportBundle\Timeline;
use Chill\MainBundle\Timeline\TimelineProviderInterface;
use Doctrine\ORM\EntityManager;
class TimelineReportProvider implements TimelineProviderInterface
{
//...
/**
*
* {@inheritDoc}
*/
public function supportsType($type)
{
return $type === 'report';
}
//...
}
The `getEntities` function
^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is where the service must fetch entities from database and return them to the master service.
The results **must be** an array where the id given by the UNION query (remember `fetchQuery`).
<p><i class="fa fa-folder-open"></i> {{'An accompanying period is opened for %person% on %date%'|trans({'%person%':person,'%date%':period.dateOpening|localizeddate('long','none')})}}</p>
Create a timeline with his own context
======================================
You have to create a Controller which will execute the service `chill.main.timeline_builder`. Using the `Chill\MainBundle\Timeline\TimelineBuilder::getTimelineHTML` function, you will get an HTML representation of the timeline, which you may include with twig `raw` filter.
When you create a `sticker`, a sort of label to represent a text in a way that the user can associate immediatly with a certain type of class / entity.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Javascript functions
####################
Some function may be useful to manipulate elements on the page.
Show-hide elements according to a form state
*********************************************
The module ``ShowHide`` will allow you to show/hide part of your page using a specific test.
This must be use inside a javascript module.
Usage
=====
In this module, the module will listen to all input given in the ``container_from`` div, and will show or hide the content of the ``container_target`` according to the result of the ``test`` function.
This module allow to handle encapsulated show/hide elements. For instance :
* in a first checkbox list, a second checkbox list is shown if some element is checked ;
* in this second checkbox list, a third input is shown if some element is checked inside the second checkbox list.
As a consequence, if the given element in the first checkbox list is unchecked, the third input must also be hidden.
Example: when a situation professionnelle is ``en activite``, the second element ``type contrat`` must be shown if ``en_activite`` is checked. Inside ``type_contrat``, ``type_contrat_aide`` should be shown when ``contrat_aide`` is checked.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Layout / Template usage
#######################
We recommand the use of the existing layouts to ensure the consistency of the design. This section explains the different templates and how to use it.
The layouts are twig templates.
Twig templating helper
======================
`chill_print_or_message`
------------------------
Print a value or use a default template if the value is empty.
The template can be customized.
Two default templates are registered:
-:code:`default`, do not decorate the value ;
-:code:`blockquote`: wrap the value into a blockquote if exists
..code-block::html+twig
{{ "This is a message"|chill_print_or_message("No message") }}
<!-- will print "This is a message" -->
{{ ""|chill_print_or_message("No message")}}
<!-- will print <span class="chill-no-data-statement">No message</span> -->
{{ "This is a comment\n with multiples lines"|chill_print_or_message("No comment", 'blockquote') }}
<!-- will print <blockquote class="chill-user-quote">This is a comment<br/>with multiples lines</blockquote> -->
When customizing the template, two arguments are passed to the template:
-:code:`value`: the actual value ;
-:code:`message`: the message, given as argument
Routing with return path
------------------------
Three twig function are available for creating routes and handling "return path".
**Rationale**: When building a "CRUD" (CReate, Update, Delete of an entity), you would like to allow people to go back on some custom cancel page when coming for another place of an application. For instance, if you are in the timeline and show an activity, you would like that the user go back to the timeline when pressing the "return" button at the bottom of the page, instead of going back to the "activity list" page.
Using those function, a :code:`returnPath` parameter will be added in the path generated. It will be used instead of the default one in the subsequente pages.
-:code:`chill_path_add_return_path(name, parameters = [], relative = false)`: will create a path with current page as return path (users will go back to the current page on the next page) ;
-:code:`chill_return_path_or(name, parameters = [], relative = false)`: will create a path to the return path if present, or build the path according to the given parameters ;
-:code:`chill_path_forward_return_path(name, parameters = [], relative = false)`: will create a path and adding the return path that is present for the current page, *forwarding* the return path to the next page. This is useful if you are on a "show" page with a return path (by instance, the "timeline" page), you place a link to the *edit* page and want users to go back to the "timeline" page on the edit page.
-:code:`chill_return_path_or`:
Organisation of the layouts
===========================
ChillMainBundle::layout.html.twig
---------------------------------
This is the base layout. It includes the most import css / js files. It display a page with
* a horizontal navigation menu
* a place for content
* a footer
The layout containts blocks, that are :
* title
* to display title
* css
* where to add some custom css
* navigation_section_menu
* place where to insert the section menu in the navigation menu (by default the navigation menu is inserted)
* navigation_search_bar
* place where to insert a search bar in the navigation menu (by default the search bar is inserted)
* top_banner
* place where to display a banner below the navigation menu (this place is use to display the details of the person)
* sublayout_containter
* place between the header and the footer that can be used to create a new layout (with vertical menu for example)
* content
* place where to display the content (flash message are included outside of this block)
* js
* where to add some custom javascript
ChillMainBundle::layoutWithVerticalMenu.html.twig
-------------------------------------------------
This layout extends `ChillMainBundle::layout.html.twig`. It replaces the block `layout_content` and divides this block for displaying a vertical menu and some content.
It proposes 2 new blocks :
* layout_wvm_content
* where to display the page content
* vertical_menu_content
* where to place the vertical menu
ChillMainBundle::Admin/layout.html.twig
---------------------------------------
This layout extends `ChillMainBundle::layout.html.twig`. It hides the search bar, remplaces the `section menu` with the `admin section menu`.
This layout extends `ChillMainBundle::layoutWithVerticalMenu.html.twig`. It do the same changes than `ChillMainBundle::Admin/layout.html.twig` : hiding the search bar, remplacing the `section menu` with the `admin section menu`.
It proposes a new block :
* admin_content
* where to display the admin content
@ChillPersonBundle/Person/layout.html.twig
-----------------------------------
This layout extend `ChillMainBundle::layoutWithVerticalMenu.html.twig` add the person details in the block `top_banner`, set the menu `person` as the vertical menu.
It proposes 1 new block :
* personcontent
* where to display the information of the person
ChillMainBundle::Export/layout.html.twig
----------------------------------------
This layout extends `ChillMainBundle::layoutWithVerticalMenu.html.twig` and set the menu `export` as the vertical menu.
It proposes 1 new block :
* export_content
* where to display the content of the export
Useful template and helpers
===========================
Macros
------
Every bundle may bring their own macro to print resources with uniformized styles.
See :
-:ref:`Macros in person bundle <person-bundle-macros>` ;
-:ref:`Macros in activity bundle <activity-bundle-macros>` ;
-:ref:`Macros in group bundle <group-bundle-macros>` ;
-:ref:`Macros in main bundle <main-bundle-macros>` ;
This template show a confirmation template before making dangerous things. You can add your own message and title, or define those message by yourself in another template.
The accepted parameters are :
-`title` (string) a title for the page. Not mandatory (it won't be rendered if not defined)
-`confirm_question` (string) a confirmation question. This question will not be translated into the template, and may be printed as raw. Not mandatory (it won't be rendered if not defined)
-`form` : (:class:`Symfony\Component\Form\FormView`) a form wich **must** contains an input named `submit`, which must be a :class:`Symfony\Component\Form\Extension\Core\Type\SubmitType`. Mandatory
-`cancel_route` : (string) the name of a route if the user want to cancel the action
-`cancel_parameters` (array) the parameters for the route defined in `cancel_route`
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Widgets
##############################################
Rationale
=========
Widgets are useful if you want to publish content on a page provided by another bundle.
Examples :
- you want to publish a list of people on the homepage ;
- you may want to show the group belonging (see :ref:`group-bundle`) below of the vertical menu, only if the bundle is installed.
The administrator of the chill instance may configure the presence of widget. Although, some widget are defined by default (see :ref:`declaring-widget-by-default`).
Concepts
========
A bundle may define *place(s)* where a widget may be rendered.
In a single *place*, zero, one or more *widget* may be displayed.
Some *widget* may require some *configuration*, and some does not require any configuration.
-:code:`$env` the :class:`\Twig_Environment`, which you can use to render your widget ;
-:code:`$place` a string representing the place where the widget is rendered ;
-:code:`$context` the context given by the template ;
-:code:`$config` the configuration which is, in this case, always an empty array (see :ref:`creating-a-widget-with-config`).
..note::
The html returned by the :code:`render` function will be considered as html safe. You should strip html before returning it. See also `How to escape output in template <http://symfony.com/doc/current/templating/escaping.html>`_.
Declare your widget
-------------------
Declare your widget as a service and add it the tag :code:`chill_widget`:
You can declare your widget as a service. Not tag is required, as the service will be defined by the :code:`Factory` during next step.
..code-block::yaml
services:
chill_person.widget.person_list:
class:Chill\PersonBundle\Widget\PersonListWidget
arguments:
- "@chill.person.repository.person"
- "@doctrine.orm.entity_manager"
- "@chill.main.security.authorization.helper"
- "@security.token_storage"
# this widget is defined by the PersonListWidgetFactory
You can eventually skip this step and declare your service into the container through the factory (see above).
Declare your widget factory
---------------------------
The widget factory must implements `Chill\MainBundle\DependencyInjection\Widget\Factory\WidgetFactoryInterface`. For your convenience, an :class:`Chill\MainBundle\DependencyInjection\Widget\Factory\AbstractWidgetFactory` will already implements some easy method.
You can declare your widget into the container by overriding the `createDefinition` method. By default, this method will return the already existing service definition with the id given by :code:`getServiceId`. But you can create or adapt programmatically the definition. `See the symfony doc on how to do it <http://symfony.com/doc/current/service_container/definitions.html#working-with-a-definition>`_.
A place should be defined by using the :code:`chill_widget` function, which take as argument :
-:code:`place` (string) a string defining the place ;
-:code:`context` (array) an array defining the context.
The context should be documented by the bundle. It will give some information about the context of the page. Example: if the page concerns a people, the :class:`Chill\PersonBundle\Entity\Person` class will be in the context.
Example :
..code-block::html+jinja
{# an empty context on homepage #}
{{ chill_widget('homepage', {} }}
..code-block::html+jinja
{# defining a place 'right column' with the person currently viewed
{{ chill_widget('right_column', { 'person' : person } }}
Declare configuration for you place
-----------------------------------
In order to let other bundle, or user, to define the widgets inside the given place, you should open a configuration. You can use the Trait :class:`Chill\MainBundle\DependencyInjection\Widget\AddWidgetConfigurationTrait`, which provide the method `addWidgetConfiguration($place, ContainerBuilder $container)`.
- line 25-39: we implements the method required by :class:`Chill\MainBundle\DependencyInjection\Widget\HasWidgetExtensionInterface` ;
- line 48-49: we record the configuration of widget into container's parameter ;
- line 56 : we create an instance of :class:`Configuration` (declared above)
Compile the possible widget using Compiler pass
-----------------------------------------------
For your convenience, simply extends :class:`Chill\MainBundle\DependencyInjection\Widget\AbstractWidgetsCompilerPass`. This class provides a `doProcess(ContainerBuildere $container, $extension, $parameterName)` method which will do the job for you:
-:code:`$container` is the container builder
-:code:`$extension` is the extension name
-:code:`$parameterName` is the name of the parameter which contains the configuration for widgets (see :ref:`the example with ChillMain above <example-chill-main-extension>`.
As explained `in the symfony docs <http://symfony.com/doc/current/service_container/compiler_passes.html>`_, you should register your Compiler Pass into your bundle :
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Welcome to Chill documentation!
=====================================
Chill is a free software for social workers.
Chill rely on the php framework `Symfony <http://symfony.com>`_.
Contents of this documentation:
..toctree::
:maxdepth:2
installation/index.rst
development/index.rst
Bundles <bundles/index.rst>
Let's talk together !
======================
You may talk to developers using the matrix room: `https://app.element.io/#/room/#chill-social-admin:matrix.org`_
Contribute
==========
*`Issue tracker <https://gitlab.com/groups/Chill-project/issues>`_ You may want to dispatch the issue in the multiple projects. If you do not know in which project is located your bug / feature request, use the project Chill-Main.
User manual
===========
An user manual exists in French and currently focuses on describing the main concept of the software.
`Read (and contribute) to the manual <https://fr.wikibooks.org/wiki/Chill>`_
Available bundles
=================
* Chill-app | https://gitlab.com/Chill-project/Chill-app This is the skeleton of the project. It does contains only few code, but information about configuration of your instance ;
* Chill-bundle: contains the main bundles, the most used in an instance. This means:
* chill-main, the main framework,
* Chill Person, to deal with persons,
* chill custom fields, to add custom fields to some entities,
* chill activity: to add activities to people,
* chill report: to add report to people,
* chill event: to gather people into events,
* chill docs store: to store documents to people, but also entities,
* chill task: to register task with people,
* chill third party: to register third parties,
* chill family members: to register family members
You will also found the following projects :
* The website https://chill.social : https://gitlab.com/Chill-project/chill.social
And various project to build docker containers with Chill.
TODO in documentation
=====================
..todolist::
Licence
========
The project is available under the `GNU AFFERO GENERAL PUBLIC LICENSE v3`_.
This documentation is published under the `GNU Free Documentation License (FDL) v1.3`_
.._GNU AFFERO GENERAL PUBLIC LICENSE v3: http://www.gnu.org/licenses/agpl-3.0.html
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
Installation & Usage
####################
Requirements
************
- This project use `docker <https://docker.com>`_ to be run. As a developer, use `docker-compose <https://docs.docker.com/compose/overview/>`_ to bootstrap a dev environment in a glance. You do not need any other dependencies ;
- Make is used to automate scripts.
Installation in development mode
********************************
1. Get the code
===============
Clone or download the chill-app project and `cd` into the main directory.
As a developer, the code will stay on your computer and will be executed in docker container. To avoid permission problem, the code should be run with the same uid/gid from your current user. This is why we get your current user id with the command ``id -u`` in each following scripts.
2. Prepare your variables
=========================
Have a look at the variable in ``.env.dist`` and in ``app/config/parameters.yml.dist`` and check if you need to adapt them. If they do not adapt with your need, or if some are missing:
1. copy the file as ``.env``: ``cp .env.dist .env``
2. you may replace some variables inside ``.env``
**Note**: If you intend to use the bundle ``Chill-Doc-Store``, you will need to configure and install an openstack object storage container with temporary url middleware. You will have to configure `secret keys <https://docs.openstack.org/swift/latest/api/temporary_url_middleware.html#secret-keys>`_.
3. Run the bootstrap script
===========================
This script can be run using `make`
..code-block::bash
make init
This script will :
1. force docker-compose to, eventually, pull the base images and build the image used by this project ;
2. run an install script to download `composer <https://getcomposer.org>`_ ;
3. install the php dependencies
4. build assets
4. Start the project
====================
..code-block::bash
docker-compose up
**On the first run** (and after each upgrade), you must execute *post update commands* and run database migrations. With a container up and running, execute the following commands:
..code-block::bash
make migrate
Chill will be available at ``http://localhost:8001.`` Currently, there isn't any user or data. To add fixtures, run
docker-compose run --user $(id -u) php ./composer.phar
How to access to PGADMIN ?
==========================
Pgadmin is installed with docker-compose.
You can access it at ``http://localhost:8002``.
Credentials:
- login: admin@chill.social
- password: password
How to run tests ?
==================
Tests reside inside the installed bundles. You must `cd` into that directory, download the required packages, and execute them from this place.
**Note**: some bundle require the fixture to be executed. See the dedicated _how-tos_.
Exemple, for running test inside `main` bundle:
..code-block::bash
# mount into the php image
docker-compose run --user $(id -u) php /bin/bash
# cd into main directory
cd vendor/chill-project/main
# download deps
php ../../../composer.phar install
# run tests
/vendor/bin/phpunit
How to run webpack interactively
================================
Executing :code:`bash docker-node.sh` will open a terminal in a node container, with volumes mounted.
Build the documentation API
===========================
A basic configuration of `sami <https://github.com/FriendsOfPhp/Sami>`_ is embedded within the project.
A configuration file for `phpDocumentor <https://www.phpdoc.org>`_ is present.
Error `An exception has been thrown during the rendering of a template ("Asset manifest file "/var/www/app/web/build/manifest.json" does not exist.").` on first run
Currently, to run this software in production, the *state of the art* is the following :
1. Run the software locally and tweak the configuration to your needs ;
2. Build the image and store them into a private container registry. This can be done using :code:`make build-and-push-image`.
To be sure to target the correct container registry, you have to adapt the values ``IMAGE_NGINX`` and ``IMAGE_PHP`` date in the ``.env`` file.
3. Run the image on your production server, using docker-compose or eventually docker stack. You have to customize the variable set in docker-compose.
See also the :ref:`running-production-tips-and-tricks` below.
..warning::
In production, you **must** set those variables:
*``APP_ENV`` to ``prod``
*``APP_DEBUG`` to ``false``
There are security issues if you keep the same variable than for production.
.._running-production-tips-and-tricks:
Tips and tricks
===============
Operation on database (backups, running custom sql, replication) are easier to set when run outside of a container. If you run into a container, take care of the volume where data are stored.
The PHP sessions are stored inside redis. This is useful if you distribute the traffic amongst different php server: they will share same sessions if a request goes into a different instance of the container.
When the PHP servers are shared across multiple instances, take care that some data is stored into redis: the same redis server should be reachable by all instances.
It is worth having an eye on the configuration of logstash container.
Design principles
*****************
Why the DB URL is set in environment, and not in parameters.yml ?
Because, at startup, a script does check the db is up and, if not, wait for a couple of seconds before running ``entrypoint.sh``. For avoiding double configuration, the configuration of the PHP app takes his configuration from environment also (and it will be standard in future releases, with symfony 4.0).
message: "#^Parameter \\$action of method Chill\\\\PersonBundle\\\\Repository\\\\AccompanyingPeriod\\\\AccompanyingPeriodWorkRepository\\:\\:buildQueryBySocialActionWithDescendants\\(\\) has invalid type Chill\\\\PersonBundle\\\\Repository\\\\AccompanyingPeriod\\\\SocialAction\\.$#"
message: "#^Parameter \\$action of method Chill\\\\PersonBundle\\\\Repository\\\\AccompanyingPeriod\\\\AccompanyingPeriodWorkRepository\\:\\:countBySocialActionWithDescendants\\(\\) has invalid type Chill\\\\PersonBundle\\\\Repository\\\\AccompanyingPeriod\\\\SocialAction\\.$#"
message: "#^Method Chill\\\\ActivityBundle\\\\Export\\\\Export\\\\StatActivityDuration\\:\\:getDescription\\(\\) should return string but return statement is missing\\.$#"
message: "#^Method Chill\\\\ActivityBundle\\\\Export\\\\Export\\\\StatActivityDuration\\:\\:getTitle\\(\\) should return string but return statement is missing\\.$#"
message: "#^Method Chill\\\\CustomFieldsBundle\\\\CustomFields\\\\CustomFieldChoice\\:\\:buildForm\\(\\) should return Symfony\\\\Component\\\\Form\\\\FormTypeInterface but return statement is missing\\.$#"
message: "#^Method Chill\\\\CustomFieldsBundle\\\\CustomFields\\\\CustomFieldDate\\:\\:buildForm\\(\\) should return Symfony\\\\Component\\\\Form\\\\FormTypeInterface but return statement is missing\\.$#"
message: "#^Method Chill\\\\CustomFieldsBundle\\\\CustomFields\\\\CustomFieldLongChoice\\:\\:buildForm\\(\\) should return Symfony\\\\Component\\\\Form\\\\FormTypeInterface but return statement is missing\\.$#"
message: "#^Method Chill\\\\CustomFieldsBundle\\\\CustomFields\\\\CustomFieldNumber\\:\\:buildForm\\(\\) should return Symfony\\\\Component\\\\Form\\\\FormTypeInterface but return statement is missing\\.$#"
message: "#^Method Chill\\\\CustomFieldsBundle\\\\CustomFields\\\\CustomFieldText\\:\\:buildForm\\(\\) should return Symfony\\\\Component\\\\Form\\\\FormTypeInterface but return statement is missing\\.$#"
message: "#^Method Chill\\\\CustomFieldsBundle\\\\CustomFields\\\\CustomFieldTitle\\:\\:buildForm\\(\\) should return Symfony\\\\Component\\\\Form\\\\FormTypeInterface but return statement is missing\\.$#"
message: "#^Parameter \\$resolver of method Chill\\\\EventBundle\\\\Form\\\\EventTypeType\\:\\:setDefaultOptions\\(\\) has invalid type Symfony\\\\Component\\\\OptionsResolver\\\\OptionsResolverInterface\\.$#"
message: "#^Parameter \\$resolver of method Chill\\\\EventBundle\\\\Form\\\\RoleType\\:\\:setDefaultOptions\\(\\) has invalid type Symfony\\\\Component\\\\OptionsResolver\\\\OptionsResolverInterface\\.$#"
message: "#^Parameter \\$resolver of method Chill\\\\EventBundle\\\\Form\\\\StatusType\\:\\:setDefaultOptions\\(\\) has invalid type Symfony\\\\Component\\\\OptionsResolver\\\\OptionsResolverInterface\\.$#"
message: "#^Parameter \\$scope of method Chill\\\\MainBundle\\\\CRUD\\\\Controller\\\\CRUDController\\:\\:getReachableCenters\\(\\) has invalid type Chill\\\\MainBundle\\\\CRUD\\\\Controller\\\\Scope\\.$#"
message: "#^Method Chill\\\\MainBundle\\\\CRUD\\\\Resolver\\\\Resolver\\:\\:getConfigValue\\(\\) should return string but return statement is missing\\.$#"
message: "#^Method Chill\\\\MainBundle\\\\Command\\\\ChillImportUsersCommand\\:\\:execute\\(\\) should return int but return statement is missing\\.$#"
message: "#^Method Chill\\\\MainBundle\\\\Command\\\\ChillUserSendRenewPasswordCodeCommand\\:\\:execute\\(\\) should return int but return statement is missing\\.$#"
message: "#^Method Chill\\\\MainBundle\\\\Command\\\\LoadAndUpdateLanguagesCommand\\:\\:execute\\(\\) should return int but return statement is missing\\.$#"
message: "#^Method Chill\\\\MainBundle\\\\Timeline\\\\TimelineBuilder\\:\\:getTemplateData\\(\\) should return array but return statement is missing\\.$#"
message: "#^Method Chill\\\\PersonBundle\\\\Command\\\\ChillPersonMoveCommand\\:\\:execute\\(\\) should return int but return statement is missing\\.$#"
message: "#^Method Chill\\\\PersonBundle\\\\Repository\\\\AccompanyingPeriod\\\\AccompanyingPeriodWorkRepository\\:\\:buildQueryBySocialActionWithDescendants\\(\\) has invalid return type Chill\\\\PersonBundle\\\\Repository\\\\AccompanyingPeriod\\\\QueryBuilder\\.$#"
message: "#^Method Chill\\\\ReportBundle\\\\DataFixtures\\\\ORM\\\\LoadReports\\:\\:getRandomChoice\\(\\) should return array\\<string\\>\\|string but return statement is missing\\.$#"
message: "#^Method Chill\\\\ReportBundle\\\\Security\\\\Authorization\\\\ReportVoter\\:\\:supports\\(\\) should return bool but return statement is missing\\.$#"
message: "#^Method Chill\\\\TaskBundle\\\\Timeline\\\\SingleTaskTaskLifeCycleEventTimelineProvider\\:\\:getTransitionByName\\(\\) should return Symfony\\\\Component\\\\Workflow\\\\Transition but return statement is missing\\.$#"
message: "#^Method Chill\\\\TaskBundle\\\\Timeline\\\\TaskLifeCycleEventTimelineProvider\\:\\:getTransitionByName\\(\\) should return Symfony\\\\Component\\\\Workflow\\\\Transition but return statement is missing\\.$#"
message: "#^Method Chill\\\\ThirdPartyBundle\\\\Search\\\\ThirdPartySearch\\:\\:renderResult\\(\\) should return string but return statement is missing\\.$#"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.