View Issue Details

IDProjectCategoryView StatusLast Update
0020675mantisbtwebpagepublic2018-07-12 02:33
ReporterTomR Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version1.2.19 
Summary0020675: 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

TagsNo 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;
    }
}

Relationships

related to 0020690 closeddregad inconsistent UI for view bugnote revision 
has duplicate 0024604 closedatrol Hide "View Revisions" link in the Issue History & Notes sections 

Activities

dregad

dregad

2016-03-09 08:42

developer   ~0052701

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 ?

TomR

TomR

2016-03-11 04:47

reporter   ~0052744

What I mean is that I do not want to see all the lines in the history with revisions ( linked ).
So yes I want to hide specific history entries: all the revisions ( below a certain access level ).

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.

TomR

TomR

2016-03-11 04:48

reporter   ~0052745

Another question: is it possible to set 'revisions' to OFF?
Could not find that either in the configuration.

dregad

dregad

2016-03-11 11:06

developer   ~0052746

I want to hide specific history entries: all the revisions ( below a certain access level ).

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.

I looked into an EVENT for a plugin but was unable to find that.

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.

is it possible to set 'revisions' to OFF?

No.

dregad

dregad

2016-03-11 11:09

developer   ~0052747

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.

cproensa

cproensa

2016-03-11 15:02

developer   ~0052750

At fist i understood that the request was about a configuration that:

  • The history line is shown (eg: bugnote edited), but the user is not allowed to see the revisions.

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.

cproensa

cproensa

2016-03-11 15:13

developer   ~0052751

Last edited: 2016-03-11 15:14

Regarding dregad implementation:

  • your event would filter the raw data array. I'm not sure if that is fine.

I would approach the event to be triggered after "history_localize_item()".
For example in: history_get_events_array().
The event would be for changing how the history line is showed (or not show at all), leaving the core api history retrieval untouched.

...or there is place for both:
EVENT_HISTORY_FILTER and EVENT_HISTORY_DISPLAY

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?

dregad

dregad

2016-03-12 01:35

developer   ~0052755

dregad implementation is different, applied to this request, it would mean to not show the history line at all.

The event allows that, but if you look at the POC plugin I attached, it also lets you show an altered line item.

your event would filter the raw data array. I'm not sure if that is fine.

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.

EVENT_HISTORY_FILTER and EVENT_HISTORY_DISPLAY

I don't mind having multiple events, but in your given example I'm not sure what the difference would be.

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?

I think it's outside the scope, but that could be an idea

cproensa

cproensa

2016-03-12 05:58

developer   ~0052759

Why not ? I think it makes sense to have filtering occur as early as possible

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.
I mean, your approach would let a filter override any history retrieval that is made through the mantis api. Another core function that needs history data wont get the actual raw values, and this function may have its valid reasons to need the actual, unfiltered, data.

I don't mind having multiple events, but in your given example I'm not sure what the difference would be.

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.
So, basically, I was thinking about an event that allows to modify presentation of history lines.
Also, this would match the general approach for events to work tied to the UI layer, not in core. Thinking for events in core should account for a different set of requirements necessarily, as they are part of an api (in PR 720 i am asking about this same issue, UI<->core events)