Content
View differences
Updated by Marc Alcobé about 3 years ago
**As** a user _\[enter role of user\]_
**I want to** have a clear understanding which access tokens are active, create new ones or delete them _\[enter objective\]_
**so that** I can control all my access tokens in a single page _\[enter desired result\]_
## Note
This work package is a work in progress in order to kick start the discussion about improving the Access tokens settings. Probably the scope of this changes will be divided in other work packages in order to make the implementation chunks feasible.
## **Acceptance criteria**
* The Access tokens page will now be divided between:
1. **API**
2. **iCalendar**
3. **RSS** _\[enter acceptance criteria\]_
* Each of this sections will have a description bellow.
* Each section might have more than one token. They also can be empty with only the link or explanation how to add new tokens.
* For **API** and **RSS** an action bellow to add a new token. Bellow the **iCalendar** an information text explains the user how calendar tokens works.
* All the tokens can be deleted individually. A confirmation message will be displayed before the action is performed _(to be designed)._
* The name of the **iCalendar** tokens follow the structure: "Project - Calendar name". This should be a link that redirects to the calendar itself.
* _\[Work in progress\]_ Once a user creates a new **API** token a modal opens and allows the user to give it a name and also specify which permissions this **API** token will contain.
## **TBD**
* Divide the concept into feasible work packages and have a plan of implementation.
* Niels is checking what RSS is currently doing and if we still need it
* Is there any of this tokens that has expire date? Do we need expire dates? If yes, we should be able to edit them.
* Is there any other action needed in the action column for any of the tokens?
* The texts bellow each token should be reviewed.
* Do we need also options like the ones for creating an **API** token for the **RSS**?
## Visuals
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/54018/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/54019/content">
## Figma
https://www.figma.com/file/fIFszjTJWyd0p94SXjih58/Calendar-view?node-id=419-12453&t=tWiFUFNR280wLykv-4 _..._
**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 work package is a work in progress in order to kick start the discussion about improving the Access tokens settings. Probably the scope of this changes will be divided in other work packages in order to make the implementation chunks feasible.
## **Acceptance criteria**
* The Access tokens page will now be divided between:
1. **API**
2. **iCalendar**
3. **RSS**
* Each of this sections will have a description bellow.
* Each section might have more than one token. They also can be empty with only the link or explanation how to add new tokens.
* For **API** and **RSS** an action bellow to add a new token. Bellow the **iCalendar** an information text explains the user how calendar tokens works.
* All the tokens can be deleted individually. A confirmation message will be displayed before the action is performed _(to be designed)._
* The name of the **iCalendar** tokens follow the structure: "Project - Calendar name". This should be a link that redirects to the calendar itself.
* _\[Work in progress\]_ Once a user creates a new **API** token a modal opens and allows the user to give it a name and also specify which permissions this **API** token will contain.
## **TBD**
* Divide the concept into feasible work packages and have a plan of implementation.
* Niels is checking what RSS is currently doing and if we still need it
* Is there any of this tokens that has expire date? Do we need expire dates? If yes, we should be able to edit them.
* Is there any other action needed in the action column for any of the tokens?
* The texts bellow each token should be reviewed.
* Do we need also options like the ones for creating an **API** token for the **RSS**?
## Visuals
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/54018/content"><img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/54019/content">
## Figma
https://www.figma.com/file/fIFszjTJWyd0p94SXjih58/Calendar-view?node-id=419-12453&t=tWiFUFNR280wLykv-4