Opened 12 years ago
Closed 12 years ago
#10753 closed enhancement (wontfix)
Show a TracError when 'Remove selected accounts' is submitted with no checkboxes selected
Reported by: | Ryan J Ollos | Owned by: | Steffen Hoffmann |
---|---|---|---|
Priority: | normal | Component: | AccountManagerPlugin |
Severity: | normal | Keywords: | web-UI |
Cc: | Trac Release: |
Description (last modified by )
Following the common convention in Trac, show a TracError when Remove selected accounts is submitted with no checkboxes selected. Following the commit of the patch in #10745, this will only be useful when JavaScript is disabled, since the patch implements the behavior that the buttons are disabled until at least one checkbox is selected.
Originally mentioned in #10745.
Attachments (1)
Change History (7)
comment:1 Changed 12 years ago by
Description: | modified (diff) |
---|
Changed 12 years ago by
Attachment: | t10753-r12507-1.patch added |
---|
comment:2 Changed 12 years ago by
The code is patterned after admin.py in the Trac core. I considered having the text read No user(s) selected., but didn't want to make things too odd for translators.
comment:3 follow-up: 4 Changed 12 years ago by
Keywords: | web-UI added |
---|
Replying to rjollos:
Following the common convention in Trac, show a TracError when Remove selected accounts is submitted with no checkboxes selected.
Hm, I think, this assertion is not quite right. At least Trac is inconsistently handling similar situations. Push 'Apply Changes' on the same panel - nothing happens. Same for the plugin admin panel. Doesn't feel similar enough? How about 'Remove selected items' in permission admin panel? While it certainly looks like a similar situation, with no selection on POST it does just nothing.
I always felt, not to jump at the user with an error in such non-fatal situations, was more of a feature. If it's possible to POST without selection, it should be treated rather gracefully, no? Different situation, if you disabled the button, and someone still manages to go around it and still POST without selection.
Although I would agree to add a warning on inappropriate actions. What do you think?
comment:4 Changed 12 years ago by
Replying to hasienda:
Hm, I think, this assertion is not quite right. At least Trac is inconsistently handling similar situations. Push 'Apply Changes' on the same panel - nothing happens. Same for the plugin admin panel. Doesn't feel similar enough? How about 'Remove selected items' in permission admin panel? While it certainly looks like a similar situation, with no selection on POST it does just nothing.
Good points.
I always felt, not to jump at the user with an error in such non-fatal situations, was more of a feature. If it's possible to POST without selection, it should be treated rather gracefully, no? Different situation, if you disabled the button, and someone still manages to go around it and still POST without selection.
Although I would agree to add a warning on inappropriate actions. What do you think?
After reading what you've had to say on the issue, I tend to think #10745 is enough, and maybe there is nothing that needs to be done for this ticket.
comment:5 Changed 12 years ago by
If you continue to feel so tomorrow, I'd welcome you're closing this ticket yourself. And your hint on #10745 is certainly another good reason for doing so.
comment:6 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The positive reinforcement of a successful change provided by #10684 is further reason for closing this. Also, I don't like landing on a TracError
page and having to click the back button.
Now that we've discussed, I'd almost rather favor changes to the Trac core for pages such as Admin > Components so that a TracError
is not raised. There too though, that change would be less important following the addition of some JavaScript (t:#10994).
Patch against r12507 of the trunk.