Hide ticket changes from specific groups

[Daniel França]

Hi, 

I wanto to know if it's possible to hide ticket change history for some groups or permissions...

I'd google it and I've find that: http://trac.edgewall.org/ticket/6840

but it seems to work only to hide sensitive ticket, not to hide only the change history for specific groups.

Anyone know some good solution for this case? or maybe a patch.

[Steffen Hoffmann]

Am 06.07.2012 04:12, wrote Daniel França:
> Hi,
> I wanto to know if it's possible to hide ticket change history for some
> groups or permissions...

> I'd google it and I've find that: http://trac.edgewall.__org/ticket/6840

> <http://trac.edgewall.org/ticket/6840>
> but it seems to work only to hide sensitive ticket, not to hide only the
> change history for specific groups.
>
> Anyone know some good solution for this case? or maybe a patch.

Using Trac unaltered TICKET_VIEW permission is required for this, and
core code doesn't differentiate between view of current ticket
properties in the colored box on top of the ticket page and presentation
of historic values - the change history.

However, I think Trac is still good to do what you want with a little
development work, as there's no ready-made plugin right now AFAIK.

Some pointers for minimum requirement:
* implementation of interfaces of Trac's component architecture [1] for
* IPermissionRequestor [2] to add another action/permission like
TICKET_HISTORY_VIEW
* ITemplateStreamFilter [3] to intercept any processing of a request
for 'ticket.html' template and alter the content depending on
permission found in req.perm permission cache for that request
* use XPATH expression to pick the Genshi template portion containing
ticket history from the stream [4]

roughly like so:


from genshi.filters.transform import Transformer
from trac.core import Component, implements
from trac.perm import IPermissionRequestor
from trac.web.api import ITemplateStreamFilter

class TicketChangeViewFilterPlugin(Component):

implements(IPermissionRequestor, ITemplateStreamFilter)

tkt_chg_view = 'TICKET_HISTORY_VIEW'

# IPermissionRequestor method
def get_permission_actions(self):
return [tkt_chg_view]

# ITemplateStreamFilter method
def filter_stream(self, req, method, filename, stream, data):
if filename == 'ticket.html' and not tkt_chg_view in req.perm:
xpath_match = '//div[@id="changelog"]'
filter = Transformer(xpath_match)
stream |= filter.remove()
return stream

Well, I guess that's it; untested, but most needed parts to make it work
for you.

Sincerely,

Steffen Hoffmann


[1] http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture
[2]
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.perm.IPermissionRequestor
[3]
http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints/trac.web.api.ITemplateStreamFilter
[4] http://genshi.edgewall.org/wiki/Documentation/filters.html

[RjOllos]

Hi Steffen,

Do you have any thoughts in the advantages or disadvantages of the ITemplateStreamFilter vs IRequestFilter implementation? They seem pretty equivalent to me. Perhaps the latter would give better performance in some situations.

[RjOllos]

The IRequest filter implementation I'm referring to is what I posted in: https://groups.google.com/forum/m/?fromgroups#!forum/trac-users

The orginal poster cross-posted this question.

[Steffen Hoffmann]

Well, I had to think about this recently, but looking at the API, I
could see their distinct use cases:

ITemplateStreamFilter
* just one method, straight: manipulate template content
* since you return just the Genshi XHTML stream, you can't do much more

IRequestFilter
* advanced, two times interception, allows to
(pre_process stage)
* redirect requests
(post_process stage)
* not just alter but totally exchange page template
* alter corresponding data

IMHO, all implementations should be coded for efficiency, so test simple
and early, if they should be invoked, and return instantly, if not.

Performance-wise I prefer the ITemplateStreamFilter due to simplicity
and one-time-per-request action, if it could do the job. Something like
like DOM element-tree manipulation, that don't require additional data
changes. IRequestFilter is definitely more versatile, powerful, thus
should be a bigger burden to response time. But this is an educated
guess only, can't give profiling results to ultimately proof my point.

Yours,

Steffen Hoffmann