[go: up one dir, main page]
Skip to content

BE: Modify the work item List sort settings to be context specific

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

⚠️ This is meant to be addressed only for the new 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 #393559 (closed) 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)

  1. Introduce a new table like:
work_item_user_preferences
column type notes
id bigint
user_id bigint
namespace_id bigint

sharding_key - the namespace id affected by the preference
work_item_type_id bigint the work item type affected by the preference
sort text

following the constraints already used in the UserPreference
  • 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).
  1. Create a new GraphQL type/mutation for the WorkItemUserPreference
Edited by Kassio Borges