The bug summary contains a freudian typo, of course: It should be "Adding duplicate relationship should not set "modified" date of parent issue".

Removed the freudian

I tend to disagree with this - from my point of view, adding a relationship is an update of both affected bugs, and as such the last updated date should be bumped.

As a side note, updating only one of the issues has been considered as a bug (0012628, fixed in 1.2.5).

I personally rather see this related to 0007633 - both actions are technically an update, but you probably don't want to see the issue being bumped to the top of the issue list just because someone has edited a note or added a relationship. Especially in the case of issues that have been resolved long ago, it is annoying to see them at the top again just because someone else has reported the same issue again and you want to mark the new issue as a duplicate.

j_schultz: I'm not sure if I understand your point correctly, your statement sounds contradictory: "both actions are technically an update" vs "don't want to see the issue being bumped to the top" - kinda hard to have one without the other, no ?

I can understand the "annoying" bit, but if we accept the fact that adding a relationship (or editing a note) is an update, then how do you propose to handle things ?

j_schultz, sometimes editing a note is worth to bump the issue (user added valuable content, removed a freudian typo) sometimes not (user removed a typo).
Something which is not easy to distingiush by MantisBT.

Sorry, I misread the bug description, so it is not related to the behaviour I suggest at all.

But I'd like to hear your reason why exactly it is necessary to bump a (maybe already closed) issue to the top if someone reports a similar issue and send a mail to all people who subscribed to the issue.

Would it be agreeable that the current behaviour remains for open issues, but not bumping the original issue for closed/resolved issues?

Would it be agreeable that the current behaviour remains for open issues, but not bumping the original issue for closed/resolved issues?

I am quite sure this will introduce even more confusion and another round of discussions with other users.

Maybe 0007840 is what you really want + a plugin which allows you to define your additional rules to the filter.
This is possible but will not have the best performance because you have to look at the history of every issue.

[UPDATE 1]
You would not need the plugin, filtering by "Hide Status" "Resolved and above" is enough and works also for the "View Issues" page in 1.2.11

[UPDATE 2]
Maybe setting $g_hide_status_default = RESOVLED; is able to get what you want for some of your use cases

Honestly I think all of that are just workarounds which do not address the core problem in my opinion. If you don't agree that it would be more logical to just update one issues, that's okay, but I don't really see the neccessity behind it.

OK, back to the core problem:
"Adding duplicate relationship should not set "modified" date of parent issue"

It's a solution for you if MantisBT would not set the date in future versions.
But it's a regression for other users, see 0012268 0008911 0007453.

Do we need another configuration option?
Something like $g_update_modified_date_for_relationships = ON;

I think a configuration option would be a great solution, since I can imagine that there are more people who agree with me but I can also understand if people prefer it to stay as it is.

(In reply to comment 0014417:0032331)

You opened 0012628, what do you think?

I did that specifically for the SOAP API, not for the core api. The SOAP API now follows the core api in this respect.

I can see why you want to have a more restrictive definition of bug change, but I don't have a strong opinion regarding the configuration option . However, it would add quite a bit more complexity to our code so we should be 100% certain we want to add this feature and support it.

Have submitted PR https://github.com/mantisbt/mantisbt/pull/366 that would ensure that last update is changed for both bugs when changing a relationship that would generate a history entry (and therefore we've argued in the past constitute an update to a bug)