Changing owner of a ticket removes the sensitive flag?

[andrew.hardy@…]

When we reassign the owner of a 'sensitive' ticket the sensitive flag is being removed.

Not sure if this impacts the plugin, but we have a customized workflow with 'Submit to Internal Testing' and 'Submit to UAT' stages prior to ticket closure.

[Ryan J Ollos]

I cannot reproduce. The plugin does not modify the value of the sensitive custom field.

Are you running the 0.11​ branch?

What other plugins do you have installed?

[Ryan J Ollos]

Replying to Ryan J Ollos:

Are you running the 0.11​ branch?

The 1.2​ branch should also be fine.

[andrew.hardy@…]

Replying to Ryan J Ollos:

Replying to Ryan J Ollos:

Are you running the 0.11​ branch?

The 1.2​ branch should also be fine.

• Trac 1.0.1
• authz-policy
• tracaccount-manager 0.3.2
• tracmastertickets 4.0.0dev
• tracsensitivetickets 1.2.1
• tractags 0.8
• tracusernamedecorate 0.12.0.1
• tracwikicssplugin 0.2

I'll try and produce a test-case.

[Ryan J Ollos]

I'll be interested to hear what you find. The behavior sounds like it's affected by a ticket manipulator or custom workflow operation, however from the plugin list you show I don't see any likely candidates.

[anonymous]

I've not been able to reproduce this issue.

On checking where this appears to have occurred I notice that the tickets were first created before we'd started using the plugin. The tickets don't seem to show when sensitive was set, the first reference show's the sensitive being unset - although I'm certain that the ticket was made sensitive prior to this.

To add to the complication, in the above case the original reporter does not have access to sensitive tickets.

[Ryan J Ollos]

The plugin adds a custom field of type checkbox:

[ticket-custom]
sensitive = checkbox
sensitive.label = Sensitive
sensitive.default = 0

On first update of a ticket after the custom field is added the custom field property will be set.

If you made the default = 1 by editing trac.ini, a ticket would be set sensitive on first update after installing a plugin.

I suspect what you've observed is somehow related to Trac's custom field behavior.

[Andrew Hardy <andrew.hardy@…>]

OK - the 'unset' message makes sense in this context, we have sensitive=0 in our trac.ini.

We'll keep an eye on this.

I wonder what happens with custom fields if they are set to a non-default value on the first time that a ticket is opened that doesn't currently have this field? I assume that the 'default' is only applied once the ticket is upddated and the new field is not set.

Thanks for looking at this.

[Ryan J Ollos]

Replying to Andrew Hardy <andrew.hardy@…>:

I wonder what happens with custom fields if they are set to a non-default value on the first time that a ticket is opened that doesn't currently have this field?

The custom field is set on the first update to a ticket after the field is added. If the user makes an explicit selection that differs from the default, the field will be set to that value, otherwise it is set to the default.