Do not set unsupported sort order from user preference
When displaying collections (e.g., in issues list or group dashboard), some sort options may not be supported depending on the context and we should conditionally restore and set the sort order from saved user preferences.
We currently store the last sort options used for various domain objects (issues, projects, epics, etc.) in user_preferences
table. Take issues
as an example. When a user visits an issues list, we first look up issues_sort
column and use the stored value if one exists:
# app/controllers/concerns/sorting_preference.rb#7
def set_sort_order(field = sorting_field, default_order = default_sort_order)
set_sort_order_from_user_preference(field) ||
set_sort_order_from_cookie(field) ||
params[:sort] ||
default_order
end
However, the same sort option may not be supported across all views that display an issues list. One example is sorting issues by weight. Because Weight is a GitLab Premium feature, we need to check for its availability for a namespace and we've been only supporting the sort option in group and project issues list.
# ee/app/helpers/ee/sorting_helper.rb#45
if viewing_issues && (@project || @group)&.licensed_feature_available?(:issue_weights)
options.concat([weight_option])
end
The issues list that appears in the dashboard can display issues coming from multiple namespaces. We leave out the weight sort here because checking for the feature availability can be expensive and complicated. So we should not use the sort value weight
cached in issues_sort
or cookie (it was the root cause of gitlab-com/gl-infra/production#6546 (closed). Also see the demos in !82558 (merged).)
In addition, we may want to consider falling back to using the first available sort option when rendering a sort dropdown instead of raising an error (!78708 (comment 838591859)).