View Issue Details

IDProjectCategoryView StatusLast Update
0025902mantisbtapi restpublic2019-07-04 20:17
Reportervboctor Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version2.21.0 
Target VersionFixed in Version 
Summary0025902: Implement IssueViewCommand to make to separate logic from rendering of issue view page
  • Implement IssueViewCommand with logic that provides all information and flags needed to render the issue.
  • Implement a rest API to make this functionality available to Javascript or clients.
  • Refactor issue view page to use the command.
TagsNo tags attached.




2019-07-04 18:45

developer   ~0062355

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)


2019-07-04 20:17

manager   ~0062356

Here is the link to the PR:


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.

Issue History

Date Modified Username Field Change
2019-07-04 15:55 vboctor New Issue
2019-07-04 15:55 vboctor Status new => assigned
2019-07-04 15:55 vboctor Assigned To => vboctor
2019-07-04 18:45 cproensa Note Added: 0062355
2019-07-04 20:17 vboctor Note Added: 0062356