Posted by naught101 on July 5, 2009 at 3:00am
Jump to:
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
The "Edit issue settings" fieldset is expanded by default. Often new users seem to think that the fields in this fieldset are specific to their comment, rather than the issue itself, and wrongly rename the entire issue.
Collapsing this fieldset by default would require new users to actually read the words "Edit issue settings" before they could edit them accidentally. This would reduce confusion, as well as the number of comments required to undo the changes.
Comments
#1
I agree that to collapse the fieldset is a good idea, even though the description for the fieldset clearly states that "changing any of these items will update the issue's overall values"; hopefully, having the fieldset collapsed by default could help the users to see that description, if they open the fieldset.
#2
The other option would be to allow comment titles on issue comments. but maybe that's a limitation of the project module...
#3
We shouldn't collapse that by default since for the people who do the most work in the issue queues, that'd require an extra click to get anything done, and there'd be a (justifiable) outcry.
However, instead of just "won't fix"'ing this issue, perhaps this:
- we'd add a per-user setting to control if the fieldset should be collapsed or expanded
- this setting would default to "closed" for users
- we'll email the devel list and cvs maintainers list about the new setting, and encourage power users to "unlock" themselves.
so, it's a one-time opt-in if you know what you're doing, not an opt-in every time you try to comment on an issue.
thoughts? if someone likes this approach, i won't prevent it from happening (but I'm not going to write the code either -- should be a trivial patch).
#4
Which module should be changed to allow this feature?
#5
Depending on how big/ugly the patch gets (I image it'd be pretty small), I'd be willing to see it as a patch against project_issue.
Otherwise, drupalorg.module.
Thanks,
-Derek
#6
Project issue tracking would be the project that should be patched.
I am changing the referring project to the more appropriate one.