mirror of
https://github.com/opf/openproject.git
synced 2026-06-14 03:30:14 +00:00
Merge branch 'release/15.4' into dev
This commit is contained in:
OpenProject Actions CI
@@ -16,7 +16,7 @@ Here you can test all OpenProject functionalities thoroughly. After 14 days the
|
||||
|
||||
To create a new OpenProject trial, either go to the [OpenProject website](https://www.openproject.org/) or open the [start trial page](https://start.openproject.com).
|
||||
|
||||
**Enter your organization domain**. This name will become part of the URL of your OpenProject installation, for example *myneworganization.openproject.com*.
|
||||
**Enter your organization domain**. This name will become part of the URL of your OpenProject installation, for example `myneworganization.openproject.com`.
|
||||
|
||||
You can include a hyphen "-" in the organization name, e.g. *my-new-organization.openproject.com*.
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ If you want to see the billing history or download older invoices of your Enterp
|
||||
|
||||
Click the **Manage subscription** button.
|
||||
|
||||
|
||||
|
||||
|
||||
In the overlay window, click on the link **Billing History**.
|
||||
|
||||
@@ -36,4 +36,4 @@ Here, you will get an overview about all your past payments for the Enterprise c
|
||||
|
||||
With the **Download link** you can download the invoices.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ To upgrade or downgrade your Enterprise cloud subscription, follow the steps des
|
||||
|
||||
Alternatively, you can navigate to *Administration -> Subscription* and click the **Upgrade subscription** button directly.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ sidebar_navigation:
|
||||
title: Sign in
|
||||
priority: 997
|
||||
description: Sign in to your OpenProject Enterprise cloud edition.
|
||||
keywords: sign in, cloud, openproject enterpise
|
||||
keywords: sign in, cloud, openproject enterprise
|
||||
---
|
||||
|
||||
# Sign in to the OpenProject Enterprise cloud edition
|
||||
@@ -18,7 +18,7 @@ In order to sign in to your OpenProject Enterprise cloud edition directly throug
|
||||
|
||||
|
||||
|
||||
Enter your OpenProject instance name. This is the name that appears in the first part of the URL, e.g. myneworganization.openproject.com.
|
||||
Enter your OpenProject instance name. This is the name that appears in the first part of the URL, e.g. `myneworganization.openproject.com`.
|
||||
|
||||
Click the **Sign in** button to access your OpenProject installation.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ At the end, you will find a complete list of all changes and bug fixes.
|
||||
<!-- Warning: Anything within the below lines will be automatically removed by the release script -->
|
||||
<!-- BEGIN AUTOMATED SECTION -->
|
||||
|
||||
- Bugfix: Meeting organiser does not receive their own meeting invites \[[#61427](https://community.openproject.org/wp/61427)\]
|
||||
- Bugfix: Meeting organizer does not receive their own meeting invites \[[#61427](https://community.openproject.org/wp/61427)\]
|
||||
- Bugfix: Internal Server Error when export with open overview screen panel \[[#61726](https://community.openproject.org/wp/61726)\]
|
||||
- Bugfix: PDF Export: table cell border/background styles definition in yml file is ignored \[[#61749](https://community.openproject.org/wp/61749)\]
|
||||
- Bugfix: Form configuration requires reload - without reload the configuration of relations tables fail \[[#61919](https://community.openproject.org/wp/61919)\]
|
||||
|
||||
@@ -169,7 +169,7 @@ For more information, see [this code maintenance work package on our Community i
|
||||
- Bugfix: Always Show CKeditor Tool Bar On Screen When Scrolling \[[#53451](https://community.openproject.org/wp/53451)\]
|
||||
- Bugfix: Calendar headers don't respect date format (always show it in North American MM/DD format) \[[#54378](https://community.openproject.org/wp/54378)\]
|
||||
- Bugfix: Search results for projects does not render the description correctly \[[#56694](https://community.openproject.org/wp/56694)\]
|
||||
- Bugfix: After Updating and saving a value in a Project atribute with type user It isn't shown in the information project page \[[#57504](https://community.openproject.org/wp/57504)\]
|
||||
- Bugfix: After Updating and saving a value in a Project attribute with type user It isn't shown in the information project page \[[#57504](https://community.openproject.org/wp/57504)\]
|
||||
- Bugfix: If user removes all columns for their PDF export then default columns are used \[[#57618](https://community.openproject.org/wp/57618)\]
|
||||
- Bugfix: Project members: Unexpected opening of links in new tab (target="\_blank") \[[#58135](https://community.openproject.org/wp/58135)\]
|
||||
- Bugfix: Download button for backup does not work \[[#60720](https://community.openproject.org/wp/60720)\]
|
||||
@@ -192,7 +192,7 @@ For more information, see [this code maintenance work package on our Community i
|
||||
- Bugfix: Unclear error message upon save on empty Subject patterns \[[#61619](https://community.openproject.org/wp/61619)\]
|
||||
- Bugfix: Wrong tab opens upon error message on Subject configuration tab \[[#61625](https://community.openproject.org/wp/61625)\]
|
||||
- Bugfix: Redis cache fills up over time \[[#61633](https://community.openproject.org/wp/61633)\]
|
||||
- Bugfix: The costlog edit form shows incorrect cost value after update \[[#61689](https://community.openproject.org/wp/61689)\]
|
||||
- Bugfix: The cost log edit form shows incorrect cost value after update \[[#61689](https://community.openproject.org/wp/61689)\]
|
||||
- Bugfix: OIDC data sent to AppSignal \[[#61691](https://community.openproject.org/wp/61691)\]
|
||||
- Bugfix: Rescheduled series creates invalid open meetings \[[#61729](https://community.openproject.org/wp/61729)\]
|
||||
- Bugfix: Edit relation modal doesn't show the WP subject \[[#61737](https://community.openproject.org/wp/61737)\]
|
||||
@@ -209,7 +209,7 @@ For more information, see [this code maintenance work package on our Community i
|
||||
- Bugfix: Not possible to re-allocate / move booked time to work packages in other projects \[[#62066](https://community.openproject.org/wp/62066)\]
|
||||
- Bugfix: "New child" modal closes unexpectedly on mouse release outside. Confirmation also missing. \[[#62076](https://community.openproject.org/wp/62076)\]
|
||||
- Bugfix: Trying to create OIDC user tokens, even for non-OIDC providers \[[#62086](https://community.openproject.org/wp/62086)\]
|
||||
- Bugfix: Activity journals around scheduling mode changes aren't adapted to the new scheduling mode \[[#62091](https://community.openproject.org/wp/62091)\]
|
||||
- Bugfix: Activity journals around scheduling mode changes aren't adapted to the new scheduling mode \[[#62091](https://community.openproject.org/wp/62091)\]
|
||||
- Bugfix: work packages links in relation tab should open in same browser tab \[[#62109](https://community.openproject.org/wp/62109)\]
|
||||
- Bugfix: The Version custom field options are not grouped on the project general settings page \[[#62160](https://community.openproject.org/wp/62160)\]
|
||||
- Feature: Generate PDF document from a work package description \[[#45896](https://community.openproject.org/wp/45896)\]
|
||||
|
||||
@@ -10,7 +10,7 @@ keywords: file storages, document category, document categories
|
||||
|
||||
To create or edit document categories in OpenProject, navigate to *Administration → Files → Categories*. Here, you will see all existing values. You can adjust the items within the list by using the options behind the **More (three dots)** menu on the right side. You can also rearrange the order by using the drag-and-drop handle on the left.
|
||||
|
||||
|
||||
|
||||
|
||||
## Create new document category
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 53 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 57 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
@@ -7,94 +7,41 @@ keywords: github integration
|
||||
---
|
||||
# GitHub integration
|
||||
|
||||
OpenProject offers an integration with GitHub pull requests (PRs) to link software development closely to planning and specification.
|
||||
You create a pull request in GitHub and link it to an OpenProject work package.
|
||||
OpenProject offers an integration with GitHub pull requests (PRs) to link software development closely to planning and specification. You can create pull requests in GitHub and link them directly to OpenProject work packages.
|
||||
|
||||
## Overview
|
||||
|
||||
OpenProject work packages will directly display information from GitHub in a separate tab.
|
||||
|
||||
|
||||
|
||||
|
||||
The tab shows all PRs linked to a work package with their corresponding status (e.g. 'Open' or 'Merged') as well as the state (e.g. 'success' or 'queued') of the GitHub actions configured to run for a PR. PRs and work packages are in an n:m relationship, so a work package can be linked to multiple PRs and a PR can be linked to multiple work packages.
|
||||
The GitHub tab shows all PRs linked to a work package with their corresponding statuses (e.g. 'Open' or 'Merged') as well as the state (e.g. 'success' or 'queued') of the GitHub actions configured to run for a PR. PRs and work packages are in an n:m relationship, so a work package can be linked to multiple PRs and a PR can be linked to multiple work packages.
|
||||
|
||||
Additionally, in your OpenProject work package, the GitHub integration supports you to create a branch straight from the work package and consequently the matching pull request.
|
||||
Additionally, in your OpenProject work package, the GitHub integration supports you in creating a branch straight from the work package and the corresponding pull request.
|
||||
|
||||
|
||||
|
||||
Pull request activities will also show up in the Activity tab when the pull request is
|
||||
|
||||
|
||||
Pull request activities will also appear in the Activity tab when the pull request is:
|
||||
* first referenced (usually when opened)
|
||||
* marked ready for review
|
||||
* merged
|
||||
* closed
|
||||
|
||||
|
||||
|
||||
## Create a pull request
|
||||
|
||||
As pull requests are based on branches, a new branch needs to be created first. For that, open the GitHub tab in your OpenProject work package detail view. Click on 'Git snippets' to extend the menu. First, copy the branch name by clicking the corresponding button.
|
||||
|
||||
|
||||
|
||||
Then, open your git client, e.g. GitHub desktop or a console. There, you create your branch with the name you copied from your OpenProject work package. That way, all the branches will follow a common pattern and as the OpenProject ID is included in the branch name, it will be easy to see the connection between a PR and a work package when taking a look at a list of PRs on GitHub.
|
||||
|
||||
|
||||
|
||||
With the branch opened, you can start the actual development work using whatever tool you deem to be the best (it is VIM BTW), to alter your codebase.
|
||||
|
||||
|
||||
|
||||
Once you are satisfied with the changes you create a commit. Within the 'Git snippets' menu, OpenProject suggests a commit message for you based on the title and the URL of the work package.
|
||||
|
||||
|
||||
|
||||
A URL pointing to a work package within a pull request description or a comment will lead to the two entities becoming linked. Using the value in the 'Commit message' input thus helps you to establish that link. The link needs to be in the PR and not in a commit but GitHub will use the first commit message as the proposed branch description (as long as there is only one commit).
|
||||
|
||||
|
||||
|
||||
Once the branch is published,
|
||||
|
||||
|
||||
|
||||
you create your pull request. Title and comment with the link to the respective OpenProject work package will be prefilled, at least if there is only one commit to the branch. Because of this one commit limitation and if the policy is to create a branch as early as possible, there is a third option in the 'Git snippets' menu ('Create branch with empty commit') that will open a branch and add an empty commit to it in one command. Using this option, one can first create the branch quickly and have it linked to the work package right from the beginning. Commits can of course be added to the branch (and PR) after that.
|
||||
|
||||
The branch description can be amended before a PR is created giving the opportunity to further describe the changes. To help with that, it is also possible to copy parts of the work package description since the description can be displayed in the markdown format. Links to additional work packages can also be included in the PR description.
|
||||
|
||||
Rather than inserting a link to the work package you can also reference it just by adding "OP#87" to the pull request's description where 87 is the ID of the work package.
|
||||
|
||||
|
||||
|
||||
Click on **Create pull request** and your pull request will be opened.
|
||||
|
||||
|
||||
|
||||
When you click on the link in the comment, it will take you to the OpenProject work package, where you will see in the Activity tab of the work package that the pull request was created.
|
||||
|
||||
|
||||
|
||||
In the GitHub tab of that work package, the status of the pull request as well as status of all the configured GitHub Actions will also be displayed.
|
||||
|
||||
|
||||
|
||||
If the status of a pull request changes, it will accordingly appear in its OpenProject work package. Please see the example below.
|
||||
|
||||
|
||||
|
||||
|
||||
## Configuration
|
||||
|
||||
You will have to configure both OpenProject and GitHub for the integration to work.
|
||||
To enable the integration, you must configure both OpenProject and GitHub.
|
||||
|
||||
### OpenProject
|
||||
|
||||
First you will need to create a user in OpenProject that will make the comments.
|
||||
The user will have to be added to each project with a role that allows them
|
||||
to see work packages and comment on them.
|
||||
First, create a user in OpenProject to make the comments. Add this user to each project with a role that grants permission to view and comment on work packages.
|
||||
|
||||
The role needs two permissions and should only receive those two: "View work packages" and "Add notes" which you will find in the "Work packages and Gantt charts" section.
|
||||
First you will need to create a user in OpenProject that has the permission to make comments. We recommend creating a dedicated role and assigning this role to the user. This role only requires two permissions, *View work packages* and *Add notes*, which you will find in the Work packages and Gantt charts section under [Roles and Permissions](../../users-permissions/roles-permissions/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Once the user is created you need to generate an OpenProject API token for this user (you will need it on the GitHub side). For this you have to:
|
||||
|
||||
@@ -103,32 +50,102 @@ Once the user is created you need to generate an OpenProject API token for this
|
||||
3. Go to [*Access Tokens*](../../../user-guide/account-settings/#access-tokens)
|
||||
4. Click on **+ API token**
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Make sure you copy the generated key and securely save it, as you will not be able to retrieve it later.
|
||||
|
||||
You can then configure the necessary webhook in GitHub.
|
||||
|
||||
Finally you will need to activate the GitHub module under [Project settings](../../../user-guide/projects/project-settings/modules/) so that all information pulling through from GitHub will be shown in the work packages.
|
||||
|
||||
|
||||
|
||||
|
||||
Seeing the 'GitHub' tab requires **Show GitHub content** permission, so this permission needs to be granted to all roles in a project allowed to see the tab.
|
||||
To see the 'GitHub' tab, users need the **Show GitHub content** permission. Ensure this is granted to all roles that require access
|
||||
|
||||
### GitHub
|
||||
|
||||
In GitHub you have to set up a webhook in each repository to be integrated with OpenProject.
|
||||
|
||||
|
||||
|
||||
|
||||
You need to configure just two things in the webhook.
|
||||
Only two settings need to be configured in the webhook.
|
||||
The **Content Type** has to be `application/json`.
|
||||
The **Payload URL** must point to your OpenProject server's GitHub webhook endpoint (`/webhooks/github`).
|
||||
|
||||
> **Note**: For the events that should be triggered by the webhook, please select "Send me everything".
|
||||
> [!NOTE]
|
||||
> For the events that should be triggered by the webhook, please select "Send me everything".
|
||||
|
||||
Now you need the API key you copied earlier. Append it to the *Payload URL* as a simple GET parameter named `key`. In the end the URL should look something like this:
|
||||
You will need the API key you copied earlier in OpenProject. Append it to the *Payload URL* as a simple GET parameter named `key`. In the end the URL should look something like this:
|
||||
|
||||
`https://myopenproject.com/webhooks/github?key=42`
|
||||
|
||||
_Earlier version may have used the `api_key` parameter. In OpenProject 10.4, it is `key`._
|
||||
|
||||
Now the integration is set up on both sides and you can use it.
|
||||
|
||||
## Using GitHub integration
|
||||
|
||||
### Using a Git Desktop Client
|
||||
|
||||
As pull requests are based on branches, a new branch needs to be created first. For that, open the GitHub tab in your OpenProject work package detail view. Click on 'Git snippets' to extend the menu. First, copy the branch name by clicking the corresponding button.
|
||||
|
||||
|
||||
|
||||
Then, open your GitHub desktop client. There, you create your branch with the name you copied from your OpenProject work package. That way, all the branches will follow a common pattern and as the OpenProject ID is included in the branch name, it will be easy to see the connection between a PR and a work package when taking a look at a list of PRs on GitHub.
|
||||
|
||||
|
||||
|
||||
Once you click the *Create branch* button, you can directly publish that branch in the next step.
|
||||
|
||||
|
||||
|
||||
With the branch opened, you can start the actual development work using whatever tool you prefer, to alter your codebase.
|
||||
|
||||
|
||||
|
||||
Once your changes are complete, create a commit. To do that, copy the suggested *Commit message* from the *Git snippets* dropdown menu. It is based on the title and the URL of the work package.
|
||||
|
||||
|
||||
|
||||
A URL pointing to a work package within a pull request description or a comment will lead to the two entities becoming linked. Using the value in the 'Commit message' input thus helps you to establish that link. The link needs to be in the PR and not in a commit but GitHub will use the first commit message as the proposed branch description (as long as there is only one commit).
|
||||
|
||||
|
||||
|
||||
You can now create your pull request by clicking the *Commit* button. Title and comment with the link to the respective OpenProject work package will be prefilled, at least if there is only one commit to the branch. Because of this one commit limitation and if the policy is to create a branch as early as possible, there is a third option in the 'Git snippets' menu ('Create branch with empty commit') that will open a branch and add an empty commit to it in one command. Using this option, one can first create the branch quickly and have it linked to the work package right from the beginning. Commits can of course be added to the branch (and PR) after that.
|
||||
|
||||
The branch description can be amended before a PR is created giving the opportunity to further describe the changes. To help with that, it is also possible to copy parts of the work package description since the description can be displayed in the markdown format. Links to additional work packages can also be included in the PR description.
|
||||
|
||||
Instead of inserting a full link to the work package, you can reference it by adding 'OP#87' (where 87 is the work package ID) to the pull request description.
|
||||
|
||||
|
||||
|
||||
Click on **Create pull request** and your pull request will be opened. You can then assign it for a review or further modify your PR by adding a new commit. Once the PR is finalized, you can merge it by clicking the respective button.
|
||||
|
||||
|
||||
|
||||
In OpenProject you will see the changes of the PR status under Activity tab. Under GitHub tab you will also see the status change of all the configured GitHub Actions.
|
||||
|
||||
|
||||
|
||||
### Using the Command Line Interface
|
||||
|
||||
If you prefer to work with Git via the Command Line Interface (CLI), you can follow a similar process to create and manage pull requests, by following same steps as you would if using a Git Desktop Client.
|
||||
|
||||
You can copy the branch name from the OpenProject work package as described in the Git snippets section above. Then, create and switch to a new branch in your local repository. Modify the necessary files in your repository. Once you are satisfied with the changes, stage and commit them, using the suggested commit message from OpenProject.
|
||||
|
||||
|
||||
|
||||
When using a CLI you can also use the **Create branch with empty commit** Git snippet.
|
||||
|
||||
|
||||
|
||||
The advantage of using this snippet is that there is no need to first create a branch and then copy a separate Git snippet for the commit. A new branch will be created from your current branch along with an empty commit, which when pushed to GitHub will link back to the work package.
|
||||
|
||||
|
||||
|
||||
Continue your work as you normally would, push the branch to GitHub and create a pull request.
|
||||
|
||||
|
||||
|
||||
Changes to the pull request will be tracked under GitHub tab of OpenProject work package, from which git snippets were copied.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 140 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 532 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 123 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 223 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 426 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 347 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 153 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 157 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 136 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 302 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 229 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 502 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 450 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 426 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB |
@@ -51,6 +51,7 @@ Once the user is created you need to generate an OpenProject API token for this
|
||||
3. Go to [*Access Tokens*](../../../user-guide/account-settings/#access-tokens)
|
||||
4. Click on **+ API token**
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Make sure you copy the generated key and securely save it, as you will not be able to retrieve it later.
|
||||
|
||||
You can then configure the necessary webhook in [GitLab](#gitlab).
|
||||
@@ -75,20 +76,20 @@ You will need the API key you copied earlier in OpenProject. Append it to the *U
|
||||
|
||||
`https://myopenproject.com/webhooks/gitlab?key=4221687468163843`
|
||||
|
||||
> **Note**: For the events that should be triggered by the webhook, please select the following
|
||||
>
|
||||
> - Push events (all branches)
|
||||
> - Comments
|
||||
> - Issues events
|
||||
> - Merge request events
|
||||
> - Pipeline events
|
||||
For the events that should be triggered by the webhook, please select the following
|
||||
|
||||
- Push events (all branches)
|
||||
- Comments
|
||||
- Issues events
|
||||
- Merge request events
|
||||
- Pipeline events
|
||||
|
||||
|
||||
> **Note**: Please note that the *Pipeline events* part of the integration is still in the early stages. If you have any feedback on the *Pipeline events*, please let us know [here](https://community.openproject.org/wp/54574).
|
||||
> [!NOTE] Please note that the *Pipeline events* part of the integration is still in the early stages. If you have any feedback on the *Pipeline events*, please let us know [here](https://community.openproject.org/wp/54574).
|
||||
|
||||
|
||||
> **Note**: If you are in a local network you might need to allow requests to the local network in your GitLab instance.
|
||||
> You can find this settings in the **Outbound requests** section when you navigate to **Admin area -> Settings -> Network**.
|
||||
> [!TIP]
|
||||
> If you are in a local network you might need to allow requests to the local network in your GitLab instance. You can find this settings in the **Outbound requests** section when you navigate to **Admin area -> Settings -> Network**.
|
||||
|
||||
We recommend that you enable the **SSL verification** before you **Add webhook**.
|
||||
|
||||
@@ -105,13 +106,15 @@ Before upgrading, please do the following:
|
||||
|
||||
## Using GitLab integration
|
||||
|
||||
### Create merge requests
|
||||
### Using a Git Desktop Client
|
||||
|
||||
#### Create merge requests
|
||||
|
||||
As merge requests are based on branches, a new branch needs to be created first. For that, open the GitLab tab in your OpenProject work package detailed view. Click on **Git snippets** to extend the menu. First, copy the branch name by clicking the corresponding button.
|
||||
|
||||
|
||||
|
||||
Then, open your git client, e.g. Git desktop client or a console. There, you can create your branch by entering the branch name you copied from your OpenProject work package. That way, all the branches will follow a common pattern and as the OpenProject ID is included in the branch name, it will be easy to see the connection between a MR and a work package when taking a look at a list of MRs on GitLab.
|
||||
Then, open your Git desktop client. There, you can create your branch by entering the branch name you copied from your OpenProject work package. That way, all the branches will follow a common pattern and as the OpenProject ID is included in the branch name, it will be easy to see the connection between a MR and a work package when taking a look at a list of MRs on GitLab.
|
||||
|
||||
|
||||
|
||||
@@ -157,6 +160,29 @@ If the status of a merge request changes, it will be reflected in the OpenProjec
|
||||
|
||||
|
||||
|
||||
### Using the Command Line Interface
|
||||
|
||||
If you prefer to work with Git via the Command Line Interface (CLI), you can follow a similar process to create and manage merge requests, by following same steps as you would if using a Git Desktop Client.
|
||||
|
||||
You can copy the branch name from the OpenProject work package as described in the Git snippets section above. Then, create and switch to a new branch in your local repository. Modify the necessary files in your repository. Once you are satisfied with the changes, stage and commit them, using the suggested commit message from OpenProject.
|
||||
|
||||
|
||||
|
||||
When using a CLI you can also use the **Create branch with empty commit** Git snippet.
|
||||
|
||||
|
||||
The advantage of using this snippet is that there is no need to first create a branch and then copy a separate Git snippet for the commit. A new branch will be created from your current branch along with an empty commit, which when pushed to GitLab will link back to the work package.
|
||||
|
||||
|
||||
|
||||
Continue your work as you normally would, push the branch to GitLab and create a merge request.
|
||||
|
||||
|
||||
|
||||
Changes to the merge request will be tracked under GitLab tab of OpenProject work package, from which git snippets were copied.
|
||||
|
||||
|
||||
|
||||
### Link issues
|
||||
|
||||
OpenProject GitLab integration allows linking GitLab issues directly with OpenProject work packages.
|
||||
@@ -171,4 +197,4 @@ You can either create a new issue in GitLab, or edit an already existing one. En
|
||||
|
||||
Once you save your changes or create a GitLab issue, it will become visible under the **GitLab** tab in OpenProject.
|
||||
|
||||
|
||||
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 703 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 276 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 104 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 460 KiB |
@@ -243,7 +243,7 @@ Read more about [subscribing to a calendar](../../calendar/#subscribe-to-a-calen
|
||||
|
||||
Meetings in OpenProject can have three different statuses: Open, In Progress, and Closed. Depending on the meeting status, different options are available, such as editing the agenda, adding outcomes, or finalizing the meeting. You can transition between these statuses using the meeting status button with a drop-down menu under the meeting name or in the right-hand pane.
|
||||
|
||||
|
||||
|
||||
|
||||
Clicking on this button will show following status options:
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ Here is an example of the date picker in OpenProject. This is what you will see:
|
||||
|
||||
1. The **information banner** on top of date picker will state what scheduling mode is selected and if there are possible date constraints due to existing work package relations. The message will vary depending on the scheduling mode selected and the existing work package relations. This banner is only shown for work packages that have relations
|
||||
2. The **show relations** button on the banner will open a Gantt chart view showing an overview of all directly-related work packages
|
||||
3. The **Relation tabs** let you see a list of relevant relations for the current work pacakges: *predecessors*, *successors* or *children*
|
||||
3. The **Relation tabs** let you see a list of relevant relations for the current work packages: *predecessors*, *successors* or *children*
|
||||
4. The **scheduling mode toggle** allows you to switch between [manual](#manual-scheduling) and [automatic](#automatic-scheduling) modes
|
||||
5. The **Working days only** switch, that lets you switch between counting only working days or all days to the total duration
|
||||
6. **Start date**, **finish date** and **duration** input fields
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
This component defines a colored status button with an action menu to select other statuses. The component is optionally marked readonly, resulting in disabling the action menu.
|
||||
The Status button communicates the current status of something (like a meeting or a work package) using a label and a colour. Optionally, it allows the user to change the status to something else. The button triggers an action menu with alternate statuses. In read-only mode, the status button does not offer any interaction.
|
||||
|
||||
The colours adapt automatically to the currently active mode (light/dark/light high contrast).
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -6,43 +8,70 @@ This component defines a colored status button with an action menu to select oth
|
||||
|
||||
## Anatomy
|
||||
|
||||
The component provides two use-cases:
|
||||
The component provides two variants:
|
||||
|
||||
**1. Using colors only**
|
||||
**1. With colour markers**
|
||||
|
||||
If you are providing `StatusOption` with only the `color` property set, it will use that to color the button of the component. For any selectable status items, the color will be shown as a small square using the `icon_for_color` helper used in various places of the administration.
|
||||
For any selectable status item, a small colour marker will be displayed. The colour of this marker is determined by our internal colour helpers.
|
||||
|
||||
**2. Using icons and colors**
|
||||
<%= embed OpPrimer::StatusButtonComponentPreview, :playground %>
|
||||
|
||||
If you provide `StatusOption` with `icon` and `color` properties set, the color will be used for the button only, and the icon will be used to provide a leading visual icon. In the action menu dropdown, the icons will also be used as a leading icon. Colors will not be shown in the dropdown.
|
||||
**2. With icons and colours**
|
||||
|
||||
The button will be coloured, along with a leading icon in the foreground colour (the same as the text). The action dropdown menu will also show icons; the dropdown will not, however, show colours.
|
||||
|
||||
<%= embed OpPrimer::StatusButtonComponentPreview, :with_icon %>
|
||||
|
||||
## Best practices
|
||||
|
||||
**Do**
|
||||
|
||||
- Provide colors using the `Color` model.
|
||||
- Use the component when each status needs a colour. (Eg. meeting or work package status)
|
||||
- Specify the colour for each status; these colours are not automatically set via Primer and must be manually entered. However, using named Primer colour variables is encouraged (although a hex code will also work, thanks to the internal colour helpers who will translate it to other colour modes).
|
||||
|
||||
**Don't**
|
||||
|
||||
- Don't use the component if the status is not colored. You can simply use an ActionMenu for this case.
|
||||
- Don't use the component if the status is not coloured. You can simply use an ActionMenu for this case.
|
||||
|
||||
## Used in
|
||||
|
||||
The component is used in meetings to signal the status of the meeting, as well as providing options to change it. It will be used in the future for the work package status.
|
||||
The component is used in:
|
||||
|
||||
* Meetings to signal the status of the meeting, as well as providing options to change it.
|
||||
* It will be used in the future for the work package status.
|
||||
|
||||
## Examples
|
||||
|
||||
For detailed examples have a look at the other [preview examples](/lookbook/inspect/OpenProject/Primer/status_button/playground) of the component.
|
||||
|
||||
This is an exemplary playground of the `OpPrimer::StatusButtonComponent`.
|
||||
This is an example playground of the `OpPrimer::StatusButtonComponent`.
|
||||
|
||||
<%= embed OpPrimer::StatusButtonComponentPreview, :playground, panels: %i[params source] %>
|
||||
|
||||
## Technical notes
|
||||
|
||||
The StatusButton component is a composition of a Primer Button and Primer ActionMenu. You provide options of statuses using the `OpPrimer::StatusButtonOption`. In there, you can pass a name, icon, color. All other options will be passed to the `ActionMenu` item.
|
||||
The StatusButton component is a composition of a Primer Button and Primer ActionMenu. You provide options of statuses using the `OpPrimer::StatusButtonOption`. In there, you can pass:
|
||||
|
||||
* `name`: (required) the name of the option
|
||||
* `icon`: (optional) the leading icon
|
||||
* `color_ref`: (optional) The reference of the object to be coloured (for persisted items (like WorkPackage status or type), this is the ID, otherwise some other unique identifier)
|
||||
* `color_namespace`: (optional, although it is required when setting `color_ref`) The namespace is usually the name of the coloured objects (e.g "status", "type", "meeting_status".
|
||||
|
||||
The `color_ref` and `color_namespace` are used together to build internally the highlighting classes for the options (e.g `__hl_inline_status_1`)
|
||||
|
||||
**Note** For this to work, your `color_namespace` has to be registered so that the classes are created beforehand. Have a look [here](https://github.com/opf/openproject/blob/dev/app/views/highlighting/styles.css.erb) on how this is done for the already existing namespaces.
|
||||
|
||||
```css
|
||||
<%# For persisted objects %>
|
||||
<%= resources_scope_color_css("status", ::Status) %>
|
||||
<%= resources_scope_color_css("priority", ::IssuePriority) %>
|
||||
<%= resources_scope_color_css("type", ::Type, inline_foreground: true) %>
|
||||
|
||||
<%# For non-persisted objects %>
|
||||
<% Meetings::Statuses::AVAILABLE.each do |meeting_status| %>
|
||||
<%= resource_color_css("meeting_status", meeting_status) %>
|
||||
<% end %>
|
||||
```
|
||||
|
||||
### Code structure
|
||||
|
||||
@@ -53,9 +82,10 @@ The status button can be called directly
|
||||
items = [
|
||||
OpPrimer::StatusButtonOption.new(name: "Closed",
|
||||
icon: :lock,
|
||||
color: Color.new(hexcode: "#00FF00"),
|
||||
color_ref: 1,
|
||||
color_namespace: "status",
|
||||
tag: :a,
|
||||
href: :a)
|
||||
href: "/bar")
|
||||
]
|
||||
component = OpPrimer::StatusButtonComponent.new(current_status: items.first,
|
||||
items: items,
|
||||
@@ -64,3 +94,7 @@ The status button can be called directly
|
||||
end
|
||||
%>
|
||||
```
|
||||
|
||||
Further, you can pass all options you'd want to pass to the `ActionMenu` item, e.g the description:
|
||||
|
||||
<%= embed OpPrimer::StatusButtonComponentPreview, :with_description %>
|
||||
|
||||
@@ -4,7 +4,7 @@ module OpPrimer
|
||||
# @logical_path OpenProject/Primer
|
||||
class StatusButtonComponentPreview < ViewComponent::Preview
|
||||
# See the [component documentation](/lookbook/pages/components/status_button) for more details.
|
||||
# @display min_height 200px
|
||||
# @display min_height 100px
|
||||
# @param readonly [Boolean]
|
||||
# @param disabled [Boolean]
|
||||
# @param size [Symbol] select [small, medium, large]
|
||||
@@ -35,7 +35,7 @@ module OpPrimer
|
||||
end
|
||||
|
||||
# See the [component documentation](/lookbook/pages/components/status_button) for more details.
|
||||
# @display min_height 200px
|
||||
# @display min_height 100px
|
||||
def with_icon(size: :medium)
|
||||
status = OpPrimer::StatusButtonOption.new(name: "Open",
|
||||
color_ref: :open,
|
||||
@@ -59,15 +59,19 @@ module OpPrimer
|
||||
end
|
||||
|
||||
# See the [component documentation](/lookbook/pages/components/status_button) for more details.
|
||||
# @display min_height 200px
|
||||
# @display min_height 150px
|
||||
def with_description(size: :medium)
|
||||
status = OpPrimer::StatusButtonOption.new(name: "Open",
|
||||
color_ref: :open,
|
||||
color_namespace: :meeting_status,
|
||||
icon: :unlock,
|
||||
description: "The status is open")
|
||||
|
||||
items = [
|
||||
status,
|
||||
OpPrimer::StatusButtonOption.new(name: "Closed",
|
||||
color_ref: :closed,
|
||||
color_namespace: :meeting_status,
|
||||
icon: :lock,
|
||||
description: "The status is closed")
|
||||
]
|
||||
|
||||
Reference in New Issue
Block a user