Nice feature.

Performance has to be considered.
Don't fetch and transfer data that might never be displayed.
Note data should be fetched when hovering the mouse over the link.

What you suggest is using dynamic http, qjery, ajax...? how is it suppported in mantis, is there any documentation?

my idea was simpler, get the text trimmed at ~250 chars, retrieved with bugnote cache statistics, so no extra db queries.
text is delivered in the link attributes, so its a little more KBs per page, but saves on http requests.

+1 for not affecting performance to fetch information that user may never care about. I'm not sure what makes the latest comment useful vs. description and any other fields that may not be in the list of shown columns.

Also note that mouse move is like to trigger such popups without the user intending to do so, which can be annoying.

Ajax is MantisBT is currently limited, but an example is how we expand filters when user clicks on them.

Overall, I'm inclined to -1 this feature.

Another option is to introduce a new column "latest_note".

I'm not sure what makes the latest comment useful vs. description and any other fields that may not be in the list of shown columns.

I think the motivation is to have some indicator of what made the latest update to the issue, sometimes you see issued updataed recently, but no way to see if its been modified by you, or other user.

Another option is to introduce a new column "latest_note".

Taking into account the use case, a more precise indicator would be a column for last updater.

Anyway, i find interesting trying this feature as a plugin. However: IRRC, there are no plugin EVENTS for field presentation (only a custom function). And how implementable is the ajax thing from a plugin...?

If your use case is knowing what triggered the last update, then the bugnote text is not necessarily the relevant information to display, since date change can be caused e.g. by a user monitoring the issue, or a relationship being added, none of which generate any bugnote.

In this context, showing the most recent history event(s) is probably more appropriate.

The question remains, whether this is something we would want to do in core or not (also taking performance impact into consideration).

Regarding potentially missing plugin events vs custom functions, the strategy is to move towards the former, and eventually deprecate the latter, so if new events are required for a plugin implementation, I believe it would be worth considering.

Regarding potentially missing plugin events vs custom functions, the strategy is to move towards the former, and eventually deprecate the latter, so if new events are required for a plugin implementation, I believe it would be worth considering.

Is there any central place for this discussion, adding events?
This would be a good time to try to program a lot of functionalities by plugins and let the laking of necessary events arise.

Is there any central place for this discussion, adding events?

The right place would be the mantisbt-dev mailing list.

Historically, plugins' needs have frequently been a driver for adding new events. This is an ongoing process.

As for specifically replacing the custom functions, I vaguely recall discussing this fairly recently - I think it was with atrol, but I don't remember where.

but I don't remember where.

Recently with vboctor, maybe 0020037 and 0017844.

We had some more discussion, but I don't remember where ;-)

I agree with Astrol, include last_note could be interesting for indicators and improve a team management.