Release version 4.0 of plugin

[Ryan J Ollos]

All of the existing bugs have been fixed for this plugin. Pending feedback on 4.0b1, I'll release version 4.0 of this plugin.

[Ryan J Ollos]

Any ideas about how the allow_override option is supposed to work? This bit of code is confusing me.

# Should we allow a session override?
if self.allow_override:
    do_filter = req.session.get('simpleticket.do_filter', do_filter)

[Adrian Fritz]

Just linking related resources found (more people questioning this lines of code, or related info):

1. ​http://www.mail-archive.com/trac-users@googlegroups.com/msg19079.html
2. ​http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride

Maybe plugin author can enlight us (sorry for the interruption Noah):

• cc coderanger

[Steffen Hoffmann]

Replying to rjollos:

Any ideas about how the allow_override option is supposed to work? This bit of code is confusing me.

# Should we allow a session override?
if self.allow_override:
    do_filter = req.session.get('simpleticket.do_filter', do_filter)

This is checking for a session attribute in the current request object (selected by session ID - corresponding to a Trac user or anonymous). Defaults to the result of checking for the TICKET_CREATE_SIMPLE permission (inherited by TRAC_ADMIN of course), if no attribute is configured for the current sid alias Trac user. Note that I didn't find a place where this is set, so the check should always rule.

[Steffen Hoffmann]

Side-note: In the long run it doesn't make sense to maintain this plugin while DynamicFieldsPlugin is developed too. I think it is capable of doing all that SimpleTicketPlugin does and more, like setting default values, has server-wide setup optionally combined with user configurable options, and even aims at modifying regular ticket view too, not only /newticket.

Not meant to be rude, but we discussed the need for consolidation of the current plugin crowd several times before, so I as all of you kindly to think twice and tell me good reasons for putting (more) time into this plugin, please.

[Ryan J Ollos]

Replying to hasienda:

Not meant to be rude, but we discussed the need for consolidation of the current plugin crowd several times before, so I as all of you kindly to think twice and tell me good reasons for putting (more) time into this plugin, please.

You are certainly not being rude. I haven't looked at DynamicFieldsPlugin, but I trust your judgement that this one should be deprecated and work should proceed with the DynamicFieldsPlugin.

I'll look into wrapping up the open tickets, deprecating this and getting up to speed on DynamicFieldsPlugin.

[Ryan J Ollos]

Replying to hasienda:

This is checking for a session attribute in the current request object (selected by session ID - corresponding to a Trac user or anonymous). Defaults to the result of checking for the TICKET_CREATE_SIMPLE permission (inherited by TRAC_ADMIN of course), if no attribute is configured for the current sid alias Trac user. Note that I didn't find a place where this is set, so the check should always rule.

I can't see any use for the code either. I'm considering just removing it.

[Ryan J Ollos]

(In [11179]) Refs #9572: Removed the session_override option, which didn't seem to provide any function.

[Ryan J Ollos]

(In [11183]) Refs #9572: [11179] was incorrect and broke permissions-based filtering.

[Ryan J Ollos]

Replying to hasienda:

Side-note: In the long run it doesn't make sense to maintain this plugin while DynamicFieldsPlugin is developed too.

It looks like there is also some overlapping functionality with the BlackMagicTicketTweaksPlugin.

[Ryan J Ollos]

(In [11512]) Refs #9572: Reorganized repository into a trunk and tags layout. Version 0.1 is for Trac 0.9. Version 0.1.3 is for Trac 0.10.

[Ryan J Ollos]

(In [11513]) Fixes #9572: Created tag of version 4.0. Bumped trunk to 5.0dev.

[Ryan J Ollos]

Replying to hasienda:

Side-note: In the long run it doesn't make sense to maintain this plugin while DynamicFieldsPlugin is developed too.

My current plan is to try and implement #6648 since I just need to make this plugin work on my Trac installation and don't have time to try and figure out how to get the equivalent features out of the DynamicFieldsPlugin. At that point, and when I have more time available, I'll look at moving over to DynamicFieldsPlugin, and writing a migration guide for users currently on the SimpleTicketPlugin.

[Rob Guttman]

Replying to rjollos:

Replying to hasienda:

Side-note: In the long run it doesn't make sense to maintain this plugin while DynamicFieldsPlugin is developed too.

My current plan is to try and implement #6648 since I just need to make this plugin work on my Trac installation and don't have time to try and figure out how to get the equivalent features out of the DynamicFieldsPlugin. At that point, and when I have more time available, I'll look at moving over to DynamicFieldsPlugin, and writing a migration guide for users currently on the SimpleTicketPlugin.

Can you list out what features you need out of DynamicFieldsPlugin? I would be interested to see what effort it would take to incorporate them (if not already provided).

[Ryan J Ollos]

Replying to robguttman:

Can you list out what features you need out of DynamicFieldsPlugin? I would be interested to see what effort it would take to incorporate them (if not already provided).

Basically, we just need to be able to define a permission (for this plugin the permission is called TICKET_CREATE_SIMPLE) and a list of fields that are hidden from view on the newticket form when the user has the permission. Or flip it around and hide the fields when the user doesn't have a permission.

A nice feature that SimpleTicketPlugin does not currently support would be to allow for more than just a single simple ticket view. A user's group membership or presence of a certain permission would determined what predefined simple ticket view that they see on the newticket form.

I recently learned that Trac 0.12 has the extra permissions provider (​t:TracIni#extra-permissions-section), which would partially support this. Given that feature, a way to accomplish this would be to define a set of permissions (TICKET_VIEW_COMPONENT, TICKET_EDIT_COMPONENT, TICKET_VIEW_PRIORITY, TICKET_EDIT_PRIORITY, TICKET_VIEW_KEYWORDS, TICKET_EDIT_KEYWORDS, ...) and associate each permission with a field so that the field is hidden from view when the user doesn't have that permission.

It didn't look to me like the DynamicFieldsPlugin has the ability to hide fields based on a permission, but the BlackMagicTicketTweaksPlugin can do this (or at least something close to it). The BlackMagicTicketTweaksPlugin isn't currently being maintained, but maybe we could merge some of its features into the DynamicFieldsPlugin over the coming months?

[Ryan J Ollos]

Replying to rjollos:

A nice feature that SimpleTicketPlugin does not currently support would be to allow for more than just a single simple ticket view. A user's group membership or presence of a certain permission would determined what predefined simple ticket view that they see on the newticket form.

In fact, this feature request is captured in #9549.

EDIT: well, I guess that is a more specific request, but I was keying in on the fact that the request is to alter the ticket form based on group membership.

[Ryan J Ollos]

Replying to rjollos:

I recently learned that Trac 0.12 has the extra permissions provider (​t:TracIni#extra-permissions-section), which would partially support this. Given that feature, a way to accomplish this would be to define a set of permissions (TICKET_VIEW_COMPONENT, TICKET_EDIT_COMPONENT, TICKET_VIEW_PRIORITY, TICKET_EDIT_PRIORITY, TICKET_VIEW_KEYWORDS, TICKET_EDIT_KEYWORDS, ...) and associate each permission with a field so that the field is hidden from view when the user doesn't have that permission.

I'm moving forward with implementing this idea in #9995. For the long term, I'd like to discuss implementing these features into the DynamicFieldsPlugin, or if they aren't a good fit there, maybe to the BlackMagicTicketTweaksPlugin (which is currently up for adoption).

[Rob Guttman]

Replying to rjollos:

Replying to robguttman:

Can you list out what features you need out of DynamicFieldsPlugin? I would be interested to see what effort it would take to incorporate them (if not already provided).

Basically, we just need to be able to define a permission (for this plugin the permission is called TICKET_CREATE_SIMPLE) and a list of fields that are hidden from view on the newticket form when the user has the permission. Or flip it around and hide the fields when the user doesn't have a permission.

Got it. You're correct in that the DynamicFieldsPlugin does not consider permissions (or group membership) for deciding which rules to enable or disable (such as hiding or showing certain fields). That does sound like a useful feature. I'll give it some thought and I welcome collaboration on this.

[Rob Guttman]

Replying to robguttman:

Replying to rjollos:

Replying to robguttman:

Can you list out what features you need out of DynamicFieldsPlugin? I would be interested to see what effort it would take to incorporate them (if not already provided).

Basically, we just need to be able to define a permission (for this plugin the permission is called TICKET_CREATE_SIMPLE) and a list of fields that are hidden from view on the newticket form when the user has the permission. Or flip it around and hide the fields when the user doesn't have a permission.

Got it. You're correct in that the DynamicFieldsPlugin does not consider permissions (or group membership) for deciding which rules to enable or disable (such as hiding or showing certain fields). That does sound like a useful feature. I'll give it some thought and I welcome collaboration on this.

Ok, I thought about it and added a solution to DynamicFieldsPlugin - [11518]. I'll update the docs on the wiki soon. Note that the rules only look at the lowercase group name membership.

[Ryan J Ollos]

Replying to robguttman:

Ok, I thought about it and added a solution to DynamicFieldsPlugin - [11518]. I'll update the docs on the wiki soon. Note that the rules only look at the lowercase group name membership.

Thanks! I'm going to be testing it out this coming weekend and I'll report back.