ticket,summary,type,release,owner,status,created,modified,_description,_reporter 10898,TicketSubmitPolicy not firing,defect,0.12,Ryan J Ollos,new,2013-03-01T11:16:14+01:00,2013-03-13T10:26:42+01:00,"I wonder if you could help me out. I've installed and configured the ticket submit policy plugin ( confirmed in admin console; trac.ini contains config ; server restarted ) that you wrote, but it never fires. There are no relevant logs in the trac.log file and no errors ? Trac simply seems not to be parsing the config and acting upon it. Snippets from `trac.ini`: {{{ ticketsubmitpolicy.policies.ticketexcludes = enabled ticketsubmitpolicy.policies.ticketrequires = enabled ticketsubmitpolicy.ticketsubmitpolicy.ticketsubmitpolicyplugin = enabled [ticket-submit-policy] epic_tickets.condition = type is EPIC epic_tickets.requires = summary, reporter, owner, description }}} There's really no point in sending you the trac.log as there's nothing relevant in there, however this is the content of the notification email, which clearly shows that the owner and description fields are NULL, where the ticket-submit-policy configuration required them to be present. {{{ epic_tickets.requires = summary, reporter, owner, description }}} Notification email: {{{ #29: TicketSubmitPoplicy is not firing new EPIC --------------------------------------------------------------------- Summary: TicketSubmitPoplicy is not firing Reporter: hooper_p Owner: (None) Description: (None) Type: EPIC Status: new Milestone: Backlog Resolution: (None) Keywords: (None) Cc: (None) Created: 2013-03-01 10:08:00.420726+00:00 Modified: 2013-03-01 10:08:00.420726+00:00 Due Date: 30.03.2013 Parent: (None) Detected By: (None) Assigned To: (None) Component: cdbcore Detected in sprint: (None) Device Category: Mobile Handset Device Name: HTC ONE Device Operating System: Android 4.0.3 Browser Vendor: Google Browser Name: Chrome Browser Version: 10 Test Type: (None) Trunk Allowed: 1 Added to build: (None) Priority: (None) Steps to reproduce the defect: (None) }}} Really hope you are able to shed some light on this - I've been to the forums, created tickets etc, but am going nowhere fast ! Thanks Paul",phooper0001@… 8955,Better check for field types and use labels instead of keys,defect,0.12,obs,new,2011-07-07T15:50:16+02:00,2011-07-07T15:50:16+02:00,"At the moment, keywords are used for displaying the notification (see #6735), and fields are not checked correctly depending on type (checkbox for instance, if it must be filled). I have edited the requires.js to change that, see below the new as attachment. Could you please add it to the plugin? Thanks.",anonymous 7281,Add ability to exclude fields differently when the ticket is being created vs edited,enhancement,0.12,obs,new,2010-06-22T20:43:48+02:00,2010-06-22T20:43:48+02:00,"I would like the ability to exclude ticket fields when a ticket is created, but have the field be available when tickets are being edited. For example, I have a custom field called percent_complete that I would like to be hidden during creation and defaulted to 0. Then when the ticket is edited, I would like the field to be available to be changed so the owner can provide completion information.",jvetter@… 6735,Use field label insted of field id in required error,defect,0.11,obs,new,2010-02-26T23:05:19+01:00,2010-04-09T02:07:34+02:00,"Currently filed id is used in required error message. Use filed label seems better for user like this: {{{ --- ../0.11/ticketsubmitpolicy/htdocs/js/requires.js 2010-02-27 06:15:30.0000 00000 +0900 +++ ticketsubmitpolicy/htdocs/js/requires.js 2010-02-27 06:58:20.000000000 +0 900 @@ -4,22 +4,24 @@ for ( var i=0; i != requiredfields.length; i++ ) { var field=$(""#field-"" + requiredfields[i]).val(); if (!field) { - missing.push(requiredfields[i]); + field_label = $(""#properties label[for='field-""+requiredfields[ i]+""']"").html(); + field_label = field_label.substring(0, field_label.length-1); + missing.push(field_label); } } }}} regards, Takashi Okamoto",okamototk 5923,Policies are not applied,defect,0.11,obs,new,2009-10-05T16:19:41+02:00,2011-03-08T16:39:42+01:00,"Environment: I'm using Debian 5.0, Trac 0.11.1, Mozilla Firefox 3.0.13 (with Javascript enabled, of course). I got your plugin to be correctly installed, and it seemed to be working: the Admin panel has appeared, I'm able to configure it... but no policies are applied. To test if the JS codes were loading correctly, I've changed the onsubmit and requires function to pop alerts like ""Reached the Requires function"" and so on. The alerts are always exhibited, but the policy is not being applied. As I had some field's name containing two or more words (""defect report"" instead of defect, for example), I've tried some simple stuff, as in: policy1.condition = resolution is fixed policy1.requires = version I don't know what else I could do to try to test and/or fix it. Please, advise.",andreavb 5532,Compatibility with Trac 0.12,defect,0.12,obs,new,2009-07-20T19:19:26+02:00,2011-03-08T16:38:35+01:00,"I was trying to make ticketSubmitPolicyPlugin work on Trac 0.12, I have all installed, and the plugin give me no error message. The WebAdmin works and it configures the trac.ini correctly (despite that WebAdmin destroy the trac.ini so this is not an specific ticketSubmitPolicyPlugin issue). I tried on both IE 8 and Firefox 3.0.5. My ini is like this: {{{ [components] ticketsubmitpolicy.* = enabled [ticket-submit-policy] policy2.condition = component is not OUTRO policy2.excludes = modulo_field #Where modulo_field is a custom field }}} Even using default field instead of modulo_field the plugin don't hide the field. Since 0.11.x will not last forever it is reccomended to treat this issue, as many plugins for 0.11.x works on 0.12. If someone can run ticketSubmitPolicyPlugin on 0.12 please leave a message.",Tony 4487,TicketSubmitPolicyPlugin doesn't check status and it should,enhancement,0.11,obs,new,2009-01-20T10:55:18+01:00,2016-12-19T19:03:45+01:00,"The TicketSubmitPolicyPlugin doesn't work on ticket status. This makes it impossible to really enforce ticket workflow in a meaningful way, as you might want fields only to appear, be required, etc based upon the ticket status (new, closed, etc). See also: gdiscussion:trac-users:fk__A3dVsMk.",Jeff Hammel 4464,Field labels are still shown when field is hidden,enhancement,0.11,obs,new,2009-01-15T13:18:36+01:00,2021-02-22T12:39:22+01:00,"I still see the field labels when fields are hidden. I would expect them to be hidden also. I'm using Firefox 3, Trac 0.11.2.1, and several other plug-ins.",J Evan S 3950,types for comparitor fields should be typed appropriately,enhancement,0.11,obs,new,2008-10-20T18:09:50+02:00,2010-04-09T02:07:23+02:00,"currently, all the RHS of the comparitor tests are textfields. for 'is' and 'is not', these should be drop-downs if they are select fields on the ticket fields for 'is in' and 'is not in', these should be checkboxes if they are select fields on the ticket fields",Jeff Hammel 3834,TicketSubmitPolicy does not work with IE,defect,0.11,obs,new,2008-09-30T20:56:34+02:00,2021-04-26T01:03:36+02:00,"As reported in http://groups.google.com/group/trac-users/browse_thread/thread/acf5d0581461dcb9/a57e9ff2c1d37c97 : ''The TicketSubmitPolicyPlugin seems good for what I need, but I had some problems while using it. In particular, in my project I have 4 different components and 4 different custom tickets, each one is specific for a particular component. My goal is to force the user to specify a value for the custom ticket related to the selected component, while the other custom tickets should be disabled. I managed to install the plugin and to define the policies but it worked quite well only with Firefox, even if I have to manually force a refresh of the web page when I change the component. With Internet Explorer 7.0 no submit policy is applied.'' ",Jeff Hammel 3130,post-POST checking and enforcement if JS not available,defect,0.11,obs,new,2008-06-03T23:10:18+02:00,2010-04-09T02:07:38+02:00,"currently, the TicketSubmitPolicyPlugin works entirely with JS to enforce a ticket submission policy. However, this is easily undoable by posting using an agent without JS. The POST request should be intercepted and it should be ensured that the values conform to the expected policy. Errors should be indicated to the user with the possibility of editting + reposting",Jeff Hammel 3128,TicketSubmitPolicy does no field locking/checking,defect,0.11,obs,new,2008-06-03T22:59:11+02:00,2010-04-09T02:07:17+02:00,"it is possible to construct a policy that modifies the onchange condition of a field more than once. In this case, I think the last one applied will win, but the desired behavior is that all functions should be applied to the onchange condition. This could be done by abstracting out onchange functions for each field as is done with onload and onsubmit",Jeff Hammel