Content
View differences
Updated by Niels Lindenthal about 3 years ago
**As** a user
**I want to** have a clear understanding which access tokens are active, create new ones or delete them
**so that** I can control all my access tokens in a single page
## Note
This feature is an MVP about this page and will be gradually improved over the future with more details and capabilities.
## **Acceptance criteria**
* The Access tokens page will now be divided in sections in this order:
1. **API**
2. **iCalendar**
3. **OAuth**
4. **RSS**
* Each of this sections will have a description below.
* For the moment only **iCalendar** and **OAuth** will be able to have more than one token (once ##15339 is completed).
* There could be more than one **OAuth** token for a single application displayed.
* In the empty status **API** and **RSS** an action below to add a token. Below the **iCalendar** and **OAuth** an information text in the empty state case.
* When clicking on the link bellow **API** or **RSS** to generate a token a toast will appear with the API (current implementation).
* All the tokens can be deleted individually. A toast will be displayed once the token is deleted and the section will go back to the empty state.
* The name of the **iCalendar** tokens will contain the extra column to show the project where the calendar is located. The calendar name is the first column and should be a link that redirects to the calendar itself.
* The **iCalendar** tokens are the only ones that contain expiration dates for now.
* The **OAuth** section contains all the OAuth tokens including active storages. The application connected appears inside brackets (same as in the OAuth).
* Only active **OAuth** tokens are displayed in the **OAuth** section. If there is an application configured but the user doesn't have an active token for it, no information about this application is displayed.
* In case the administrator of the instance has deactivated through admin settings either the **API** or the **iCalendar** a fix information toast appears in the section and the add link is removed.
## To be clarified
* [x] Divide the concept into feasible work packages and have a plan of implementation.
* [x] RSS
* [x] Do we need also options like the ones for creating an **API** token for the **RSS**?
* [x] What is RSS is currently doing do we still need it
* [x] Is there any of this tokens that has expire date? Do we need expire dates? If yes, we should be able to edit them.
* [x] Is there any other action needed in the action column for any of the tokens?
* [x] The texts below each token should be reviewed.
* [x] [ ] Do we want to have multiple tokens per calendar in separate lines or revoke all tokens per calendar?
# Out of scope
* Implementing scopes for the API tokens to limit their permissions (part of <mention class="mention" data-id="47735" data-type="work_package" data-text="#47735">#47735</mention>).
* Having more than one API token (part of <mention class="mention" data-id="47735" data-type="work_package" data-text="#47735">#47735</mention>).
## Visuals
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55606/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55607/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55610/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55760/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55761/content">
## Figma
https://www.figma.com/file/qivvu0fvo3EeIn9KlxuxJJ/Access-tokens?node-id=0-1
**I want to** have a clear understanding which access tokens are active, create new ones or delete them
**so that** I can control all my access tokens in a single page
## Note
This feature is an MVP about this page and will be gradually improved over the future with more details and capabilities.
## **Acceptance criteria**
* The Access tokens page will now be divided in sections in this order:
1. **API**
2. **iCalendar**
3. **OAuth**
4. **RSS**
* Each of this sections will have a description below.
* For the moment only **iCalendar** and **OAuth** will be able to have more than one token (once ##15339 is completed).
* There could be more than one **OAuth** token for a single application displayed.
* In the empty status **API** and **RSS** an action below to add a token. Below the **iCalendar** and **OAuth** an information text in the empty state case.
* When clicking on the link bellow **API** or **RSS** to generate a token a toast will appear with the API (current implementation).
* All the tokens can be deleted individually. A toast will be displayed once the token is deleted and the section will go back to the empty state.
* The name of the **iCalendar** tokens will contain the extra column to show the project where the calendar is located. The calendar name is the first column and should be a link that redirects to the calendar itself.
* The **iCalendar** tokens are the only ones that contain expiration dates for now.
* The **OAuth** section contains all the OAuth tokens including active storages. The application connected appears inside brackets (same as in the OAuth).
* Only active **OAuth** tokens are displayed in the **OAuth** section. If there is an application configured but the user doesn't have an active token for it, no information about this application is displayed.
* In case the administrator of the instance has deactivated through admin settings either the **API** or the **iCalendar** a fix information toast appears in the section and the add link is removed.
## To be clarified
* [x] Divide the concept into feasible work packages and have a plan of implementation.
* [x] RSS
* [x] Do we need also options like the ones for creating an **API** token for the **RSS**?
* [x] What is RSS is currently doing do we still need it
* [x] Is there any of this tokens that has expire date? Do we need expire dates? If yes, we should be able to edit them.
* [x] Is there any other action needed in the action column for any of the tokens?
* [x] The texts below each token should be reviewed.
* [x]
# Out of scope
* Implementing scopes for the API tokens to limit their permissions (part of <mention class="mention" data-id="47735" data-type="work_package" data-text="#47735">#47735</mention>).
* Having more than one API token (part of <mention class="mention" data-id="47735" data-type="work_package" data-text="#47735">#47735</mention>).
## Visuals
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55606/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55607/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55610/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55760/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/55761/content">
## Figma
https://www.figma.com/file/qivvu0fvo3EeIn9KlxuxJJ/Access-tokens?node-id=0-1