View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025902||mantisbt||api rest||public||2019-07-04 15:55||2020-05-16 16:54|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.23.0||Fixed in Version||2.23.0|
|Summary||0025902: Implement IssueViewPageCommand to separate logic from rendering of issue view page|
|Tags||No tags attached.|
|related to||0026094||closed||dregad||PHP notice in bug view page when viewing issue without category|
|related to||0026123||closed||dregad||Both "monitor" and "end monitoring" buttons are displayed|
|related to||0026125||closed||dregad||"Users monitoring this issue" section not shown if nobody is monitoring the issue|
|related to||0026482||closed||atrol||'View Issue' page fails to populate some fields (ex 'ID') for some projects (but not others)|
|related to||0026600||closed||dregad||Performance loss after update from 2.20.0 to 2.23.0|
|related to||0026470||closed||atrol||Issue values on bug view page are not localized.|
|related to||0026610||closed||atrol||Option history_default_visible does not work|
|related to||0026838||closed||atrol||OS build field not filled in viewing mode|
|related to||0026920||resolved||vboctor||reporter allowed to close|
|related to||0026921||closed||atrol||View Issue page does not show "Product Build" (wrong key names in code)|
|related to||0026962||resolved||vboctor||Remove unused |
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.
MantisBT: master 08abf7f4
2019-07-05 22:22:39Details Diff
|Control showing of action buttons via flags
Remove logic in issue view page to decide showing buttons and depend on flags from issue view command.
|mod - bug_view_inc.php||Diff File|
|mod - core/commands/IssueViewCommand.php||Diff File|