Mandatory fields in tickets

[johan.regnell@…]

It would be great with ability to set some ticket fields as mandatory. These fields should be verified before allowing submit when creating a new ticket.

[anonymous]

Hi,

is anyone actively working on this?

If so, is there a guess, when this enhancement might be available, without defining a whole new Workflow?

TIA Max

[Noah Kantrowitz (coderanger) <coderanger@…>]

This is indeed possible in 0.10. I will see about coding it up later this week.

[Christian Boos]

Hey that week is over, where's the patch? :-)

See also the antonym ticket #2464

[osimons]

#6248 closed as duplicate. It requests making standard and custom fields mandatory, or at least marking them visually in a special way (related to #899, #925, #1748).

Rescheduling according to #6248 value recently updated by cboos.

[Remy Blank]

Closed #5567 as a duplicate.

[Remy Blank]

#8464 was closed as a duplicate.

[anonymous]

What's happening with this ticket

[velappanv@…]

Hi All,

This would be great future if we implemented this? Did any have any idea to work on this please share with us so we iwe can work on the same and release it as soon as possible.

~vela

[Mark Mc Mahon <mark.mcmahon@…>]

I tried to throw something together for this.

It currently is a very basic patch that works in the following way:

• You define in the trac.ini file which fields are required for which workflow actions e.g.

    accept.required_fields = component,version
  

• When validating the ticket on submission these fields are checked not to be empty.

Problems with this patch:

• No tests
• No documentation
• No handling of required fields when creating a new ticket (my proposal here is to have a list of required fields in the [ticket] configuration section which would always be required (so new and every other state)

I would appreciate feedback as to whether this is the right approach before doing much more work on it. (for example - the code to retrieve the workflow actions in _validate_ticket() seem over complicated - maybe there is an easier way?

[Mark Mc Mahon <mark.mcmahon@…>]

Very first attempt at implementing required ticket fields

[Mark Mc Mahon <mark.mcmahon@…>]

(adding comment so that "Add to Cc" is not flagged as spam.

[Remy Blank]

Required fields dependent on the workflow? Interesting idea! There would indeed need to be an additional list for ticket creation, as that was the original request. Making that list apply to all workflow transitions makes sense to me.

[Mark Mc Mahon <mark.mcmahon@…>]

Add

[Mark Mc Mahon <mark.mcmahon@…>]

This latest patch adds required fields when creating a ticket also.

I had a look at the Genshi template 'ticket.html' and when the required fields are passed in the data to the template it should be easy enough to add '*' or change the format to the required fields.

<span py:if="'description' in required_fields">* </span> 
    Description:</label></th>

Any input appreciated.

[Mark Mc Mahon <mark.m.mcmahon@…>]

In the meantime while this is being discussed there is already hack that implements this: ​http://www.matbooth.co.uk/trac/wiki/TicketValidationStart (author Matt Booth)

[Remy Blank]

The TicketValidationStart plugin looks really nice. The idea of associating required fields with status transitions, while elegant and quite simple to implement, doesn't capture the real need. Indeed, a field is required not for a transition, but for the end status. If the check is only performed on transitions, it would be possible to clear a required field after the transition.

So I would rather go with an implementation specifying required fields based on (at least) the status. Arbitrary boolean expressions are a nice addition, but I wouldn't want to add a new dependency on pyparsing just for parsing boolean expressions. Such a simple parser could probably be implemented relatively easily "by hand", though.

We could even have multiple expressions per field, and associate a message to be displayed to the user if the expression is false. This could all be defined in the [ticket-custom] section in trac.ini, with message translations (see #9648).

[trac@…]

Replying to rblank:

The TicketValidationStart plugin looks really nice. The idea of associating required fields with status transitions, while elegant and quite simple to implement, doesn't capture the real need. Indeed, a field is required not for a transition, but for the end status. If the check is only performed on transitions, it would be possible to clear a required field after the transition.

A state transition occurs only when the user chooses to change the state by using a work flow action. The rules in the TicketValidation are run every time you submit the ticket whether a state transition occurs or not. So, if you want a field to be mandatory when the "state == closed" then that field will be mandatory until the ticket is reopened.

So I would rather go with an implementation specifying required fields based on (at least) the status. Arbitrary boolean expressions are a nice addition, but I wouldn't want to add a new dependency on pyparsing just for parsing boolean expressions. Such a simple parser could probably be implemented relatively easily "by hand", though.

You are probably right, but we wanted to get a plug-in working as soon as possible, and using a library helped us with that.

[Remy Blank]

Oh, my comment about pyparsing wasn't meant to be criticism of your plugin: if it works for you, great! It was meant to define a requirement if something similar should be included in Trac core.

[Remy Blank]

Refocusing.

[anonymous]

Plugin by Matt Booth that was downloaded eons ago.

[anonymous]

Plugin by Matt Booth mentioned on this ticket, which was recently updated by me. I'm not an expert, but seems to work with Jinja on 1.4.2.

[anonymous]

Sorry for the late addition, but I just attached the plugin mentioned in the comments section which was done by Matt Booth. I don't know if it is being maintained, but I just updated it to work with my new installation. I am attaching it here just in case it can be of help to someone. This page came up when I searched for the URL listed as the plugin's home page.

[Ryan J Ollos]

Several plugins on trac-hacks provide the feature: ​https://trac-hacks.org/tags/validation?wiki=on.

[anonymous]

Additionally … for hiding (which ticketvalidation also implements): ​https://trac-hacks.org/tags/hide?wiki=on

for example:

[ticket-validation]
nondefecthidden = ((type == enhancement) or (type == task))
nondefecthidden.enabled = True
nondefecthidden.hidden = root_cause
rootcauserequired = (type == defect) and ((status == reviewing) or (status == closed))
rootcauserequired.enabled = True
rootcauserequired.required = root_cause

[anonymous]

While I no longer use Trac, I would happily merge PRs for this plugin over at github: ​https://github.com/trac-hacks/trac-ticketvalidation