View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020675 | mantisbt | webpage | public | 2016-03-09 07:39 | 2018-07-12 02:33 |
Reporter | TomR | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | new | Resolution | open | ||
Product Version | 1.2.19 | ||||
Summary | 0020675: It would be nice if you could hide revisions in history below a certain user level | ||||
Description | It would be nice if you could hide revisions in history below a certain user level | ||||
Tags | No tags attached. | ||||
Attached Files | HistoryFilterHideRevisions.php (913 bytes)
<?php class HistoryFilterHideRevisionsPlugin extends MantisPlugin { function register() { $this->name = 'HistoryFilterHideRevisions'; $this->description = 'Excludes revision data from Bug History'; $this->version = '1.0'; $this->requires = array( 'MantisCore' => '1.3.0', ); } function hooks() { return array( 'EVENT_HISTORY_FILTER' => 'filter', ); } function filter( $p_event, $p_history_item ) { switch( $p_history_item['type'] ) { case BUGNOTE_UPDATED: $p_history_item['new_value'] = null; break; case DESCRIPTION_UPDATED: case STEP_TO_REPRODUCE_UPDATED: case ADDITIONAL_INFO_UPDATED: $p_history_item['old_value'] = null; break; } return $p_history_item; } } | ||||
I don't think it would be difficult to change the current $g_history_default_visible setting from an ON/OFF flag, to an access-level approach. Or do you mean to hide specific categories of history entries as opposed to the whole "Issue History" section ? |
|
What I mean is that I do not want to see all the lines in the history with revisions ( linked ). The reason is that sometimes we change some silly textual mistakes which we would not share with the Reporter/Updater. I looked into an EVENT for a pluigin but was unable to find that. |
|
Another question: is it possible to set 'revisions' to OFF? |
|
That would probably require a new config option, defining an array mapping history entry types to authorized access level, and updating history API accordingly. Need also to assess whether all API functions need to take this into consideration, or just history_get_event_from_row(). Doing the check for all functions could be complex and have a performance impact. Not sure it's worth the added complexity and effort to add this to the core.
We don't have one ATM, although it would make sense to add an event in the main loop of history_get_event_from_row(), allowing a plugin to determine whether the history event should be displayed or not.
No. |
|
Here's a proposal for implementation of history event https://github.com/dregad/mantisbt/tree/20675-event-filter-history See attached for a proof-of-concept plugin making use of the new event. Let me know what you think. |
|
At fist i understood that the request was about a configuration that:
To me that is a feasible situation. I may not want low level users to see outdated versions of the items. dregad implementation is different, applied to this request, it would mean to not show the history line at all. |
|
Regarding dregad implementation:
I would approach the event to be triggered after "history_localize_item()". ...or there is place for both: For further improvement, this could be a place to introduce and extend the work from timeline api, which started to use objects for history management, and enhance the design? |
|
The event allows that, but if you look at the POC plugin I attached, it also lets you show an altered line item.
Why not ? I think it makes sense to have filtering occur as early as possible. It also ensures we don't do any useless processing (e.g. localize an item which will then never be shown). As far as I can tell, most history-related functions rely on the raw data generated by history_get_event_from_row() with the exception of a few APIs which query the DB directly.
I don't mind having multiple events, but in your given example I'm not sure what the difference would be.
I think it's outside the scope, but that could be an idea |
|
My concern for that is that having the filtering done in the lowest level api for retrieving history data, avoids any chance to get the actual data by using the api.
My point is, even if you can alter the raw data, the actual presentation for the history text is done in "history_localize_item()" (after the filtering is done). I find useful to also be able to modify text that is showed. |
|