### Summary Currently, if a user updates the `Sort` order of a work item List page in one location (Project, Group, or Your Work), that setting is then updated and persisted across the other contexts (all other Projects, Groups, and Your Work). Since users may care about sorting differently based on which context they are in (ex: a specific Project), it doesn't make sense to tie this setting to all other instances. ### Proposal :warning: This is meant to be addressed only for the new [work items](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/work_items/) List pages, not the legacy experience. Change how we persist `Sort` option settings to be **context-specific**, meaning if the sort is updated in one location (ex: a specific project) it only effects that one project. Any other project (as well as any other Group or "Your work") List page would remain with the sort settings as they were. #### Acceptance criteria - [ ] When a user changes the sort order of a planning List page, preserve that sort setting for the specific context they are viewing (ex: the Issues List within a specific project). Below is an example: - User changes the `Issues` List page for **Group A** to sort by `Created date`. - The `Epics` List page for **Group A** is **not** effected - The `Issues` List page for **Group B** is **not** effected - The `Issues` List page in **Project A** (within Group A) is **not** effected - The `Assigned issues` page (within `Your work`) is **not** effected - [ ] This should apply for the following current planning Lists - Group level `Epics` List - Group level `Issues` List - Project level `Issues` List - `Assigned issues` (in Your work) In https://gitlab.com/gitlab-org/gitlab/-/issues/393559 we are looking at adding display options for meta-data, and we will want to follow a similar pattern for how we handle other settings such as this. #### Proposed technical solution ([thread](https://gitlab.com/gitlab-org/gitlab/-/issues/501712#note_2236745638)) 1. Introduce a new table like: <table> <tr> <th colspan="3" align="center">work_item_user_preferences</th> </tr> <tr> <th align="center">column</th> <th align="center">type</th> <th>notes</th> </tr> <tr> <td>id</td> <td>bigint</td> <td></td> </tr> <tr> <td>user_id</td> <td>bigint</td> <td></td> </tr> <tr> <td>namespace_id</td> <td>bigint</td> <td> `sharding_key` - the namespace id affected by the preference </td> </tr> <tr> <td>work_item_type_id</td> <td>bigint</td> <td>the work item type affected by the preference</td> </tr> <tr> <td>sort</td> <td>text</td> <td> following the constraints already used in the `UserPreference` </td> </tr> </table> * Pros * We could easily keep the preference by namespace * We can have default values on the model * Cons * Yet another table (Is that a problem? ~database ) * Some columns might require _special_ values for _special_ conditions, for example: _how do we specify the preference on the User dashboard screen (`YourWork`)._ 2. Create a new GraphQL type/mutation for the `WorkItemUserPreference`