View Issue Details

IDProjectCategoryView StatusLast Update
0009193mantisbtotherpublic2021-11-22 21:45
Reportertimj Assigned To 
Status newResolutionopen 
Summary0009193: "Selected project" state should be client-side not server-side

The fact that Mantis keeps state server-side for the selected project is really limiting. Lots of people these days use tabs/multiple windows and I often want to be able to have one tab with one project open and another with another project open yet with Mantis as I move around in one window, as soon as I perform an action in the other window, it will jump to the most recently-selected project in the old.

Keeping state server-side like this and the way it causes cross-window interactions is very confusing and user-unfriendly. It is the frequent cause of mis-filed bugs etc. in a multi-project system.

Mantis should really pass the project ID around client-side (i.e. in GET/POST fields) to avoid this problem.

TagsNo tags attached.


related to 0020098 new Changing project specific configuration management applies to current project, not "intended" project 


Blue Ninja

Blue Ninja

2008-05-28 14:23

reporter   ~0017929

I agree. This will also simplify features talked about in the forums such as being able to report to a sub-project directly.



2018-04-12 07:10

reporter   ~0059539

Yes, this would be great. Related to: 0023741, 0005790 and other.

HTML5 introduced the local storage[1] which could be used for this purpose. You can even store JSON objects with a tiny hack[2].




2018-04-12 07:28

developer   ~0059541

@npeifer contributions are welcome.

Send us a Pull Request on our Github repository



2020-03-12 05:19

reporter   ~0063745

Another possible way of solving it would be using some query parameter - project_id? That would store id of currently selected project. Mantis would then set on each request current project by setting $g_project_override variable to project_id query. On project selection, redirect url would have to change project_id to newly selected project. Cookie version could stay for a while to make project selection working as badly as now for urls that wouldn't have project_id specified.

url generating functions like project_page would have to be updated to append project_id and manually written urls would have to be updated too. Non updated urls would still use the cookie version.

contribution welcome?



2021-07-08 16:09

reporter   ~0065681

Just a +1 from me. (Alas I'm not a web/PHP programmer)



2021-10-06 14:45

reporter   ~0065892

@atrol @dregad @vboctor @cproensa my employer is willing to pay someone to fix this issue. Do any of you, or anyone else, do such contract work?



2021-10-28 15:28

reporter   ~0065964

@atrol @dregad @vboctor @cproensa if I find and hire a PHP programer under contract to work on this issue, are some of you willing to discuss how to properly solve this issue, so that his work can be merged into mantis? I'm unlikely to find a PHP programer that already knows the mantis codebase/architecture, so he would need some guidance in order to produce something acceptable.



2021-10-28 18:54

developer   ~0065965

willing to discuss how to properly solve this issue

Of course, but please bear in mind that I work on Mantis my spare time, so I cannot make any commitments on responding to your programmer's request (for the same reason, I wouldn't accept such a contract myself).



2021-11-22 21:44

reporter   ~0066046

Last edited: 2021-11-22 21:45

# Hello, World!

... Parameterization ...

I'm currently working on solving this. Funny enough: I stumbled upon everything that @nenadalm suggested on my own. I did have a difference from the proposal to use a query-string, however. Instead of query-string as the parameterization field, I wanted parts of the URL path to do that.

  • http://mbt.localhost/project/3/my_view_page.php
  • http://mbt.localhost/project/1/bug_report_page.php
  • http://mbt.localhost/project/4/summary_page.php

My initial peek around the system gave me the impression that a query-string parameter for project_id (or something of a similar name) was already be getting used in various places, if I recall correctly.

What are the preferences, among those us here, between the solutions that have been conceptualized so far: subdir style, query-string style, or, even "why not both"?

... $g_project_override ...

One thing I didn't yet trace was the full extent of the impact of touching $g_project_override. Will mutating this special, global variable really do the trick all the time that we want it to? There were a number of workarounds involving $g_project_override upon closer inspection. I thought it would have been best to avoid conflicting with the all the flows that already existed for it, at least to start.

Thoughts on this?