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

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].

[1] https://www.w3schools.com/html/html5_webstorage.asp
[2] https://stackoverflow.com/a/3146971/3204042

@npeifer contributions are welcome.

Send us a Pull Request on our Github repository https://github.com/mantisbt/mantisbt

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?

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

@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?

@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.

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).

# 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?

@dregad so my employer has contracted @starlocke to take a look at fixing this issue. If you have a chance to help guide him, it would be much appreciated. Thanks!

i give my +1 on this. Would be an improvement for the UX when using Mantis

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.

@rogueresearch @starlocke
any chance that the enhancement would be an open source?

@sintaq yes, we'll open source the result. But @starlocke's work is on hold pending a reply from @dregad, precisely because we want something that will be integrated into mantis. We ourselves don't want to run our own fork.

Oops sorry I did not realize you guys were waiting for my input... Thanks for the heads up, I'll have a look later tonight or tomorrow.

While the idea of passing the project id as part of URL path seems interesting, I'm a bit concerned about backwards-compatibility with URLs, i.e. making sure everything still works without the /project/xxx/ bit. How are you proposing to achieve this ? Also, remember that the solution must work on various web servers (e.g. no Apache mod_rewrite tricks).

A query string seems more in line with how Mantis currently works, so maybe preferable. Using project_id could indeed be a problem as it is widely used today, but not necessarily in the context of "currently active project" so this approach would need to be analyzed closely. A different parameter name could work

Are you planning to use sessionStorage to persist the data on client side as suggested in 0009193:0059539 ?

Regarding $g_project_override, its purpose is to allow pages to override the current project settings, which typically applies to the view bug pages where the "current" project used by filters, etc does not match the bug being viewed.

This is pretty much what we're attempting to achieve here so IMO it would make sense to try and use that instead of designing something else. I can't promise you it will work 100% of the time or that there would be no conflicts, but it's at least worth a try.

Consider this potentially conflicting use case: https://example.com/project/1/view.php?id=2 where issue 2 belongs in another project

@rogueresearch @starlocke @dregad
Thanks guys. Lets keep this thread alive and rocking. Yeehhaaaaaaa

@dregad - Okay. That's a lot of helpful feedback!

RE: "sessionStorage plans?" -- No, that does not seem like a useful solution to me, since it would "lock in" any considerations to a singular browser/session.

RE: queryString vs URL -- Originally, I wanted to use web-server magic to setup a URL-based solution, but, it's clear that query-string would be preferable for the project's sake in order to minimize dependencies. I'll endeavour to go that route.

RE: conflict use case -- How about opting for a simple rule like "the more-specific identifier(s) will win" to resolve such conflicts? These conflicts can be detected, and, the clients can then be redirected to the canonically-resolved URL. When redirected like that, it would be nice to have a "notice" message at the top of the page if the concept of "flash messages" exists within MantisBT's framework already.

How about opting for a simple rule like "the more-specific identifier(s) will win" to resolve such conflicts?

That would work I guess... It is usually quite obvious which one is the "correct" project id from context, amongst user default, currently active one, or the displayed bug's.

the concept of "flash messages" exists within MantisBT's framework already

Not really sure what you mean by that - like a pop-up message that user can dismiss ?
If so, we don't have such feature as a standard core functionality today.

https://github.com/starlocke/mantisbt-compose - Here's a work in progress. I'd like to assume that the watches of this issue are people who know how to use "Docker" and "Docker-Compose" in order to get a rapidly useable "sandbox" to test things out in. See its README.md for details.

The TL;DR for the above is that you can "taste test" the query-string functionality:

Reporting a bug

• http://localhost:10200/bug_report_page.php?project_id=1
• http://localhost:10200/bug_report_page.php?project_id=2

Viewing issues

• http://localhost:10200/view_all_bug_page.php?project_id=1
• http://localhost:10200/view_all_bug_page.php?project_id=2

My View

• http://localhost:10200/my_view_page.php?project_id=1
• http://localhost:10200/my_view_page.php?project_id=2

Known issue of the implementation, so far:

• Since I wanted to provide "nice" URLs everywhere, I implemented a very broad helper function (helper_mantis_url) that patches up URLs with the project_id querystring parameter as needed. Unfortunately, sometimes, URLs end up with extra / symbols (ex: http://localhost//some_page.php) and I haven't yet pinpointed how/why that's happening.

For the rest of the people who aren't using "Docker"... there's https://github.com/starlocke/mantisbt (project_id_by_query_string branch) that would require whatever manual installation routines you feel like using.

This is EXPERIMENTAL-quality work. It would not be wise to upgrade your production systems with these changes at this time.

Requesting some initial comments/feedback on the rough patch, please.

+1 from me

@starlocke your current changes are based on outdated source code of version 2.9.1.
You should rebase based on latest master branch.

The preferred for review is to send a pull request https://www.mantisbt.org/docs/master/en-US/Developers_Guide/html-desktop/#dev.contrib.submit.github

Thanks @starlocke. I'll have a look, but being quite busy at the moment, I can't really commit on when I'll be able to provide feedback.

In addition to what atrol just said about using an old version of MantisBT, I also noticed that your repo https://github.com/starlocke/mantisbt is actually not a fork of https://github.com/mantisbt/mantisbt, so you won't be able to submit pull requests... I would suggest you fix that (drop the Github repo, fork the official repo, then push your changes again).

I probably won't be able to keep up rebasing 100% of the time with "fast" release schedules. Also, this isn't a pull request. This is more of a very rough proof-of-concept. That's why the request for an initial pass at reviewing it. I intend to sniff out edge cases, build tests, etc -- before it's really ready for "prime time" pull requests to be made -- unless you happen to already see huge value in this and actually want a formal PR right away. Personally speaking, I think it's scary to deploy this without a set of tests for the new, special functionality.

I probably won't be able to keep up rebasing 100% of the time with "fast" release schedules.

I doubt you'd have any merge conflicts rebasing even daily, as you can see here:

https://github.com/mantisbt/mantisbt/commits/master

there are only a few commits a month. mantisbt is not a fast moving project.

But why did you base your work on 2.9.1 and not at least the current release (2.25.2)?

Forking the mantisbt repo and creating a PR would be easiest for me too. I already have a mantis test server running and testing your work would just be a matter of doing a git pull of your changes and restarting apache. Figuring out docker always takes me an afternoon. :)

Ah. I see that 2.9.1 is quite ancient! I suppose it was a rather random "stumbled on that number" selection of starting point. I'll definitely rebase up to a current release and look forward to some good bug fixes and nice new features :)

Hey, community! I rebased to release-2.25.2, and, advanced the prototype quite a fair bit.

• https://github.com/starlocke/mantisbt-compose/tree/670771fa21ae313101ef7e90487d7ec24329e0cf (docker)
• https://github.com/starlocke/mantisbt/tree/97e3cafcb427974dd00a9733b88f6db02d578e5f (core MantisBT; on the topic-branch project_id_by_query_string)

As a temporary(?) measure, the system has a "make project_id affinity visibile" capability. I think it would be worthwhile to make that somewhat permanent, albeit with some toned-down styling instead of the "loud" styling currently employed. -- see screenshot, attached

000237.png (122,813 bytes)   

000237.png (122,813 bytes)   

@starlocke your message came at the start of my vacation, but I'm now back, and caught up on all the usual post-vacation fires. :) I've created a test server and installed from your github fork. I see all the loud pink boxes.

So is the idea that things with dotted boxes have yet to transition to getting the product_id= added? And do we need to hunt around in the UI to find all dotted boxes so you know which need doing? (I can get my QA to do that.)

Also, @dregad, since the change is pretty big, am I right in assuming that it'll never go into 2.25.x? In other words, would it be better for @starlocke to rebase this on master?

@dregad friendly ping. I hesitate to pay @starlocke for further work until we get some feedback... :) For example:

• do you want this rebased on master?
• do you want a github PR?
• what do you think of his approach generally?

Thanks!

@rogueresearch Thanks for the ping and apologies about the silence, I've been busy on other things and must admit that I forgot about this, sorry.

am I right in assuming that it'll never go into 2.25.x?

Correct. hotfix releases such as 2.25.x generally only receive bugfixes.

do you want this rebased on master?

Yes please.

do you want a github PR?

That would be best, as it makes the review process easier.

what do you think of his approach generally?

I had a quick look at it back in March and the approach seems OK overall, but I must admit that I have not fully tested it yet.

@dregad, no worries, I know what it's like to be too busy! :)

So @starlocke if you're still game, could you rebase your work on master and create the typical github fork + PR?

Meanwhile, we have what you've done so far installed on a test server... my QA has some time now, what is it we should test or look for?

@dregad @rogueresearch - Gotcha: aim for a PR against master. For your information, I currently hesitate to open a PR before flushing out all oddities with hyperlinks and MantisBT's behaviours. Still very much a work-in-progress, this.

Re: Testing and bug hunting -- "dotted boxes" are one sign of things needing to be worked on. There will be too many to manually hunt them down at this stage, so I've created a web crawler to do that for me. It's rather risky to be playing with MantisBT's fundamental system like this without an automated safety net in place. I'm not yet certain about how to "share" the test suite -- it's based on schliflo/puppeteer-mocha-chai-docker.

@starlocke I think the desire for the github PR is because that is how they are accustomed to reviewing code, not because anyone wants to merge this as-is or in the short term.

Exactly. And you can mark the PR as draft until you feel it's ready

@dregad - https://github.com/mantisbt/mantisbt/pull/1851 has been created to demonstrate the changes and get more feedback. I went with "merge from main" rather than "rebase atop" mainly due to conflicts that would arise involving URLs in edited lines of code; it was the simpler path.

Exhaustive testing required a crawler (not published anywhere at this time) - it tested 1000's of pages from a very simplistic, fresh-install-with-2-projects starting point.

Thank you. I'm quite busy at the moment, and don't have much time available for testing but I'll have a look as soon as possible.