Issue 2550722
Created on 2011-08-21 23:00 by joseph_myers, last changed 2011-08-22 09:14 by joseph_myers.
| Messages | |||
|---|---|---|---|
| msg4386 (view) | Author: [hidden] (joseph_myers) | Date: 2011-08-21 23:00 | |
If you select "no selection" on a multilink field when editing an item, and in fact nothing is selected for that multilink in the database item, and you make no other changes (so submitting a null edit), a templating error occurs on attempting to render the results of the null edit. No redirection occurs for a null edit (unlike for a non-null edit); instead, the page for that item is rendered directly from the form submission - with a context containing the values from that form submission, and in particular a negative value for the multilink, which is not a valid member of that class. An example may make this clearer. I verified the issue with the present tracker as follows: I found an issue, issue2550709, with a multilink with no values selected. I submitted a first, erroneous, edit, that both set "Components" to None (changing the no-values-selected multilink to have a value selected) and cleared the title (having JavaScript disabled so no client-side detection of the missing title could occur). This produced the expected error page with "Required issue property title not supplied", and "Components" correctly showing "None" (i.e., that edit was not lost) (and the original title back) - and because of "None" being selected, the "no selection" option was also present, which it wasn't on the original issue page. I then changed "Components" to "no selection" (selecting "no selection", unselecting "None") and resubmitted - this being the null edit, since the database already had no Components value set. The result was the "An error has occurred" page. |
|||
| msg4388 (view) | Author: [hidden] (ber) | Date: 2011-08-22 08:17 | |
Joseph, thanks for the detailed report. I guess this was for 1.4.19 and svn trunk? Next would probably be a patch to fix this or maybe even a unit test to check that behaviour even earlier. Best, Bernhard |
|||
| msg4391 (view) | Author: [hidden] (joseph_myers) | Date: 2011-08-22 09:14 | |
I observed the issue with 1.4.19 (my own instance, not the standard templates and schema) then verified it with Roundup's own tracker (I don't know what version that is running) to confirm my conclusion that it was an issue with the Roundup core rather than with my own instance and to provide an easy way to reproduce it with a more or less standard Roundup installation. I don't believe there have been any relevant changes checked in since 1.4.19. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2011-08-22 09:14:54 | joseph_myers | set | messages: + msg4391 |
| 2011-08-22 08:17:24 | ber | set | nosy:
+ ber messages: + msg4388 |
| 2011-08-21 23:00:20 | joseph_myers | create | |