Content
View differences
Updated by Marc Alcobé 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 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. **Storages** **Nextcloud**
4. **RSS**
* Each of this sections will have a description below.
* 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 below to add a new token. Below 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.
* The **Storages** section contains the OAuth related to the active storages with format "Storage name (Provider)". Bellow the **Storages** an information text explains the user how to add a new storage
* _\[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.
## To be clarified together with the devs
* [ ] Divide the concept into feasible work packages and have a plan of implementation.
* [ ] RSS
* [ ] Do we need also options like the ones for creating an **API** token for the **RSS**?
* [ ] What is RSS is currently doing do 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 below each token should be reviewed.
# Out of scope
* Implementing scopes for the API tokens to limit their permissions.
## Visuals
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/54795/content"><img 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/qivvu0fvo3EeIn9KlxuxJJ/Access-tokens?node-id=0-1 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. **Storages**
4. **RSS**
* Each of this sections will have a description below.
* 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 below to add a new token. Below 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.
* The **Storages** section contains the OAuth related to the active storages with format "Storage name (Provider)". Bellow the **Storages** an information text explains the user how to add a new storage
* _\[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.
## To be clarified together with the devs
* [ ] Divide the concept into feasible work packages and have a plan of implementation.
* [ ] RSS
* [ ] Do we need also options like the ones for creating an **API** token for the **RSS**?
* [ ] What is RSS is currently doing do 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 below each token should be reviewed.
# Out of scope
* Implementing scopes for the API tokens to limit their permissions.
## Visuals
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/54795/content"><img
## Figma
https://www.figma.com/file/qivvu0fvo3EeIn9KlxuxJJ/Access-tokens?node-id=0-1