### User Story

**As a** project member or project admin
**I want to** view and edit project attributes in a structured way (organised in sections) on the project overview screen
**So that** I can more easily keep track of and manage a large project portfolios and communicate importants details about the individual project goals and benefits to project stakeholder.

### Acceptance criteria

#### Project overview <mention class="mention" data-id="51791" data-type="work_package" data-text="#51791">#51791</mention>&nbsp;

* The project overview will maintain the current implementation of widgets but include a new right pane (like in the Meetings module)
* This pane will display project attributes enabled for this project in their respective sections, along with their values (visible setting is respected, only admins can see/edit &quot;invisible&quot; project attributes)
* A section is only shown if at least one project attribute from that section is enabled for the project (if that number is zero, the section is hidden entirely)
* If the user has the permission &quot;edit\_project&quot;, each section shows an edit icon
* Clicking this icon opens a dialog showing inputs for all enabled project attributes contained in that section
* Saving this dialog automatically closes the dialog and 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
* Each section is self-contained. If a project attribute in section &quot;A&quot; is in an invalid state, a section &quot;B&quot; can still be saved.
* For example, if a new required project attributes is added to section &quot;A&quot;. section &quot;A&quot; is now technically in an invalid state. However, this does not affect Section &quot;B&quot;, which can be edited and saved normally.
* Special renderings in the sidebar:
* If a value is not set for a project attribute, &quot;-&quot; is shown
* Boolean 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 &quot;Expand&quot; 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
* If a project has no enabled project attributes, the sidebar is completely empty.
* A separate feature will address this blank state.
* Begin of the insertion~~ForEnd of the insertion Begin of the deletion ForEnd of the deletion project admins with permission to edit project attributes, there is a third More (...) button on the top right corner to the right of Add (+) with two Begin of the insertionoptions:~~End of the insertion Begin of the deletion options:End of the deletion
* Begin of the insertion~~&quot;ManageEnd of the insertion Begin of the deletion &quot;ManageEnd of the deletion project attributes&quot; (redirects to Project settings &gt; Project Begin of the insertionattribtues)~~End of the insertion Begin of the deletion attribtues)End of the deletion
* Begin of the insertion~~&quot;Archive project&quot;~~
* Moved to ###53576End of the insertion Begin of the deletion &quot;Archive project&quot;End of the deletion
* URL routing: `projects/{project_id}`
* Accessible to project members with the permission &quot;view\_project&quot;
* Edit actions only available for project members with the permission &quot;edit\_project&quot;

#### Administration of project Begin of the insertionattributesEnd of the insertion Begin of the deletion attributes End of the deletion

**Menu entries**

* There is a new menu entry in the Admin settings called &quot;Projects&quot; with these items:
* Project attributes (default)
* New project
* Project lists
* The two sections under the &quot;Settings&quot; sub-menu (Settings for new projects, Settings for project overview) will be split into two different pages: <mention class="mention" data-id="51793" data-type="work_package" Begin of the insertiondata-text="#51793">#51793</mention>End of the insertion Begin of the deletion data-text="#51793">#51793</mention> End of the deletion
* **New project**:
* This will contain the same settings as under &quot;Settings for new projects&quot;, without the h2 header
* The title of the page will be &quot;New project&quot;
* **Project lists**
* This will contain the same settings as under &quot;Settings for project overview list&quot;, without the h2 header
* The title of the page will be &quot;Project lists&quot;

**Project attributes** <mention class="mention" data-id="51789" data-type="work_package" Begin of the insertiondata-text="#51789">#51789</mention>End of the insertion Begin of the deletion data-text="#51789">#51789</mention> End of the deletion

* **Sections**: Project 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
* 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 is assigned to them
* A new section can be created by clicking on the &quot;+ Section&quot; 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)
* **Individual attributes:**
* Within a section box, all assigned project attributes are shown with their:
* Name
* Type (String, User, List...)
* the number of projects using this attribute
* a required label, if required
* Individual project attributes within a section can be re-ordered via drag and drop or action menu buttons
* The More (..) button to the right of an individual attribute will display a drop-box with these options:
* Edit (redirects to 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 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 and drop
* A project attribute can be deleted (after confirmation), even when it&#39;s used in a project (associated custom values will be deleted permanently!)
* **Creating project attributes:** A new attribute can be created by clicking on the &quot;+ Project attribute&quot; button on 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 behaves as it does currently (if &quot;Visible&quot; us unchecked, the attribute is visible only to admins).
* An empty section additionally shows a button for project attribute creation
* **Editing project attributes:** Each attribute can be edited by clicking on its name or clicking on the &quot;Edit&quot; action on the More dropdown menu
* On the edit page, the existing &quot;project custom field&quot; form (as seen for all other custom field types, e.g. WorkPackage) is rendered with a new header
* In contrast to the typical custom field form, a select box for the &quot;Section&quot; 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 and drop approach)
* Saving 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 projects after save (and can no longer be disabled at a project level)
* The visible setting behaves as it does currently (if &quot;Visible&quot; us unchecked, the attribute is visible only to admins).
* URL routing: `admin/settings/project_custom_fields`
* Only accessible ro admins

#### Project-level settings for project attributes <mention class="mention" data-id="51790" data-type="work_package" Begin of the insertiondata-text="#51790">#51790</mention>End of the insertion Begin of the deletion data-text="#51790">#51790</mention> End of the deletion

* There is a new entry in the Project settings called &quot;Project attributes&quot;
* All project custom fields are listed in boxes, grouped by their sections in the same order as defined in the global admin page ((visible setting is respected, only admins can see/enable/disable &quot;invisible&quot; project attributes)
* The order of section/attributes cannot be changed here
* The project attributes are shown with their name, type and a badge &quot;required&quot; if they are required
* Each project attribute can be enabled/disabled (activated/deactivated) for 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 &quot;enable all&quot;/&quot;disable all&quot; buttons per section allow bulk actions in order to mass edit the activation state of project attributes
* Required project attributes always stay activated and are not affected 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 be shown in the project overview page sidebar (specs below)
* Will not be exported (specs below)
* Cannot be targeted by a filter in the project list (specs below)
* For more convenience, the list can be filtered by project attribute name and type via search input below the header
* 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 the permission &quot;select\_project\_custom\_fields&quot;

#### Project creation <mention class="mention" data-id="53703" data-type="work_package" Begin of the insertiondata-text="#53703">#53703</mention>End of the insertion Begin of the deletion data-text="#53703">#53703</mention> End of the deletion

* The following applies to project creation 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 (visible setting is respected, only admins can see/edit &quot;invisible&quot; project attributes)
* 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 -&gt; true and is not touched by the user -&gt; activted and true
* which is set to default -&gt; true and is set to false by the user -&gt; activted and false
* which has no default value is set to true by the user -&gt; activted and true
* In all other cases, the project attribute is disabled in the created project, but can be enabled afterwards via project attribute settings page

#### Project copy / Project creation with template <mention class="mention" data-id="53705" data-type="work_package" Begin of the insertiondata-text="#53705">#53705</mention>End of the insertion Begin of the deletion data-text="#53705">#53705</mention> End of the deletion

* The following applies to project creation process:
* based on a template project or
* copy of an existing project
* URL routing: &#39;visit projects/new&#39; (with selected template) or &#39;projects/{project\_id}/copy&#39;
* The form contain not all project attributes by default (in contrast to the new 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)
* After successful project creation, the same project attributes as in the source project are enabled/disabled in the new project

#### Project export <mention class="mention" data-id="53733" data-type="work_package" Begin of the insertiondata-text="#53733">#53733</mention>End of the insertion Begin of the deletion data-text="#53733">#53733</mention> End of the deletion

* The project exports do not include custom values of disabled project attributes

#### Project list <mention class="mention" data-id="53007" data-type="work_package" Begin of the insertiondata-text="#53007">#53007</mention>End of the insertion Begin of the deletion data-text="#53007">#53007</mention> End of the deletion

* If an EE instance is set 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 a project
* The filter cannot target a custom value of disabled project attributes

#### API behavior <mention class="mention" data-id="51796" data-type="work_package" Begin of the insertiondata-text="#51796">#51796</mention>End of the insertion Begin of the deletion data-text="#51796">#51796</mention> End of the deletion

* No changes are made to the projects API
* Info: API is pulling info from project data model layer, API implicitly does not serve disabled project attributes (without having modified it).
* 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 &quot;Projects&quot; redirects to the project attributes administration page now
* The other project settings (&quot;Settings for new projects&quot;, &quot;Settings for project overview list&quot;) are now shown when clicking on &quot;Settings&quot; in the submenu of &quot;Projects&quot;
* Project settings page should not show custom field inputs anymore? (OPEN POINT)
* Project details widget will be replaced with this text: <mention class="mention" data-id="51794" data-type="work_package" Begin of the insertiondata-text="#51794">#51794</mention>End of the insertion Begin of the deletion data-text="#51794">#51794</mention> End of the deletion

**Project details have now moved to a column on the right edge of this page.**

Starting with version 13.5, project attributes can be grouped in sections and enabled and disabled at a project level. Learn more

_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 &quot;Project attributes&quot; (for all languages)

#### **&quot;Simple text mode configuration&quot; for custom fields of type long text**

* There is a setting per custom field of type long text to turn the CKEditor into a &quot;simpler&quot; / &quot;dumber&quot; 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

### Open questions

* [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 &quot;enabled and visible by default&quot; 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.
* [x] \[open\] Will the &quot;Edit project&quot; permission then also affect the editing of project attributes? Or will there be a separate authorization to be assigned here?
* [x] Niels: For editing project attributes there will a new permission. There needs to be a migration of permissions (like specified). See: #<mention class="mention" data-id="50844" data-type="work_package" data-text="#50844">#50844</mention>
* [x] 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.
* [x] Niels: Mandatory project attributes need to be shown in the project create form.
* [x] **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.**
* [x] **Jonas**: Required attributes gets enabled in all projects (incl. newly &quot;required&quot;) ones are visible in the copy screen. For existing projects, a value has to be entered the first time the containing section is edited (edit form has form validation). (So technically, projects _can_ be in an &quot;invalid&quot; state, if an existing project attributes is marked as required, but that attribute was not previously enabled in certain projects, so that value will be empty until the section containing that project attribute is first edited).
* [x] **Attila:** Works the same with project custom fields (newly required = empty).
* [x] **\[decision\] Visible setting: leave it as is.**
* [x] **For attributes disabled in a project will changes to them be visible in the project activities?**
* [x] Niels: Not sure if I understand this correctly. Deactivated project attributes can not be changed. So there can&#39;t be a new record in the project history. Concerning old changes that were created before the deactivation I don&#39;t have a strong opinion. What is easier to implement?
* [x] For disabled attributes, there should be no changes. For historical changes, we can leave the activity entries as-is.
* [x] The enabling/disabling project attributes is not recorded in project activities. (out of scope)
* [x] **For attributes disabled in a project, will they still show up in the API resource?**
* [x] Attila: They will not show up.
* [x] **For attributes disabled in a project, will updating them via the API still be possible?**
* [x] Jonas: If a project attribute is disabled, then you POST a value for it, it will be enabled for that project. (Not an explicit change to the API; implicit current behaviour).
* [x] Should we want to change this behaviour, we need to discuss and specify this change to the API structure.
* [x] **For attributes disabled in a project, will showing the project in the projects list still reveal the value of the attributes?**
* [x] Attila: In project lists, values for disabled project attributes (=values that were entered before the field was disabled) are not visible; the cell will be empty if the project attribute has been added as a column.
* [x] Additionally, values of displayed project attributes are not available via search.
* [x] **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.**
* [x] No, values for disabled project attributes are not included in exports.
* [x] **For attributes disabled in a project, what will be displayed for the projectValue and projectLabel macro in a wiki page?**
* [x] Niels: Let&#39;s show an error message that explains the problem. See: ###53009
* [x] **Any significant challenges for mobile responsiveness? (Separate mockups necessary?)**
* [x] Product submits bug reports for mobile (if required)

### Visuals in Figma:

https://www.figma.com/file/Ya9Xz4HvWCzOmM64qfvGPm/Projects-attributes-and-project-settings?type=design&amp;node-id=214-10525&amp;mode=design