Opened 11 years ago

Closed 11 years ago

# Release version 4.0 of plugin

Reported by: Owned by: Ryan J Ollos Ryan J Ollos normal SimpleTicketPlugin normal release falkb, Steffen Hoffmann, Noah Kantrowitz, Rob Guttman 0.12

### Description

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.

### comment:1 follow-up:  3 Changed 11 years ago by 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)


### comment:2 Changed 11 years ago by Adrian Fritz

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

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

### comment:3 in reply to:  1 ; follow-up:  6 Changed 11 years ago by Steffen Hoffmann

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.

### comment:4 follow-ups:  5  9  12 Changed 11 years ago by 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.

### comment:5 in reply to:  4 Changed 11 years ago by Ryan J Ollos

Status: new → assigned

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.

### comment:6 in reply to:  3 Changed 11 years ago by Ryan J Ollos

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.

### comment:7 Changed 11 years ago by Ryan J Ollos

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

### comment:8 Changed 11 years ago by Ryan J Ollos

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

### comment:9 in reply to:  4 Changed 11 years ago by Ryan J Ollos

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.

### comment:10 Changed 11 years ago by 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.

### comment:11 Changed 11 years ago by Ryan J Ollos

Resolution: → fixed assigned → closed

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

### comment:12 in reply to:  4 ; follow-up:  13 Changed 11 years ago by Ryan J Ollos

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.

### comment:13 in reply to:  12 ; follow-up:  14 Changed 11 years ago by Rob Guttman

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).

### comment:14 in reply to:  13 ; follow-ups:  15  16  17 Changed 11 years ago by Ryan J Ollos

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?

### comment:15 in reply to:  14 Changed 11 years ago by Ryan J Ollos

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.

### comment:16 in reply to:  14 Changed 11 years ago by Ryan J Ollos

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).

### comment:17 in reply to:  14 ; follow-up:  18 Changed 11 years ago by Rob Guttman

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.

### comment:18 in reply to:  17 ; follow-up:  19 Changed 11 years ago by Rob Guttman

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.

### comment:19 in reply to:  18 Changed 11 years ago by Ryan J Ollos

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.

### Modify Ticket

Change Properties