View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025902||mantisbt||api rest||public||2019-07-04 15:55||2019-07-04 20:17|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0025902: Implement IssueViewCommand to make to separate logic from rendering of issue view page|
|Tags||No tags attached.|
How will this leverage current events for rendering custom content from plugins?
I use, as an example, several of those events:
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.
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 (
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.