How will this leverage current events for rendering custom content from plugins?

I use, as an example, several of those events:

• Rendering data fields within the issue fields area. These fields are managed entirely from a plugin.
• Providing special actions within the view page. I have a plugin that implements an approval workflow, that renders some buttons in the fields area of the view issues, linking to plugin action pages.
• Render customized information within the activities list. For example, the timetracking plugin (that displays a box with the timetracking info similar to the standard timetracking feature)

Here is the link to the PR:
https://github.com/mantisbt/mantisbt/pull/1524

@cproensa

The EVENT_MENU_ISSUE is triggered via the command and the result is returned. The good thing about this event is that it returns logical menu option representation (i.e. a model rather than a view). It is up to the view to render this based on the UI template.

        "links": {
            "SourceIntegration": {
                "display_changeset_link": []
            }
        }

However, as you mentioned we have other events that output HTML. At this point the command doesn't return these and they are encoded directly into the view page (bug_view_inc.php). Over time, we should see if we can have a logical representation that events return that is decoupled from the way they are rendered. If not, then the events will have the following limitations:

• Will be limited to the UI and rendered by PHP or returned from PHP as an html string that is rendered by Javascript.
• Will break whenever we change the MantisBT UI template or how we leverage the template to render an issue (e.g. how we rendered sections, fields, etc).

The above applies for all types of extensions. They will continue to run in the web UI with the above limitations and will be part of the view page and not the IssueVIewCommand. I think we need a logical way to add extra fields to an issue, extra actions, etc.

For extra activities, it may make sense to question whether they should be part of the issue view or part of the issue itself (similar to custom fields).

This change doesn't limit what we can do, but highlights areas where we can do better with our extensibility model.