gitlab 18.10 upgrade removes "issues"
Hi, Today, we upgraded gitlab.torproject.org to 18.10! Among a couple of interesting new things[1], GitLab introduced a *significant* change in the way "issues" are presented and organized. It was introduced as "the work items list and saved views"[2]. It's an interesting feature! It allows you to see epics alongside issues and create saved searches of your issues, pretty neat. Except. They essentially *removed* the entire "issues" UX. You know how I keep bugging people to "file an issue"? That "new issue" button is gone. Heck, the "issues" button itself is gone. In its place, there is a "work items" button, and *there* you can find your good old issues (and, now, also epics). But, crucially, there's no "Closed" tab anymore, so you can't easily go into closed issues with one click: you need to go through the search form and a couple of clicks to find closed issues. So after consultation (well, really, it was sheer panic) with my colleagues, I found a way to revert this. So you won't yet see this view. If you really want to experiment with it, replace the "issues" string with "work_items" in URLs, that still works. I have filed a comment (like dozens of other GitLab users) objecting to the change, alongside with the instructions for other GitLab administrators to revert this change.[3] It is my hope that the feature can be improved to some maturity (at *least* keep a "closed" tab and a "new issue" button?!) and that eventually we'll be able to switch the feature back on. I can see the point of having a common view for issues and epics, even though it's not a problem I have personally struggled with in GitLab. But at this point, we can't just do that switch. Let me know if there's any other concern here! a. [1] details in https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/ [2] https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/#introduc... [3] https://gitlab.com/gitlab-org/gitlab/-/work_items/590689#note_3175428478 -- Antoine Beaupré torproject.org system administration
Hello, Thanks for the heads up Anarcat – these are interesting changes indeed, and I agree that GitLab could have done a better job of easing them in. I think the main takeaway for most issue-filers (who aren’t involved in issue management or triage) is that the New issues button has changed to New item, regardless of the reversion. Is that correct?
But, crucially, there's no "Closed" tab anymore, so you can't easily go into closed issues with one click: you need to go through the search form and a couple of clicks to find closed issues.
To help migrate users to the new system, it may have been better if GitLab had retained the “Closed” tab as a default view for existing projects. I assume since views are now user-configurable, it could be easily removed or replaced if desired. However the “Closed” tab was never that useful for me, so I personally will not mourn its demise. (Others may disagree, of course). Despite that, the ability to save sets of filters as new tabs is appealing, and I really look forward to using this feature in my work. For instance, I can now create tabs that are based on statuses, labels, releases or assignees, instead of just “Open”, “Closed” or “All issues". Users also appear to be able to control whether new tabs are visible to themselves only, or to all members of the project. For power-suers, this is great! I’m sure Team Leads and PMs could get very creative with this feature. Unfortunately, however, I’m not able to create a new view at present – as I’m receiving the error “Saved views are not enabled for this namespace”. Perhaps I can look forward to this in future, when the wrinkles have been ironed out. —Duncan
On 2026-03-20 15:21:56, Duncan R. wrote:
Hello,
Thanks for the heads up Anarcat – these are interesting changes indeed, and I agree that GitLab could have done a better job of easing them in.
I think the main takeaway for most issue-filers (who aren’t involved in issue management or triage) is that the New issues button has changed to New item, regardless of the reversion. Is that correct?
Yes, that had already happened before the 18.10 release, which I hadn't noticed.
But, crucially, there's no "Closed" tab anymore, so you can't easily go into closed issues with one click: you need to go through the search form and a couple of clicks to find closed issues.
To help migrate users to the new system, it may have been better if GitLab had retained the “Closed” tab as a default view for existing projects. I assume since views are now user-configurable, it could be easily removed or replaced if desired. However the “Closed” tab was never that useful for me, so I personally will not mourn its demise. (Others may disagree, of course).
I strongly disagree here, it's a thing I reach for *all* the time. :)
Despite that, the ability to save sets of filters as new tabs is appealing, and I really look forward to using this feature in my work. For instance, I can now create tabs that are based on statuses, labels, releases or assignees, instead of just “Open”, “Closed” or “All issues". Users also appear to be able to control whether new tabs are visible to themselves only, or to all members of the project.
For power-suers, this is great! I’m sure Team Leads and PMs could get very creative with this feature.
Sure! As I said, I can certainly imagine this being useful at some point, but I don't think it's ready just yet.
Unfortunately, however, I’m not able to create a new view at present – as I’m receiving the error “Saved views are not enabled for this namespace”. Perhaps I can look forward to this in future, when the wrinkles have been ironed out.
Right. My feature flag meddling has perhaps disabled some things in there... A. -- Antoine Beaupré torproject.org system administration
On 3/19/26 17:22, Antoine Beaupré via tor-project wrote:
Hi,
Today, we upgraded gitlab.torproject.org to 18.10! Among a couple of interesting new things[1], GitLab introduced a *significant* change in the way "issues" are presented and organized.
It was introduced as "the work items list and saved views"[2]. It's an interesting feature! It allows you to see epics alongside issues and create saved searches of your issues, pretty neat.
Except.
They essentially *removed* the entire "issues" UX. You know how I keep bugging people to "file an issue"?
That "new issue" button is gone.
Heck, the "issues" button itself is gone.
In its place, there is a "work items" button, and *there* you can find your good old issues (and, now, also epics).
But, crucially, there's no "Closed" tab anymore, so you can't easily go into closed issues with one click: you need to go through the search form and a couple of clicks to find closed issues.
So after consultation (well, really, it was sheer panic) with my colleagues, I found a way to revert this. So you won't yet see this view.
If you really want to experiment with it, replace the "issues" string with "work_items" in URLs, that still works.
I'm trying to experiment with views but I get an error that says "Save views are not enabled for this namespace". Can you figure out how I can do this tests? I would like to see if this will help us include all kind of items into our dashboards. Before we were having problems showing tasks that people were assigned to.
I have filed a comment (like dozens of other GitLab users) objecting to the change, alongside with the instructions for other GitLab administrators to revert this change.[3]
It is my hope that the feature can be improved to some maturity (at *least* keep a "closed" tab and a "new issue" button?!) and that eventually we'll be able to switch the feature back on. I can see the point of having a common view for issues and epics, even though it's not a problem I have personally struggled with in GitLab.
But at this point, we can't just do that switch.
Let me know if there's any other concern here!
a.
[1] details in https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/ [2] https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/#introduc... [3] https://gitlab.com/gitlab-org/gitlab/-/work_items/590689#note_3175428478
However the “Closed” tab was never that useful for me, so I personally will not mourn its demise. (Others may disagree, of course).
I strongly disagree here, it's a thing I reach for *all* the time. :)
Right, I only intended to insinuate that its usefulness likely varies from person to person.
I would like to see if this will help us include all kind of items into our dashboards. Before we were having problems showing tasks that people were assigned to.
+1. Members of the UX Team have [rightfully] complained about the usefulness of GitLab’s issue lists, in the past, so I’m curious how this might improve their usability. I would be happy to be part of the group that evaluates this feature, if we decide to go down that route. —Duncan
On 19/03/2026 20:22, Antoine Beaupré via tor-project wrote:
Today, we upgraded gitlab.torproject.org to 18.10!
Another bug I noticed is that gitlab searches via the url are broken. E.g.: 1. Start searching some issues using the UI. Say search for "initial" in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues 2. Then in another tab enter the url: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues?search=n... 3. This will redirect to: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues?search=i... Similarly: 1. Start searching some issues using the UI. Say search for "initial" in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues 2. Edit the URL "search" query in place and load the new URL. 3. This will also redirect back to the old URL. Similarly: 1. Start searching some issues using the UI. 2. In another tab search for something else in the UI. 3. Return to the first tab and refresh the page. 4. The refreshed page will use the search from the other tab. So it seems gitlab just ignores the "search" part of the URL, and only stores one search term in some cache at any given time :/ Similarly if you edit the existing URL for the same tab. Is this a known issue with the 18.10 update? I had a quick look through the gitlab.com/gitlab-org/gitlab issue tracker but I didn't find anything obvious. -henry
On 3/24/26 09:07, Henry Wilkes via tor-project wrote:
On 19/03/2026 20:22, Antoine Beaupré via tor-project wrote:
Today, we upgraded gitlab.torproject.org to 18.10!
Another bug I noticed is that gitlab searches via the url are broken.
yes! I have the same issue and was thinking that there was something wrong on how I was getting the links.
E.g.:
1. Start searching some issues using the UI. Say search for "initial" in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues 2. Then in another tab enter the url: https://gitlab.torproject.org/tpo/ applications/tor-browser/-/issues?search=new 3. This will redirect to: https://gitlab.torproject.org/tpo/ applications/tor-browser/-/issues?search=initial
Similarly:
1. Start searching some issues using the UI. Say search for "initial" in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues 2. Edit the URL "search" query in place and load the new URL. 3. This will also redirect back to the old URL.
Similarly:
1. Start searching some issues using the UI. 2. In another tab search for something else in the UI. 3. Return to the first tab and refresh the page. 4. The refreshed page will use the search from the other tab.
So it seems gitlab just ignores the "search" part of the URL, and only stores one search term in some cache at any given time :/ Similarly if you edit the existing URL for the same tab.
Is this a known issue with the 18.10 update? I had a quick look through the gitlab.com/gitlab-org/gitlab issue tracker but I didn't find anything obvious.
-henry
_______________________________________________ tor-project mailing list -- tor-project@lists.torproject.org To unsubscribe send an email to tor-project-leave@lists.torproject.org
Hello Henry and Gaba, Thanks for the details about how to reproduce this. To follow up on this I've opened: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42568 so far I've found that a fix was merged on gitlab for avoiding to override URL parameters if they are changed in the address bar directly. however I haven't yet found something that addresses the cross-tab pollination(pollution?) of search terms. I've added some details to gitlab's issue about the UX change to mention the problems we're facing with keeping different search results in different tabs but I don't know yet if someone will address it. On 2026-03-24 08:07, Henry Wilkes via tor-project wrote:
On 19/03/2026 20:22, Antoine Beaupré via tor-project wrote:
Today, we upgraded gitlab.torproject.org to 18.10!
Another bug I noticed is that gitlab searches via the url are broken.
E.g.:
1. Start searching some issues using the UI. Say search for "initial" in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues 2. Then in another tab enter the url: https://gitlab.torproject.org/tpo/ applications/tor-browser/-/issues?search=new 3. This will redirect to: https://gitlab.torproject.org/tpo/ applications/tor-browser/-/issues?search=initial
Similarly:
1. Start searching some issues using the UI. Say search for "initial" in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues 2. Edit the URL "search" query in place and load the new URL. 3. This will also redirect back to the old URL.
Similarly:
1. Start searching some issues using the UI. 2. In another tab search for something else in the UI. 3. Return to the first tab and refresh the page. 4. The refreshed page will use the search from the other tab.
So it seems gitlab just ignores the "search" part of the URL, and only stores one search term in some cache at any given time :/ Similarly if you edit the existing URL for the same tab.
Is this a known issue with the 18.10 update? I had a quick look through the gitlab.com/gitlab-org/gitlab issue tracker but I didn't find anything obvious.
On 2026-03-19 16:22:24, Antoine Beaupré via tor-project wrote:
Hi,
Today, we upgraded gitlab.torproject.org to 18.10! Among a couple of interesting new things[1], GitLab introduced a *significant* change in the way "issues" are presented and organized.
It was introduced as "the work items list and saved views"[2]. It's an interesting feature! It allows you to see epics alongside issues and create saved searches of your issues, pretty neat.
Note that our attempt at reverting this has now been reverted, as the feature flag has been removed. So this is now live. The biggest irritant of this change, which was the "stickiness" in the search form, seems to have been fixed. But the fundamental issue (ha!) has not been fixed: "issues" is mostly gone from the GitLab interface, apart from being an item "Type". We'll just have to get used to it, I guess. Enjoy your new powerful work items! :) A.
[1] details in https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/ [2] https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/#introduc...
-- Antoine Beaupré torproject.org system administration
participants (5)
-
Antoine Beaupré -
Duncan R. -
Gaba -
Gabriel Filion -
Henry Wilkes