Modify

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#9572 closed task (fixed)

Release version 4.0 of plugin

Reported by: rjollos Owned by: rjollos
Priority: normal Component: SimpleTicketPlugin
Severity: normal Keywords: release
Cc: falkb, hasienda, coderanger, robguttman Trac Release: 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.

Attachments (0)

Change History (19)

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

comment:2 Changed 3 years ago by AdrianFritz

  • Cc coderanger added

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

comment:3 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by hasienda

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.

comment:4 follow-ups: Changed 3 years ago by hasienda

  • Cc robguttman added
  • Keywords release added

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 3 years ago by rjollos

  • Status changed from new to assigned

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.

comment:6 in reply to: ↑ 3 Changed 3 years ago by rjollos

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.

comment:7 Changed 3 years ago by rjollos

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

comment:8 Changed 3 years ago by rjollos

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

comment:9 in reply to: ↑ 4 Changed 3 years ago by rjollos

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.

comment:10 Changed 3 years ago by rjollos

(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 3 years ago by rjollos

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:12 in reply to: ↑ 4 ; follow-up: Changed 3 years ago by 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.

comment:13 in reply to: ↑ 12 ; follow-up: Changed 3 years ago by robguttman

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

comment:14 in reply to: ↑ 13 ; follow-ups: Changed 3 years ago by 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.

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 3 years ago by rjollos

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.

comment:16 in reply to: ↑ 14 Changed 3 years ago by rjollos

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

comment:17 in reply to: ↑ 14 ; follow-up: Changed 3 years ago by 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.

comment:18 in reply to: ↑ 17 ; follow-up: Changed 3 years ago by robguttman

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.

comment:19 in reply to: ↑ 18 Changed 3 years ago by rjollos

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.

Add Comment

Modify Ticket

Action
as closed The owner will remain rjollos.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.