Current version 2.25.6

This is obviously not the original MantisBT source code, as there are no "Ready to Accept" links in the original version.
Are you able to reproduce this using a standard MantisBT without changed source code?

@atrol maybe this is just the name of the user assigned to the issue

@diedie2 we're lacking a bit of context here. Can you check, for your issue 8074

• all parent/child relationships it has with other issues
• "destination" issue id of these relationships including their direction (i.e. 8074 is parent of XXX, child of YYY, etc)
• the target_version of these related issues

Also, do you override roadmap_include_issue custom function ? Any other customizations ?

Ready to accept is indeed just a (virtual) user with that name.

=> Issue 8074 is related to issue 7897 and child of 8045.
=> Issue 7897 is related to issue 7873 (and 8074)
=> Issue 8045 is related to issue 8042 (and 8074) and child of 7802

=> Issues 8074 has "planned version" and "fixed in version" = 2023-Q4-GKS
=> Issues 7802 has "planned version" and "fixed in version" = 2023-Q4 3.3.4.1

We have plugins like taskodrome and CodevTT installed.

As far as I know that function or any other was not modified.

function custom_function_default_roadmap_include_issue( $p_issue_id ) {
return true;
}

We have plugins like taskodrome and CodevTT installed.

I don't know the details of either of those plugins so I don't know if they can have an effect on the roadmap page, but I doubt it as there are no hooks there.
Can you confirm this by deactivating the plugins ?

I am unable to reproduce with the given hierarchy 8074 -> 8045 -> 7802 (where -> means child of) and given target versions (8045 has no target, is that right ?).

• Are you sure 8704 has no other parents ?
• Does the User viewing the roadmap have full visibility on all Issues related to 8704 (even indirectly) ?

Maybe this query can help identify the problem (this is the list of candidates for display on Roadmap page)

SELECT sbt.id, source_bug_id, dbt.target_version 
FROM mantis_bug_table sbt 
LEFT JOIN mantis_bug_relationship_table ON sbt.id=destination_bug_id AND relationship_type=2
LEFT JOIN mantis_bug_table dbt ON dbt.id = source_bug_id
WHERE sbt.project_id = <PROJECT_ID> and sbt.target_version = '2023-Q4-GKS';

• assuming 8704 is a typo ;-) yes 8074 has no other parents
• Yes

Now that being said...I am unable to reproduce it at this moment. A colleague did close some issues, but they were not related to this target version, so makes it a bit strange. This also means the query gives 1 record atm.

Although 2023-10-17 was not the first time I saw it. If it comes back I will complete this issue here.

assuming 8704 is a typo

Yep. Fixed.

I am unable to reproduce it at this moment
2023-10-17 was not the first time I saw it. If it comes back I will complete this issue here

OK, I'll resolve this for now, feel free to reopen if the problem occurs again, and you can provide us with a reproducible test case.

The problem re-occurred. Currently on version 2.27.0

@diedie2 just pasting cropped screenshots like this without any explanation makes it difficult to fully understand your context for a proper analysis, so I can't really help you at this stage.

Please confirm whether the following description matches your actual situation. If I get it right, there are 4 issues involved here:

• 8540 and 8547, related to each other
• 8506 and 8518, both being parent of 8540 and 8547

The attached graph illustrates these relationships (the red arrow mean "child of").

If so, I suspect a problem due to the parent/child relationships combined with status and target version as the roadmap page attempts to build a hierarchical view of the issues.

What I'm missing is the target version and status information for each of the 4 issues.

image-5.png (29,625 bytes)   

image-5.png (29,625 bytes)   

• Yes, they are and both have 2025.2 3.5.2.1 as target version.
• Yes, and 8506 had also 2025.2 3.5.2.1 as target version. 8518 does not.

images POV 8506

yesterday, all 4 of them had status "assigned". Since today 8540 and 8547 have status "resolved", the problem is still there.

image-6.png (81,785 bytes)   

image-6.png (81,785 bytes)   

image-7.png (96,467 bytes)   

image-7.png (96,467 bytes)   

This is what I get given your settings (see image-8.png).

Not quite the same, but we do see a duplication of the child issues. This is because they have different parents, but since 8518 is not targeted to the Roadmap's version, it is not included in it causing its children to be displayed at top level. If 8518 had the same target version as 8506, you would see image-9.png.

This could be considered as normal, but I agree it is somewhat confusing. I guess in the case of a parent not being included in the Roadmap, we should check whether the "context-orphaned" children have already been included in another parent's hierarchy, and not display them a second time.

I am not able to reproduce exactly your case (where 8506 is also not included in the Roadmap) though. The only explanation I can think of to achieve that result, is if the user viewing the Roadmap is not allowed to access the parent issue (maybe it has Private view status, it's part of another, private project or the roadmap_include_issue excludes it...)

image-8.png (36,180 bytes)   

image-8.png (36,180 bytes)   

image-9.png (41,421 bytes)   

image-9.png (41,421 bytes)   

Yep, with 8506 set to private, I get image-8.png (see 0033026:0070292) when viewing Roadmap as admin, but with an unprivileged user, all else being equal, I get the same results as you.

image-10.png (32,715 bytes)   

image-10.png (32,715 bytes)   

I don't have private issues so thats a bit weird. Fact is, issues 8518 doesn't have a target version. 8518 + 8540 + 8547 are in the same project. I can simulate the issue with the administrator-account.

I gave 8518 a target version just to test, it gave me this.

image-11.png (88,200 bytes)   

image-11.png (88,200 bytes)