Content
View differences
Updated by Parimal Satyal over 2 years ago
### # User Story
**As a** project member or project admin
portfolio manager
**I want to** view and edit present the project attributes in a structured way (organised in sections) on the project overview screen
in sections
**So that** I can more easily keep track of and manage a large project portfolios portfolio and communicate importants the details about the individual individiaul project goals and benefits to the project stakeholder.
### # Acceptance criteria
#### Project overview ## **Project overview:**
* The project overview will maintain the current implementation of widgets but include a new right pane left `layout-sidebar` (like in the Meetings module)
meeting modules).
* This pane The left `layout-sidebar` will display contain the information of the project attributes enabled for this project in their respective sections, along with their following the settings specifying which sections and attributes should be displayed. The values
* A section is only shown if at least one project of each attribute from that are editable per section is enabled for clicking on the project (if that number is zero, edit icon on the section is hidden entirely)
* If header of the user has the permission "edit\_project", each section shows an edit icon
* Clicking section, this icon opens action will trigger a dialog showing inputs for all enabled project attributes contained (as in that section
* Saving this dialog automatically closes meetings) where the dialog and user can edit all the changes are reflected in the sidebar without a browser page refresh
* If an invalid value was entered, the dialog is not closed and form validations are displayed (standard Primer style)
* Thee dialog **cannot** be saved if a project attribute value _within_ this section is invalid
* The dialog **can** be save if all project attributes WITHIN this section are valid values of that section.
* Each section is self-contained. If a For project attribute in section "A" administrators there is in an invalid state, a section "B" can still be saved.
* For example, if a new required entry points to manage the project attributes is added to section "A". section "A" is now technically in an invalid state. However, this does not affect Section "B", which can be edited and saved normally.
* Special renderings in the sidebar:
* If at a value is not set for a project attribute, "Not set yet" is shown \[OPEN POINT 3\]
settings level) from the three dots button on the `PageHeader`.
* Boolean Long text fields are rendered with Yes/No
* Users are shown with their avatar
* Rich text values
* are properly formated (e.g. bold text is shown as bold...)
* are truncated when they are longer than 100 characters
* An "Expand" truncated. A link opens a dialog showing the complete rich text value as read-only (similar to #52127)
* Multi user values are shown in a list
* Other multi values are shown comma-seperated modal window (extracted from #50935).
* If a project has no enabled project attributes, the The sidebar is completely empty? (OPEN POINT 4)
* For project admins with permission responsvie and not limited to edit project attributes, there is a third More (...) button maximum width. On large screens it will be larger than on the top right corner to the right of Add (+) with two options:
* "Manage project attributes" (redirects to Project settings smaller screens (extracted from #50936).
## **Administration > Projects > Project attribtues)
attributes:**
* "Archive project"
* URL routing: `projects/{project_id}`
* Accessible to project members with Inside of the permission "view\_project"
* Edit actions only available for project members with the permission "edit\_project"
#### Administration of project attributes
**Menu entries**
* There is administration settings a new menu entry in the Admin settings called "Projects" with these items: is added. This will have a second level of navigation containing:
* Project attributes (default)
* New project
* Project lists
* The two sections settings (Now under the "Settings" sub-menu (Settings for new projects, Settings for project overview) will be split into two different pages:
* **New project**: "System settings > Projects")
* This will contain the same Projects list settings as (Now under "Settings for new projects", without the h2 header
"System settings > Projects")
* The title Inside of the "Project attributes" setting page the user will be "New project"
* **Project lists**
* This will contain find all the same settings as under "Settings for project overview list", without the h2 header
* attributes created and its sections. The title of the page user will be "Project lists"
**Project attributes**
* **Sections**: Project able to reorder the sections and attributes, create new sections and attributes are shown in their sections. A project attribute is always a part of a section.
* Sections can be re-ordered via drag and drop or action or menu buttons
* modify existing ones. The order of the sections defines the display order of the sections globally (project settings, project overview page)
* Sections can be deleted but only if no project attribute attributes is assigned to them
* A new section can be created by clicking defined at a global administration level (not on the "+ Section" button on the PageHeader. This will display a modal with an input field to name the section.
* This section will be added to the top of the list.
* The More (..) button to the right of a section will display a drop-box with these options:
* Edit title (displays a dialog with an input field with the current tile pre-filled)
* Move to top (unless already at the top)
* Move up (unless already at the top)
* Move down (unless already at the bottom)
* Move to bottom (unless already at the bottom)
* Delete (requires confirmation) project level).
* **Individual attributes:**
* Within a section box, all assigned project attributes are shown with their:
* Name
* Type (String, User, List...)
* In the number of projects using this attribute
* Individual project attributes within a section can be re-ordered via drag and drop creation or action menu buttons
* The More (..) button to the right modification of an individual attribute the user will display see a drop-box with these options:
* Edit (redirects to screen containing the edit attribute page)
* Move to top (unless already at the top)
* Move up (unless already at the top)
* Move down (unless already at the bottom)
* Move to bottom (unless already at the bottom)
* Delete (requires confirmation)
* The order basic information of the project attributes defines the display order of the project attributes globally (project settings, project overview page)
* A project attribute can be moved to another section via drag (name, type, section, multi-select, default and drop
* A project required). The type of attribute can be deleted (after confirmation), even when it's used in a project (associated custom values will be deleted permanently!)
* **Creating project attributes:** A new attribute can be created by clicking on has the "+ Project attribute" button on same types as the PageHeader. This will direct to a blank project attribute form.
* Changing the project attribute type (e.g. to list), will change the input fields directly
* Saving this form redirects back to list page, showing the new project attribute in the selected section
* If a project attribute is set to required, it gets automatically activated in all projects after create (with no option to disable it at a project-level)
* The visible setting does currently have no effect (OPEN POINT 1)
* An empty section additionally shows a button current implementation for project attribute creation custom fields.
* **Editing For each project attributes:** Each attribute can be edited by clicking on its name or clicking on the "Edit" action on the More dropdown menu
* On the edit page, the existing "project custom field" form (as seen for all other custom field types, e.g. WorkPackage) there is rendered with a new header
* In contrast screen which allows to the typical custom field form, a select box for the "Section" assignment is shown below the name form
* Changing this moves the project attribute to a different section (as an alternative to the above described drag activate and drop approach)
* Saving deactivate the form does not redirect back to the list page
* If a project attribute is updated to be required, it gets automatically activated in all for one or more projects after save (and can no longer be disabled at a project level)
(extracted from #50937)
* The visible setting does currently have no effect (OPEN POINT 1)
* URL routing: `admin/settings/project_custom_fields`
* Only accessible ro admins widget "Details" is deleted and removed from the Project overview <mention class="mention" data-id="51794" data-type="work_package" data-text="#51794">#51794</mention>
#### Project-level ## **Project settings for project attributes > Project attributes:**
* There is a A new entry in the Project settings called "Project attributes"
* All project custom fields are listed in boxes, grouped by their sections in the same order as defined in the global admin page
* The order of section/attributes cannot sidebar menu will be changed here added.
* The project attributes are shown with their name, type and In a badge "required" if they are required
* Each project attribute can be enabled/disabled (activated/deactivated) for settings level the current project using the toggle switch (except required ones)
* The toggle switch is disable for required project attributes (in the on position)
* No extra confirmation is shown after using the toggle switch
* The "enable all"/"disable all" buttons per section allow bulk actions in order administrators will be able to mass edit select which of the activation state of project available attributes
* Required project attributes always stay activated and are not affected (defined by the bulk edit buttons
* No extra confirmation is shown after using the mass edit buttons
* Disabling a project attribute does _not_ delete an assigned custom value
* A disabled project attribute and its custom value:
* Will not instance administrator) will be shown in the project overview page sidebar (specs below)
* Will not be exported (specs below)
* Cannot be targeted displayed by a filter in section into the project list (specs below) overview.
* For more convenience, All the list can projects attributes of the instance will be filtered by project attribute name displayed in this screen and type via a search input below bar will allow the header
* When a filter is active, the bulk edit buttons are hidden user to search for specific attributes.
* URL routing: `projects/{project_id}/settings/project_custom_fields`
* Accessible to project members with We remove the permission "select\_project\_custom\_fields"
#### Project creation
* The following applies to project creation input fields for custom fields from scratch, without using a template
* URL routing: `visit projects/new`
* The current project creation form is not changed at all
* All defined project attributes are visible within this form
* A project attribute gets automatically activated after project creation, if:
* The user provided a value for the project attribute
* The project attribute has a default value, which was not set to blank explicitly
* The project attribute is a boolean
* which is set to default "Project Settings -> true and is not touched by Information". This means that the user -> activted and true
* which is set only place to default -> true and is set to false by the user -> activted and false
* which has no default value and is not touched by the user -> activted and false (OPEN POINT 5)
* which has no default value is set to true by the user -> activted and true
* In all other cases, the edit project attribute attributes is disabled in the created project, but can be enabled afterwards via project attribute settings page
#### Project copy / Project creation with template
overview.
* The following applies to project creation process:
* based on Deactivating a template project or
* copy of an existing project
* URL routing: 'visit projects/new' (with selected template) or 'projects/{project\_id}/copy'
* The form contain attribute does not all project attributes by default (in contrast to delete the new value from scratch form)
* Only following project attributes are included in the form:
* Project attributes which are enabled in the source/template project
* _All_ required project attributes (which should be enabled in the source/template project anyway)
* database. After successful project creation, reactivating the described project attributes are enabled in the new project
* additionally
* project attributes with default values are enabled, if they were disabled in the source project and thus not shown (overwritable) in the form (OPEN POINT 6)
* all project attributes of type boolean are anabled (OPEN POINT 7)
#### Project export
* The project exports do not include custom values of disabled project attributes
#### Project list
* If an EE instance attribute it is set still available. In order to include specific project attributes in the list:
* The project list does not show the custom values of disabled project attributes in the row of delete a project
* The filter cannot target a custom value of disabled project attributes
#### API behavior
* No changes are made to from the projects API
* On project creation:
* If values for custom fields are provided, the custom fields are activated automatically after create
* On project update:
* Ff values for custom fields are provided, the custom fields are activated automatically after update, if not already activated
* Project attribute settings cannot be explicitly changed through the API
#### Important changes
* The administration menu item "Projects" redirects needs to the project attributes administration page now
* The other project settings ("Settings for new projects", "Settings for project overview list") are now shown when clicking on "Settings" in the submenu of "Projects"
* Project settings page should not show custom field inputs anymore? (OPEN POINT)
* Project details widget will be replaced with this text:
**Project details have now moved active. This is different to a column on the right edge of this page.**
Starting with version 13.4, project attributes can be grouped behavior in sections and enabled and disabled at a project level. Learn more work packages.
_This widget can now be removed or replaced. It will be deleted in subsequent versions._
#### Migrations
* All existing project custom fields will be assigned to an initial section called "Project attributes" (for all languages)
#### ## **"Simple text mode configuration" for custom fields of type long text**
* There is a setting per custom field of type long text to turn the CKEditor into a "simpler" / "dumber" mode.
* Setting this checkbox allows only certain inline functionality of the editor:
* Inline styles (bold, italic, etc.)
* Links
* Pictures
* Tables
* Code Snippets
* Macros
* Lists
* Spec extracted from <mention class="mention" data-id="51211" data-type="work_package" data-text="#51211">#51211</mention>
* Toggling the checkbox does not change the content whatsoever, there is no migration between a simple and rich text mode.
#### ## ##50844
workPackageValue:50844:description
## Copy project
* When copying a project the project attribute settings of the template project are copied as well.
### Open questions
* [ ] **Marc: Definition of the current mockups in mobile and all breakpoints.**
* [x] **Do the modal windows get scrollbars when needed? For example, for cross-screen text or for the permissions of the roles (because we have a few more roles in the system than shown here)?**
* [x] Product: Indeed. With our new Primer-based modals, the header and the action footer (buttons) remain fixed but the content area scrolls. This is true for the list of roles in the Manage permissions modal as it is for when viewing the contents of a long text project attribute in the Project overview.
* [x] **If "enabled and visible by default" is selected, are the attributes automatically included in newly created projects?**
* [x] Product: They are indeed; this option sets the default value for new projects.
* [x] **Are project attributes inherited / assigned when templates are used?**
* [x] Product: Yes. This current behaviour does not change, i.e, when a project is set as a template with a particular set of values for project attributes (previous project custom fields), the same values are pre-filled when a new project is created using that template. The user, of course, can modify these values as they please in the new project.
* [ ] **\[open\] Will the "Edit project" permission then also affect the editing of project attributes? Or will there be a separate authorization to be assigned here?**
* [ ] Niels: For editing project attributes there will a new permission. There needs to be a migration of permissions (like specified).
* [ ] When creating the project from scratch or from a template, should activating/deactivating properties be made available on the form? Without this, users might be forced to insert value to required custom fields even if they later on disable that field.
* [ ] Niels: Mandatory project attributes need to be shown in the project create form.
* [ ] Niels: When copying a project the mandatory fields need to be copied as well. There needs to be an error handling in case the project attribute has been changed to mandatory afterwards.
* [ ] For attributes disabled in a project will changes to them be visible in the project activities?
* [ ] Niels: Not sure if I understand this correctly. Deactivated project attributes can not be changed. So there can't be a new record in the project history. Concerning old changes that were created before the deactivation I don't have a strong opinion. What is easier to implement?
* [ ] For attributes disabled in a project, will they still show up in the API resource?
* [ ] Niels: Not sure. I would assume we do it like in work packages.
* [ ] For attributes disabled in a project, will updating them via the API still be possible?
* [ ] Niels: Not sure. I would assume we do it like in work packages.
* [ ] For attributes disabled in a project, will showing the project in the projects list still reveal the attributes? Probably not so I guess that they will simply be set to blank.
* [ ] Niels: Yes
* [ ] For attributes disabled in a project, will exporting the project still reveal the attributes? Probably not so I guess that they will simply be set to blank.
* [ ] Niels: Yes
* [ ] For attributes disabled in a project, what will be displayed for the projectValue and projectLabel macro in a wiki page?
* [ ] Niels: Let's show an error message that explains the problem.
### Visuals in Figma:
https://www.figma.com/file/Ya9Xz4HvWCzOmM64qfvGPm/Projects-attributes-and-project-settings?type=design&node-id=214-10525&mode=design https://www.figma.com/file/Ya9Xz4HvWCzOmM64qfvGPm/Projects-settings?type=design&node-id=214-10525&mode=design
**As a** project member or project admin
###
#### Project overview
* The project overview will maintain the current implementation of widgets but include a new right pane
* A section is only shown if at least one project
* If
* Clicking
* Saving this dialog automatically closes
* If an invalid value was entered, the dialog is not closed and form validations are displayed (standard Primer style)
* Thee dialog **cannot** be saved if a project attribute value _within_ this section is invalid
* The dialog **can** be save if all project attributes WITHIN this section are valid
* Each section is self-contained. If a
* For example, if a new required
* Special renderings in the sidebar:
* If
* Users are shown with their avatar
* Rich text values
* are properly formated (e.g. bold text is shown as bold...)
* are truncated when they are longer than 100 characters
* An "Expand"
* Multi user values are shown in a list
* Other multi values are shown comma-seperated
* If a project has no enabled project attributes, the
* For project admins with permission
* "Manage project attributes" (redirects to Project settings
## **Administration
* URL routing: `projects/{project_id}`
* Accessible to project members with
* Edit actions only available for project members with the permission "edit\_project"
#### Administration of project attributes
**Menu entries**
* There is
* Project attributes (default)
* New project
* Project lists
* The two sections
* **New project**:
* This will contain the same
* **Project lists**
* This will contain
*
**Project attributes**
* **Sections**: Project
* Sections can be re-ordered via drag and drop or action or menu buttons
*
* Sections can be deleted but only if no project attribute
* A new section can be created by clicking
* This section will be added to the top of the list.
* The More (..) button to the right of a section will display a drop-box with these options:
* Edit title (displays a dialog with an input field with the current tile pre-filled)
* Move to top (unless already at the top)
* Move up (unless already at the top)
* Move down (unless already at the bottom)
* Move to bottom (unless already at the bottom)
* Delete (requires confirmation)
* **Individual attributes:**
* Within a section box, all assigned project attributes are shown with their:
* Name
* Type (String, User, List...)
*
* Individual project attributes within a section can be re-ordered via drag and drop
* The More (..) button to the right
* Edit (redirects to
* Move to top (unless already at the top)
* Move up (unless already at the top)
* Move down (unless already at the bottom)
* Move to bottom (unless already at the bottom)
* Delete (requires confirmation)
* The order
* A project attribute can be moved to another section via drag
* A project
* **Creating project attributes:** A new attribute can be created by clicking on
* Changing the project attribute type (e.g. to list), will change the input fields directly
* Saving this form redirects back to list page, showing the new project attribute in the selected section
* If a project attribute is set to required, it gets automatically activated in all projects after create (with no option to disable it at a project-level)
* The visible setting does currently have no effect (OPEN POINT 1)
* An empty section additionally shows a button
* **Editing
* On the edit page, the existing "project custom field" form (as seen for all other custom field types, e.g. WorkPackage)
* In contrast
* Changing this moves the project attribute to a different section (as an alternative to the above described drag
* Saving
* If a project attribute is updated to be required, it gets automatically activated in all
* URL routing: `admin/settings/project_custom_fields`
* Only accessible ro admins
#### Project-level
* There is a
* All project custom fields are listed in boxes, grouped by their sections in the same order as defined in the global admin page
* The order of section/attributes cannot
* The project attributes are shown with their name, type and
* Each project attribute can be enabled/disabled (activated/deactivated) for
* The toggle switch is disable for required project attributes (in the on position)
* No extra confirmation is shown after using the toggle switch
* The "enable all"/"disable all" buttons per section allow bulk actions in order
* Required project attributes always stay activated and are not affected
* No extra confirmation is shown after using the mass edit buttons
* Disabling a project attribute does _not_ delete an assigned custom value
* A disabled project attribute and its custom value:
* Will not
* Will not be exported (specs below)
* Cannot be targeted
* For more convenience,
* When a filter is active, the bulk edit buttons are hidden
* URL routing: `projects/{project_id}/settings/project_custom_fields`
* Accessible to project members with
#### Project creation
* The following applies to project creation
* URL routing: `visit projects/new`
* The current project creation form is not changed at all
* All defined project attributes are visible within this form
* A project attribute gets automatically activated after project creation, if:
* The user provided a value for the project attribute
* The project attribute has a default value, which was not set to blank explicitly
* The project attribute is a boolean
* which is set to default
* which is set
* which has no default value and is not touched by the user -> activted and false (OPEN POINT 5)
* which has no default value is set to true by the user -> activted and true
* In all other cases, the
#### Project copy / Project creation with template
* based on
* copy of an existing project
* URL routing: 'visit projects/new' (with selected template) or 'projects/{project\_id}/copy'
* The form contain
* Only following project attributes are included in the form:
* Project attributes which are enabled in the source/template project
* _All_ required project attributes (which should be enabled in the source/template project anyway)
*
* additionally
* project attributes with default values are enabled, if they were disabled in the source project and thus not shown (overwritable) in the form (OPEN POINT 6)
* all project attributes of type boolean are anabled (OPEN POINT 7)
#### Project export
* The project exports do not include custom values of disabled project attributes
#### Project list
* If an EE instance
* The project list does not show the custom values of disabled project attributes in the row of
* The filter cannot target a custom value of disabled project attributes
#### API behavior
* No changes are made to
* On project creation:
* If values for custom fields are provided, the custom fields are activated automatically after create
* On project update:
* Ff values for custom fields are provided, the custom fields are activated automatically after update, if not already activated
* Project attribute settings cannot be explicitly changed through the API
#### Important changes
* The administration menu item "Projects" redirects
* The other project settings ("Settings for new projects", "Settings for project overview list") are now shown when clicking on "Settings" in the submenu of "Projects"
* Project settings page should not show custom field inputs anymore? (OPEN POINT)
* Project details widget will be replaced with this text:
**Project details have now moved
Starting with version 13.4, project attributes can be grouped
_This widget can now be removed or replaced. It will be deleted in subsequent versions._
#### Migrations
* All existing project custom fields will be assigned to an initial section called "Project attributes" (for all languages)
####
* There is a setting per custom field of type long text to turn the CKEditor into a "simpler" / "dumber" mode.
* Setting this checkbox allows only certain inline functionality of the editor:
* Inline styles (bold, italic, etc.)
* Links
* Pictures
* Tables
* Code Snippets
* Macros
* Lists
* Spec extracted from <mention class="mention" data-id="51211" data-type="work_package" data-text="#51211">#51211</mention>
* Toggling the checkbox does not change the content whatsoever, there is no migration between a simple and rich text mode.
####
workPackageValue:50844:description
* When copying a project the project attribute settings of the template project are copied as well.
* [ ] **Marc: Definition of the current mockups in mobile and all breakpoints.**
* [x] **Do the modal windows get scrollbars when needed? For example, for cross-screen text or for the permissions of the roles (because we have a few more roles in the system than shown here)?**
* [x] Product: Indeed. With our new Primer-based modals, the header and the action footer (buttons) remain fixed but the content area scrolls. This is true for the list of roles in the Manage permissions modal as it is for when viewing the contents of a long text project attribute in the Project overview.
* [x] **If "enabled and visible by default" is selected, are the attributes automatically included in newly created projects?**
* [x] Product: They are indeed; this option sets the default value for new projects.
* [x] **Are project attributes inherited / assigned when templates are used?**
* [x] Product: Yes. This current behaviour does not change, i.e, when a project is set as a template with a particular set of values for project attributes (previous project custom fields), the same values are pre-filled when a new project is created using that template. The user, of course, can modify these values as they please in the new project.
* [ ] **\[open\] Will the "Edit project" permission then also affect the editing of project attributes? Or will there be a separate authorization to be assigned here?**
* [ ] Niels: For editing project attributes there will a new permission. There needs to be a migration of permissions (like specified).
* [ ] When creating the project from scratch or from a template, should activating/deactivating properties be made available on the form? Without this, users might be forced to insert value to required custom fields even if they later on disable that field.
* [ ] Niels: Mandatory project attributes need to be shown in the project create form.
* [ ] Niels: When copying a project the mandatory fields need to be copied as well. There needs to be an error handling in case the project attribute has been changed to mandatory afterwards.
* [ ] For attributes disabled in a project will changes to them be visible in the project activities?
* [ ] Niels: Not sure if I understand this correctly. Deactivated project attributes can not be changed. So there can't be a new record in the project history. Concerning old changes that were created before the deactivation I don't have a strong opinion. What is easier to implement?
* [ ] For attributes disabled in a project, will they still show up in the API resource?
* [ ] Niels: Not sure. I would assume we do it like in work packages.
* [ ] For attributes disabled in a project, will updating them via the API still be possible?
* [ ] Niels: Not sure. I would assume we do it like in work packages.
* [ ] For attributes disabled in a project, will showing the project in the projects list still reveal the attributes? Probably not so I guess that they will simply be set to blank.
* [ ] Niels: Yes
* [ ] For attributes disabled in a project, will exporting the project still reveal the attributes? Probably not so I guess that they will simply be set to blank.
* [ ] Niels: Yes
* [ ] For attributes disabled in a project, what will be displayed for the projectValue and projectLabel macro in a wiki page?
* [ ] Niels: Let's show an error message that explains the problem.
### Visuals in Figma:
https://www.figma.com/file/Ya9Xz4HvWCzOmM64qfvGPm/Projects-attributes-and-project-settings?type=design&node-id=214-10525&mode=design