Hi Karl,

Why don't you try setting update_readonly_bug_threshold to 90 (ADMINISTRATOR), or 99 if even Administrators should not update bugs (although they would still be able to reopen them in any case), in the Configuration Report, for the project you want to be read-only ?

Damien

Thanks for answering Damien, you're right in saying that is the best approach at the moment.

You can also change other thresholds (update, report, etc) on a per-project basis to ensure that the project is read only to users.

Thank you both for your answers. You are right, the use case is feasible already today with MantisBT, by changing some configuration options or changing users' rights (as I wrote in my initial comment).

However, not all bugs are closed in the prototype project, so I have to change not only one (0012597:0027573), but a few configuration options to make the project as if write protected, as written in 0012597:0027575.
I would also have to note the old configuration options to restore the project as it was before setting it to write only, if needed.

So what I'm looking for is an option to make a project write protect with one click and make it writable again with one click!
This would speed up this use case a lot, because one could set a project with one click to write protected and with another one writable again. It would not be necessary to first note the old configuration settings, than change pretty lot of them as written in your comments and restore them again, when write access should be possible, again.

That's why I submitted this feature request. It's not urgent, but to my mind it would be a helpful thing (and maybe pretty easy to implement).

I agree that it'd be a useful option to have a one-click read/write checkbox for each project. It's just a bit hard defining what should be considered "writing"? Does adding someone to the CC list for a bug count as writing? (I would have thought so). What about adding a relationship to another bug in another project that is writable?

Well, I think "read-only" really should mean read-only, i.e. it should neither be possible to add someone CC on a read-only bug nor should it be possible to add a relationship to a read-only bug.

Adding CC on a bug, where nothing ever will be changed again (because it's read-only) will not make much sense, so to my mind there is no use case for that.

Adding a relationship from a bug in the read-only prototype project to a writeable bug in the product project makes sense sometimes, e.g. if the code base from prototype is used for the product and this code contains some open bugs.
But in this case, one can copy the bug from prototype into the product project, and I think one can see in the history of this bug, that it has been copied from the prototype project, meaning this bug is from the described use case.

However, I would also be fine with an implementation, where the only change that is possible to do on write-only projects, is changing relationships.
But this approach would not be completely kosher ...