[tor-project] gitlab 18.10 upgrade removes "issues"

Mailing Lists tor-project
1

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 GitLab 18.10 released with agentic SAST FP detection and free-tier credits | GitLab
[2] GitLab 18.10 released with agentic SAST FP detection and free-tier credits | GitLab
[3] Feedback Issue: Planning Views (Work items list + Saved Views) (#590689) · Issues · GitLab.org / GitLab · GitLab

···

--
Antoine Beaupré
torproject.org system administration
_______________________________________________
tor-project mailing list -- tor-project@lists.torproject.org
To unsubscribe send an email to tor-project-leave@lists.torproject.org

2 Likes
2

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

3

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. :slight_smile:

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.

···

On 2026-03-20 15:21:56, Duncan R. wrote:

--
Antoine Beaupré
torproject.org system administration
_______________________________________________
tor-project mailing list -- tor-project@lists.torproject.org
To unsubscribe send an email to tor-project-leave@lists.torproject.org

4

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.

···

On 3/19/26 17:22, Antoine Beaupré via tor-project wrote:

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 GitLab 18.10 released with agentic SAST FP detection and free-tier credits | GitLab
[2] GitLab 18.10 released with agentic SAST FP detection and free-tier credits | GitLab
[3] Feedback Issue: Planning Views (Work items list + Saved Views) (#590689) · Issues · GitLab.org / GitLab · GitLab

5

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. :slight_smile:

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

···

_______________________________________________
tor-project mailing list -- tor-project@lists.torproject.org
To unsubscribe send an email to tor-project-leave@lists.torproject.org

6

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 Issues · The Tor Project / Applications / Tor Browser · GitLab
2. Then in another tab enter the url: Issues · The Tor Project / Applications / Tor Browser · GitLab
3. This will redirect to: Issues · The Tor Project / Applications / Tor Browser · GitLab

Similarly:

1. Start searching some issues using the UI. Say search for "initial" in Issues · The Tor Project / Applications / Tor Browser · GitLab
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 :confused: 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 19/03/2026 20:22, Antoine Beaupré via tor-project wrote:

Today, we upgraded gitlab.torproject.org to 18.10!

7

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.

···

On 3/24/26 09:07, Henry Wilkes via tor-project wrote:

On 19/03/2026 20:22, Antoine Beaupré via tor-project wrote:

E.g.:

1. Start searching some issues using the UI. Say search for "initial" in Issues · The Tor Project / Applications / Tor Browser · GitLab
2. Then in another tab enter the url: The Tor Project · GitLab applications/tor-browser/-/issues?search=new
3. This will redirect to: The Tor Project · GitLab applications/tor-browser/-/issues?search=initial

Similarly:

1. Start searching some issues using the UI. Say search for "initial" in Issues · The Tor Project / Applications / Tor Browser · GitLab
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 :confused: 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