Merge pull request #13780 from opf/documentation/fixes

Documentation/fixes

docs/development/contribution-documentation/README.md

@@ -34,7 +34,7 @@ Being proudly open source, we invite anyone in our community to contribute to ou
 
 ## What can you contribute to the documentation?
 
-Documentation improvements and changes apply to the documentation described in the section above. Documentation changes are **not** changes or additions to the code of the OpenProject application. For contributions to the code, see our [product development guide](../product-development-handbook/#openproject-product-development-handbook). 
+Documentation improvements and changes apply to the documentation described in the section above. Documentation changes are **not** changes or additions to the code of the OpenProject application. For contributions to the code, see our [product development guide](../product-development-handbook/). 
 
 We are looking forward to receiving the following contributions from you:
 

docs/development/product-development-handbook/README.md

@@ -99,7 +99,7 @@ The phase for requirements collection and specification aims to get the best pos
 
 For new ideas and requirements which are not clearly understood yet and require specification, Product Managers (PM), User Experience Experts / designers (UX), and the requesting party (e.g. customer or community member) work together to validate the idea before moving on to the build phase.
 
-Product Managers and UX prepare the work together at least one version (~ 2 months) ahead, so that the development team in the build phase has always well-defined and validated requirements ready to start. Especially requirements with a level of confidence lower 80% (see [RICE Score](#34-rice-score)) should be clearly validated.
+Product Managers and UX prepare the work together at least one version (~ 2 months) ahead, so that the development team in the build phase has always well-defined and validated requirements ready to start. Especially requirements with a level of confidence lower 80% (see [RICE Score](#42-rice-score)) should be clearly validated.
 
 The specification phase may not be necessary for bug fixes, minor design changes, minor improvements of smaller code maintenance topics.
 
@@ -116,7 +116,7 @@ The [OpenProject Wish List](https://community.openproject.com/projects/openproje
 Requirements should be captured as a **Feature** or **Epic** (for larger features which we can be broken down into smaller features) and focus on describing the customer’s problem rather than jumping ahead to a solution.
 For a guideline on how to report feature requests, refer to the [Feature request guideline](../../development/submit-feature-idea/). Technical maintenance issues and refactorings can be tracked as **Code Maintenance**.
 
-**Bugs** are [reported aside from the feature/epic track](../../development/report-a-bug/) as they are oftentimes not subject to an elaborate specification. On the other hand, sometimes bugs turn out to be caused by either the functionality implemented not meeting the users' expectations or by a not implemented feature. Upon identifying a bug to be such a case, it is treated as a feature. But most of the bugs upon collecting find their way into the [Bug backlog](https://community.openproject.org/projects/openproject/work_packages?query_id=491). Those are then picked up in the [Building phase 5: Stabilization](#325-building-phase-5-stabilization).
+**Bugs** are [reported aside from the feature/epic track](../../development/report-a-bug/) as they are oftentimes not subject to an elaborate specification. On the other hand, sometimes bugs turn out to be caused by either the functionality implemented not meeting the users' expectations or by a not implemented feature. Upon identifying a bug to be such a case, it is treated as a feature. But most of the bugs upon collecting find their way into the [Bug backlog](https://community.openproject.org/projects/openproject/work_packages?query_id=491). Those are then picked up in the [Building phase 5: Stabilization](#335-building-phase-5-stabilization).
 
 ### 3.1.2 Evaluation phase 2: Pre-evaluation
 
@@ -148,7 +148,7 @@ Those features judged positively by the PM:
 4. PM changes feature status from “New” to “In Specification”.
 5. PM assigns the feature either to the Product Backlog or to an upcoming version. Only rarely and in consultation with Development should PM assign a feature to the currently developed version.
 
-For internal or customer requirements requirements may directly be created, evaluated based on the [RICE framework](#34-rice-score) and assigned to the product backlog.
+For internal or customer requirements requirements may directly be created, evaluated based on the [RICE framework](#42-rice-score) and assigned to the product backlog.
 
 
 ### 3.1.4 Evaluation phase 4: Requirement specification
@@ -325,7 +325,7 @@ The entire team documents possible improvements for the next release.
 
 ### 4.1 Version/Release
 
-A version is the name given to a collection of features and/or bugfixes. A release is the publicly available version of the OpenProject software. More information is provided on the [release page](./releases/).
+A version is the name given to a collection of features and/or bugfixes. A release is the publicly available version of the OpenProject software. More information is provided on the [release page](../releases/).
 
 ### 4.2 RICE Score
 

docs/development/releases/README.md

@@ -49,4 +49,4 @@ OpenProject is distributed in [various formats](../../installation-and-operation
 
 ## Versions in the codebase
 
-The version is represented as [tags](../git-workflow#tags) and [branches](../git-workflow#branching-model) in the repository. The version is also manifested in the [version.rb](https://github.com/opf/openproject/blob/dev/lib/open_project/version.rb).
+The version is represented as [tags](../git-workflow#tagging) and [branches](../git-workflow#branching-model) in the repository. The version is also manifested in the [version.rb](https://github.com/opf/openproject/blob/dev/lib/open_project/version.rb).

docs/development/running-tests/README.md

@@ -210,13 +210,13 @@ Acceptance tests evaluate both functional and non-functional requirements.
 
 ##  Non-functional testing
 
-| Type                                                         | Description                                                  | Examples, References                                         |
-| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
-| [Stress and performance tests](#performance-tests)           | (Half-)automated or manual testing of the response of the application during higher load, or expected upper boundaries of customer-defined data | e.g., running and evaluating new query plans on existing, anonymized or simulated data that matches potential or known performance bottlenecks |
-| [Security tests](#security-tests)                            | Automated or manually crafted test cases for evaluating application security by assuming the role of an attacker, e.g., by providing malicious user input or trying to break the application. | Statical and automated code scanning (CodeQL, Brakeman), defined test cases for verifying security related input as defined in the [secure coding guidelines](https://www.openproject.org/docs/development/concepts/secure-coding/). |
-| [Installation / upgrade tests](#installation-and-upgrade-tests) | Automated and manual installation tests of OpenProject       | Packaged installation build tests for various distributions, Docker installation smoke tests for verifying correct startup and basic operation of the container. |
-| [Usability tests](#usability-tests)                          | Evaluating the UX of the application as defined and in comparison to the requirements. Involves QA, Product, Customer. | e.g., verifying common use-cases as defined in the requirements in an early development stage (such as a PullPreview deployment), or on a pre-released version of the application. |
-| [Accessibility tests](#accessibility-tests)                  | Evaluating the accessibility of the application according to [WCAG AA](https://www.w3.org/WAI/WCAG2AA-Conformance) and similar standards | Performing automated keyboard navigation tests. <br />Manually executing screen readers to ensure application can be used. |
+| Type                                                            | Description                                                                                                                                                                                   | Examples, References                                                                                                                                                                                                                 |
+|-----------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| [Stress and performance tests](#performance-tests)              | (Half-)automated or manual testing of the response of the application during higher load, or expected upper boundaries of customer-defined data                                               | e.g., running and evaluating new query plans on existing, anonymized or simulated data that matches potential or known performance bottlenecks                                                                                       |
+| [Security tests](#security-tests)                               | Automated or manually crafted test cases for evaluating application security by assuming the role of an attacker, e.g., by providing malicious user input or trying to break the application. | Statical and automated code scanning (CodeQL, Brakeman), defined test cases for verifying security related input as defined in the [secure coding guidelines](https://www.openproject.org/docs/development/concepts/secure-coding/). |
+| [Installation / upgrade tests](#installation-and-upgrade-tests) | Automated and manual installation tests of OpenProject                                                                                                                                        | Packaged installation build tests for various distributions, Docker installation smoke tests for verifying correct startup and basic operation of the container.                                                                     |
+| [Usability tests](#usability-testing)                           | Evaluating the UX of the application as defined and in comparison to the requirements. Involves QA, Product, Customer.                                                                        | e.g., verifying common use-cases as defined in the requirements in an early development stage (such as a PullPreview deployment), or on a pre-released version of the application.                                                   |
+| [Accessibility tests](#accessibility-tests)                     | Evaluating the accessibility of the application according to [WCAG AA](https://www.w3.org/WAI/WCAG2AA-Conformance) and similar standards                                                      | Performing automated keyboard navigation tests. <br />Manually executing screen readers to ensure application can be used.                                                                                                           |
 
 
 

docs/installation-and-operations/installation/docker/README.md

@@ -264,7 +264,7 @@ The default scenario is to have OpenProject serve the whole virtual host.
 This requires no further configuration for the docker container beyond what is
 described above.
 
-Let's assume we want OpenProject to be accessed under https://openproject.example.com.
+Let's assume we want OpenProject to be accessed under `https://openproject.example.com`.
 
 The **apache** configuration for this looks as follows.
 

docs/installation-and-operations/installation/univention/README.md

@@ -5,7 +5,7 @@ sidebar_navigation:
 
 # OpenProject in Univention App Center
 
-Univention App Center is the marketplace in [Univention Corporate Server (UCS)](https://www.univention.com/products/ucs/), an enterprise operating platform for infrastructure and identity management. OpenProject is available in the [App Center](https://www.univention.com/appid/openproject/) and comes integrated with the identity management.
+Univention App Center is the marketplace in [Univention Corporate Server (UCS)](https://www.univention.com/products/ucs/), an enterprise operating platform for infrastructure and identity management. OpenProject is available in the [App Center](https://www.univention.com/products/app-catalog/openproject/) and comes integrated with the identity management.
 
 
 **App Appliance for easy deployment**
@@ -23,4 +23,4 @@ With the App Appliance you can easily deploy your own OpenProject server in a vi
 2. Install OpenProject via Univention App Center
 3. Add user accounts
 
-[![Available in Univention App Center](logo_uac_final.svg)](https://www.univention.com/appid/openproject)
+[![Available in Univention App Center](logo_uac_final.svg)](https://www.univention.com/products/app-catalog/openproject/)

docs/system-admin-guide/system-settings/project-system-settings/README.md

@@ -13,7 +13,8 @@ To adapt the system project settings, navigate to *Administration -> System sett
 
 1. Check if **new projects are public by default**. This means that users without an account can access the project without login.
 2. Select **which modules should be activated for newly created projects by default**.
-3. The **role given to a user in a new project when the user creates a new project but is not an (global) admin**. This makes sense when a user receives the permission to create a new project via [global role](../../users-permissions/roles-permissions/#global-roles).![image-20211209165901453](image-20211209165901453.png)
+3. The **role given to a user in a new project when the user creates a new project but is not an (global) admin**. This makes sense when a user receives the permission to create a new project via [global role](../../users-permissions/roles-permissions/#global-role).
+   ![image-20211209165901453](image-20211209165901453.png)
 
 ## Settings for the Projects Overview List
 1. Choose **which columns should be visible** in the Projects Overview List by default.

docs/system-admin-guide/users-permissions/placeholder-users/README.md

@@ -13,13 +13,13 @@ In [OpenProject Enterprise on-premises](https://www.openproject.org/enterprise-e
 Placeholder users can be used to plan a project with or for users who haven't been added to that project yet. This way you can set up projects before staffing them.
 Another use case would be to include customers, vendors or partners in your planning without them knowing it.
 
-Placeholder users can be managed by system admins and by users with the [role](../roles-permissions/#global-roles) "Create, edit and delete placeholder users".
+Placeholder users can be managed by system admins and by users with the [role](../roles-permissions/#global-role) "Create, edit and delete placeholder users".
 
 
-| Topic                                                        | Content                                              |
-| ------------------------------------------------------------ | ---------------------------------------------------- |
-| [Placeholder user list](#placeholder-user-list)              | Manage placeholder users in OpenProject.             |
-| [Create placeholder users](#create-placeholder-users)        | Add new placeholder users.                           |
+| Topic                                                                 | Content                                              |
+|-----------------------------------------------------------------------|------------------------------------------------------|
+| [Placeholder user list](#placeholder-user-list)                       | Manage placeholder users in OpenProject.             |
+| [Create placeholder users](#create-placeholder-users)                 | Add new placeholder users.                           |
 | [Manage placeholder user settings](#manage-placeholder-user-settings) | Change names and add placeholders users to projects. |
 
 

docs/system-admin-guide/users-permissions/roles-permissions/README.md

@@ -50,7 +50,7 @@ A user can have one or more roles which grant permissions on different levels.
 
 ### Non-member
 
-**Non member** is the default role of users of your OpenProject instance who have not been added to a project. This only applies if the project has been set as **[public](../user-guide/projects/#set-a-project-to-public)** in the project settings.<br />
+**Non member** is the default role of users of your OpenProject instance who have not been added to a project. This only applies if the project has been set as **[public](../../../user-guide/projects/#set-a-project-to-public)** in the project settings.<br />
 
 **Note:** The *Non-member* role cannot be deleted. 
 
@@ -95,13 +95,13 @@ To create the new role, click on the grey *Create* button at the bottom of the p
 
 Administrators can create new global roles in *Administration* > *Users and permissions* > *Roles and permissions*. In the creation form check the box **Global role**. The form now shows the available global permissions which can be assigned to the new global role:
 
-- **[Create projects](../../getting-started/projects/#create-a-new-project)**
+- **[Create projects](../../../getting-started/projects/#create-a-new-project)**
 
   > **Note:** To create a subproject for an existing project it requires also the project permission "Create subprojects".
 
-- **[Create backups](../backup/)**
+- **[Create backups](../../backup/)**
 
-- **[Create users](../users-permissions/users/#create-users)**
+- **[Create users](../../users-permissions/users/#create-users)**
 
 - **[Edit users](../users/)**
 

docs/user-guide/members/README.md

@@ -48,7 +48,7 @@ Members will have different roles with different permissions in a project. To fi
 A **role** is defined as a set of permissions defined by a unique name. Project members are assigned to a project by specifying a user's, group's or placeholder user's name and the role(s) they should assume in the project.
 </div>
 
-To assign work packages to a project member, the respective user's or placeholder user's role needs to be able to be assigned work packages. This is the default setting for default roles. You can check this setting in the [Roles and Permissions section](../../system-admin-guide/users-permissions/roles-permissions/#create-a-new-role) of the system administration.
+To assign work packages to a project member, the respective user's or placeholder user's role needs to be able to be assigned work packages. This is the default setting for default roles. You can check this setting in the [Roles and Permissions section](../../system-admin-guide/users-permissions/roles-permissions/) of the system administration.
 
 
 ## Groups