Opened 14 years ago
Last modified 15 months ago
#10232 new defect
Validating Ticket accounts for new or removed fields?
| Reported by: | osimons | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | next-stable-1.6.x |
| Component: | ticket system | Version: | 0.11.5 |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
On IRC today there appeared an issue that brought back memories of #4447 and #9663.
A user has permission to reopen a ticket, and when doing so the preview looks like this:
- status changed from closed to reopened
- resolution answered deleted
Just like it should. And trac.ticket.web_ui.TicketModule._validate_ticket() accounts for the fact that workflow may change these two fields. Problem is that the user sees an error:
Warning: No permission to change ticket fields.
The user claims that this happens all the time, and the real question is why changes isn't empty after this in initial validation method:
changed = set(ticket._old) - set(['status', 'resolution'])
I suspect this is due to fields being added or removed in the system in the time since the ticket was previously edited. They are changes that will need to be recorded, but when they don't arise from user input it seems wrong to let it be a user problem.
The problem is real, but my hypothesis is not completely researched yet… But, it feels like it makes sense… :-)
Attachments (0)
Change History (5)
comment:1 by , 14 years ago
| Milestone: | → next-minor-0.12.x |
|---|
comment:2 by , 10 years ago
| Milestone: | next-minor-0.12.x → next-stable-1.0.x |
|---|
comment:3 by , 8 years ago
| Milestone: | next-stable-1.0.x → next-stable-1.2.x |
|---|
Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.
comment:4 by , 5 years ago
| Milestone: | next-stable-1.2.x → next-stable-1.4.x |
|---|
Replying to osimons:
This may well be the cause. The change indeed shouldn't be visible to the user. We have taken pains to avoid the changes to be displayed (hence the
emptystring value used when readingNULLfrom the database), but maybe we have missed the validation part.