Draft: feat: Display options
-
Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA. As a benefit of being a GitLab Community Contributor, you receive complimentary access to GitLab Duo.
What does this MR do and why?
Provide users with control over the metadata displayed in the work item List view
Screen_Recording_2025-01-17_at_12.10.43_AM
Relates to #393559
Merge request reports
Activity
added devopsplan groupproduct planning sectiondev typefeature labels
added pipelinetier-1 label
Thanks for your contribution to GitLab @vedant-jain03!
Did you know about our community forks? Working from there will make your contribution process easier. Please check it out!
- If you need help, page a coach by clicking here or come say hi on Discord.
- When you're ready, request a review by clicking here.
- We welcome AI-generated contributions and offer complimentary access to GitLab Duo!
- To add labels to your merge request, comment
@gitlab-bot label ~"label1" ~"label2"
.
This message was generated automatically. Improve it or delete it.
added Community contribution workflowin dev labels
assigned to @vedant-jain03
mentioned in issue #393559
added linked-issue label
requested review from @nickbrandt
@vedant-jain03 this is looking great! Thanks for your work on this
Just have a few things below as well as a question:
-
When toggling off the
Health status
, it is currently removing theupdated date
as well. We want to maintain that, and only remove the divider between thehealth status
andupdated date
(when it exists) instead. -
Can we rename the
Blocked
display option toBlocked/blocking
, in order to indicate it applies to both indicators and not just Blocked? -
When clicking directly on the option (not the toggle) within the dropdown, it doesn't toggle the option. We ran into this in a couple other areas, and the solution was discussed here. Would you be able to address this here as well by following that example? Screen capture below of what I mean.
-
For the Epic List, we will want to hide a couple options that do not apply for that work item type (apologies I missed accounting for this in the issue description/proposal). For now, we will not have Epic
Milestones
orWeight
, so we will want to hide those options specifically on the Epic List page. The rest of the options apply to both the Issue List and Epic List, so should be good. -
We also need to make some small tweaks for how this is responsive for small devices, and I'll put together a couple designs to illustrate (sorry I didn't include those initially).
Question: As indicated in the description for the associated issue for this, we plan to modify the List pages display options to be context specific in the near future (meaning these options would be list/view specific – changing options in a list in one project wouldn't effect a different list in the project or elsewhere) see #501712 for more details. My assumption is leveraging local storage for this for now is fine, and we can adapt this once #501712 is implemented. My only concern is that any display option settings that users start to use now may not transfer over when we implement #501712, as from what I understand that is storing the values in the BE instead. Do you know if that would be an issue? If so, we may want to hold off on releasing this until that work is completed. That was my original rationale for marking this work as Blocked by #501712.
Let me know if you have any questions on the above! Again, nice work
-
@vedant-jain03 Here are the mobile designs. Basically the proposal is to keep the design options button on the same line as the sort options on
XS
viewport, and starting onSM
viewport how you have it currently (where search/sort/design options all on same line).Thanks, @nickbrandt, for the review and suggestions. I will reiterate on them.
My only concern is that any display option settings that users start to use now may not transfer over when we implement #501712, as from what I understand that is storing the values in the BE instead. Do you know if that would be an issue?
Yes, your concern is right; we might need to wait for #501712 to enable the capability to store the preferences for each project context, and it would be hard to retrace if we went with localStorage and the user has already made their preference.
I will resume my work on this once we have that capability. Let me know if that would be fine.
Meanwhile, if you have something for me, let me know!
That sounds great, thanks for your understanding @vedant-jain03 !
@vedant-jain03 I'm going to unassign myself just for the time being, but once this is ready to be picked back up just ping me!
removed review request for @nickbrandt
@vedant-jain03, it seems we're waiting on an action from you for approximately two weeks.
- Do you still have capacity to work on this? If not, you might want to close this MR and/or ask someone to take over.
- Do you need help in getting it ready? At any time, you can:
- If you're actually ready for a review, you can post
@gitlab-bot ready
.
This message was generated automatically. You're welcome to improve it.
added automation:author-reminded label