Content
View differences
Updated by Aleix Suau about 5 years ago
For work packages, fields can be configured as multiple selections for all projects or for individual projects. The same function is desired for user-defined fields of the type Project.
**Acceptance requirements**
* The administration of custom fields for projects gets a checkbox "Allow multi-select", just like the lists for work packages
* The project form is extended such that list custom fields can be multi-selected
* The project advanced settings is extended such that list custom fields can be multi-selected
* The project overview list/table is extended to show multi-select custom fields
* The project details widget on the project overview / dashboard displays custom lists with multiple selections.
* When copying projects, multi-selection custom fields are also copied
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/20761/content"></div></figure>
### Development Notes
* Admin > Custom fields > Wps > multiselect checkbox
* Project > Overview > Project details should allow multi-select custom fields
* Form Config:
* [https://docs.openproject.org/api/endpoints/projects/](https://docs.openproject.org/api/endpoints/projects/)
* [https://docs.openproject.org/api/endpoints/projects/#projects-projects-schema](https://docs.openproject.org/api/endpoints/projects/#projects-projects-schema)
* [https://docs.openproject.org/api/endpoints/projects/#projects-project-create-form](https://docs.openproject.org/api/endpoints/projects/#projects-project-create-form)
*
* Replace project setting's Information tab:
* exclude required disk storage
* Top left buttons (subproject, copy project...)
* 3 steps:
* Replace view with formly
* Enable the backend capable of multiselect fields project
* Enable multiselect fields project in the frontend
* How do we know when input is a typeahead? When it has allowedValues?
* How do we know it allows multiple values?
* Does the input config name have a translation? How is it managed?
* Do we have only 2 types of values?
* Resources: {title, href}
* Regular (direct value)
* Schema:
* What are \_dependencies for?
* Why Customfields are inside \_links but have an \[\] in the payload while the others have an object (title, href)?
* Do the AllowedValues share an interface?
* What options can we have in fieldSchema.options?
* Where is the lockversion changed?
* Id is writable false but lockVersion is true?
* Do all resources set their id as value (ngSelect) ?
* ng-select: Resource value come with a 'title' while resource options come with 'name', could we unify this?
* Default values: what happens if the user deletes it? Do we have to set it again before sending the form?
* We'd need a way of letting know that a writable fields should be hidden (lockVersion) and that a non writable field should be shown? Separate writability from visibility (derivedStartDate, createdOn, CreatedOn... is in the schema but should not be shown)
* Form inputs outside of the form (how do we deal with it?)
* Wp type
* Do we want to also change the HalResources + ChangeSet?
* Form state:
* Do we want to have two forms synchronized/editing the same model (reference)? (e.g. split-view table-side panel)
### Dev requirements
* Change Sources:
* Layout:
* Schema loading (FormConfig):
When the user changes the type.
* First load
* Schema change
* Model:
* Schema loading (Payload (Model + Default values)) :
When the user changes the type.
* First load
* Schema change
* User interaction
* Valid result (In this order) = Form config + Form Payload + User Changes (that applies to the active Type)
* Whenever the Type is changes, we have to reapply the entire previous sequence.
* Whenever the form is submitted, the User Changes have to be reset
* Form component:
* 2 ways of getting its config:
* New >>> POST to _api/v3/projects/\[projectId\]/work\_packages/form_ with payload _{\_links: {type: {href: "/api/v3/types/1"}}}_
* Existing >>> POST _api/v3/work\_packages/\[wp\_id\]/form_ with payload _{lockVersion: 2, \_links: {}}_
* _DynamicFormsHub Use cases:_
* _Keeps a reference of every active form_
* _Registers a form when it is created_
* _Removes a form when it is destroyed_
* _Keeps the unsaved changes_
* On route changes, o\_nly when they are not discarded (maximize side panel).\_
* _How do we know that the change has not been discarded (alert)_
### TODO
* [x] Print form
* [x] Fill model
* [x] Default values
* [x] Group fields
* [x] Layout
* [x] Validation
* [x] Sync
* [x] Async
* [x] Custom component
* [ ] Save
* [ ] Save the entire form when it is new
* [ ] Save on every field edit when it has model
* [ ] Send to endpoint
* [ ] Postprocess the model
* [ ] Set default values if the user has deleted the default value
* [ ] Remove values that don't belong to the schema (e.g. if the user has filled some custom fields and then changed the type )
* [ ] Manage:
* [ ] LockVersion
* [ ] Id (on new wps)
* [ ] Others
* [ ] Translations
* [ ] Combo inputs (country > province)
* [ ] Expressions
* [ ] Click and edit
* [ ] Improve performance
* [ ] Manage focus
* [ ] ng-select
* [ ] Between fields with tabs (inline edit)
**Acceptance requirements**
* The administration of custom fields for projects gets a checkbox "Allow multi-select", just like the lists for work packages
* The project form is extended such that list custom fields can be multi-selected
* The project advanced settings is extended such that list custom fields can be multi-selected
* The project overview list/table is extended to show multi-select custom fields
* The project details widget on the project overview / dashboard displays custom lists with multiple selections.
* When copying projects, multi-selection custom fields are also copied
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/20761/content"></div></figure>
### Development Notes
* Admin > Custom fields > Wps > multiselect checkbox
* Project > Overview > Project details should allow multi-select custom fields
* Form Config:
* [https://docs.openproject.org/api/endpoints/projects/](https://docs.openproject.org/api/endpoints/projects/)
* [https://docs.openproject.org/api/endpoints/projects/#projects-projects-schema](https://docs.openproject.org/api/endpoints/projects/#projects-projects-schema)
* [https://docs.openproject.org/api/endpoints/projects/#projects-project-create-form](https://docs.openproject.org/api/endpoints/projects/#projects-project-create-form)
*
* Replace project setting's Information tab:
* exclude required disk storage
* Top left buttons (subproject, copy project...)
* 3 steps:
* Replace view with formly
* Enable the backend capable of multiselect fields project
* Enable multiselect fields project in the frontend
* How do we know when input is a typeahead? When it has allowedValues?
* How do we know it allows multiple values?
* Does the input config name have a translation? How is it managed?
* Do we have only 2 types of values?
* Resources: {title, href}
* Regular (direct value)
* Schema:
* What are \_dependencies for?
* Why Customfields are inside \_links but have an \[\] in the payload while the others have an object (title, href)?
* Do the AllowedValues share an interface?
* What options can we have in fieldSchema.options?
* Where is the lockversion changed?
* Id is writable false but lockVersion is true?
* Do all resources set their id as value (ngSelect) ?
* ng-select: Resource value come with a 'title' while resource options come with 'name', could we unify this?
* Default values: what happens if the user deletes it? Do we have to set it again before sending the form?
* We'd need a way of letting know that a writable fields should be hidden (lockVersion) and that a non writable field should be shown? Separate writability from visibility (derivedStartDate, createdOn, CreatedOn... is in the schema but should not be shown)
* Form inputs outside of the form (how do we deal with it?)
* Wp type
* Do we want to also change the HalResources + ChangeSet?
* Form state:
* Do we want to have two forms synchronized/editing the same model (reference)? (e.g. split-view table-side panel)
### Dev requirements
* Change Sources:
* Layout:
* Schema loading (FormConfig):
When the user changes the type.
* First load
* Schema change
* Model:
* Schema loading (Payload (Model + Default values)) :
When the user changes the type.
* First load
* Schema change
* User interaction
* Valid result (In this order) = Form config + Form Payload + User Changes (that applies to the active Type)
* Whenever the Type is changes, we have to reapply the entire previous sequence.
* Whenever the form is submitted, the User Changes have to be reset
* Form component:
* 2 ways of getting its config:
* New >>> POST to _api/v3/projects/\[projectId\]/work\_packages/form_ with payload _{\_links: {type: {href: "/api/v3/types/1"}}}_
* Existing >>> POST _api/v3/work\_packages/\[wp\_id\]/form_ with payload _{lockVersion: 2, \_links: {}}_
* _DynamicFormsHub Use cases:_
* _Keeps a reference of every active form_
* _Registers a form when it is created_
* _Removes a form when it is destroyed_
* _Keeps the unsaved changes_
* On route changes, o\_nly when they are not discarded (maximize side panel).\_
* _How do we know that the change has not been discarded (alert)_
### TODO
* [x] Print form
* [x] Fill model
* [x] Default values
* [x] Group fields
* [x] Layout
* [x] Validation
* [x] Sync
* [x] Async
* [x] Custom component
* [ ] Save
* [ ] Save the entire form when it is new
* [ ] Save on every field edit when it has model
* [ ] Send to endpoint
* [ ] Postprocess the model
* [ ] Set default values if the user has deleted the default value
* [ ] Remove values that don't belong to the schema (e.g. if the user has filled some custom fields and then changed the type )
* [ ] Manage:
* [ ] LockVersion
* [ ] Id (on new wps)
* [ ] Others
* [ ] Translations
* [ ] Combo inputs (country > province)
* [ ] Expressions
* [ ] Click and edit
* [ ] Improve performance
* [ ] Manage focus
* [ ]
* [ ] Between fields with tabs (inline edit)