Add a per-project default component setting to simplify the UI when submitting issues
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed |
A client is requesting this feature, and I think it'd be a good one to have "upstream" in project_issue in general. On each project node's "issues" edit subtab, it'd be nice to give project owners the ability to optionally specify the default component for new issues, so that end users don't always have to click on that and decide when submitting new issues. Of course, it should be possible to retain the current behavior to force users to choose if a project maintainer wants that.
I see 3 possible ways for the UI to work at node/N/edit/issues:
A) A separate drop-down select after the text area for components. This is more like the rest of the Drupal UI (which puts separate settings in separate form elements). However, it's complicated when users change the list of available components -- ideally we'd have some JS to update the options available in the drop-down whenever the text area changes.
B) Use some magic symbol in the existing Components text area to mark the default. I dunno exactly what, maybe just a '*' at the front of the line. Simplifies the "changing both at once" use-case and removes the need for any JS, but will probably be confusing to project maintainers since it's unlike most of the rest of the Drupal UI.
C) Move to a full table for specifying the components, that looks and works a lot like the table of issue status values at admin/project/project-issue-status -- this is related to #140989-5: need way to rename components safely...
Not sure which UI to explore first. Other than that, this feature is a trivial one, but I'd like to make the admin UI not terrible. ;)
#1
My vote would go for c). In an ideal world, we would have a similar UI like CCK's "Manage fields":
- a table for project components, using tablesort, so you can also sort components
- a form widget and "Add more" button in the last row
- a radio button in the first column; using column header "Default"
#2
Yup, that's pretty much exactly what I had in mind. That's just like the UI for the issue status settings page at admin/project/project-issue-status.
The only thing I'm not sure about is how to let project maintainers specify they don't want a default component and they want users to always select a component for new issues. Once any radio is selected, there's no way to un-select it. I could see either:
1) A separate "Clear default component" button (or something, that's a crappy name).
2) A dummy row at the top of the table where you can't change the name (or table drag), labeled
<none>, that still has a radio (this would be the default, in fact).I lean towards 2, but it's slightly clumsy to have a whole other row in the table just for this. Any other thoughts?
#3
Reviewed the current project issue settings and issue node form once again.
The difference I see is that currently, users always start with "<None>", so they have to select something first, since the field is required.
Naturally, if there was a default component, then it would be the first in the list. Meaning: Also the first row in the tablesort admin UI.
To still allow for the current <None>, project owners would just have to be able to toggle a checkbox that says "Make component required", meaning: Either start with the default (first), or <None>.......... baaaaaaaah! Damn! That's completely different to what we want *gngngn*
But anyway, a checkbox that says "Use first component by default" might do it.
#4
I worked on this for a little while tonight. I've now got 3 possible working implementations, but I'm not sure I'm happy with any of them. ;) I'll post them as separate comments to make them easier to refer to. Each one has the working patch and a screenshot of the admin UI to manipulate the components...
First up, the original UI that I had in mind, where there's a single table, with a column of radios, and a row for the "no default, force them to select" option. We can't have the radios as the first column or things get weird with tabledrag, since we don't want to reorder the "none" option, but that means that row doesn't get the drag arrows so the alignment gets weird.
Pros:
- can order the components anyway you like (e.g. alphabetically) and still choose the most important to be default
- all in 1 table avoids the need to sync things as you edit components with another form element
Cons:
- ugly ;)
#5
Next, a separate drop-down select to choose the default component.
Pros:
- can still order the components anyway you like (e.g. alphabetically) and still choose the most important to be default
- less ugly than #4
Cons:
- sort of broken if you try to rename the default component, etc. we either need some JS to coordinate these two options or to fix #140989-5: need way to rename components safely -- these patches all pave the way for that, at least.
#6
Final option, what sun proposed in #3 -- a separate checkbox for "Use the first component by default".
Pros:
- not really ugly at all
- nothing to coordinate -- the checkbox is still valid even if you rename/delete the first component
Cons:
- You have to use the first component as the default, so you can't order however you like and still choose the best default
#7
I like elements of several of these options, so let me propose yet another and see what people think.
I like the select box in #6, partially because it provides text to explain what "default component" means. From the original issue, it seems that by "default" we mean that the select box will initially have that value, but that the user will be able to change it if desired. I think some people might think that "default" means that the user will not be able to change the component when filing an issue (which could be useful as well). As is we might want to clarify what "default" means in this context in the description of the checkbox.
The thing I don't like about #6 is that if we want to use a default component, that it has to be first in the list.
So my proposal would be to have the checkbox but also keep the radios in the table (as in #4 and #5). If the checkbox is checked, then the column in the table with the radios is revealed (or maybe just enabled). If unchecked, that column is hidden (or disabled) using javascript.
One potential problem with this idea is that I'm not sure how well the interface would degrade if javascript is disabled.
For the description of the checkbox in #6, I also think we want a semicolon so that the text reads "...new issues; otherwise, ....". Or it could be two sentences. But this is just being picky, and that text will probably change anyway if it's included at all.
#8
Looking at all other select lists (in Drupal), the default option is always the first. From an "end-user" perspective, meaning the one who has to fill out this form, it still seems to be the most natural thing to me. The other/following options could still be ordered alphabetically or in whatever way they make sense to the project owner. If that even solves another technical issue to properly ensure the default option, I would say let's go with #6.
#9
@sun: "Looking at all other select lists (in Drupal), the default option is always the first."
Guess you're not looking at any "weight" select lists these days. ;) Default is always 0, which is in the middle between -10 and 10...
Or how about the category drop down on the site-wide contact form? You control both the weight and the "selected" option independently, so you can order however you like, and choose which one (if any) is selected by default.
@aclight: We could still add help text to the other options, #6 just made that most natural. I just don't want this feature to get *too* complicated with much more fancy js stuff. It's the sort of thing people will probably set once, if ever, then forget about. ;) I do agree it'd be nice to get a little more help text in there to make it clear what "Default" is about in each case. Re: degrading, I think it'd be perfectly fine to say that if the checkbox is deselected, then we just ignore the value in the radios.
In fact, I think that might be implementation in any case. If that checkbox is not checked, the submit handler always sets {project_issue_projects}.default_component to the empty string. So, if you reload the page, none of the radios will be selected at first. So, we could wipe out the weird first row in the table from #4 and leave the checkbox. I'm not convinced we even need the js bling to enable/disable those radios based on the status of the checkbox... Someone could always add that later if they were so inclined. ;) Maybe I'll take a stab at this later today, depends on other factors.
#10
4 or 6 look good to me. I don't see any benefit to 5 (it seems the ugliest to me, anyway, and since you've pointed out a problem with renaming, it seems to be all negative). Either one would meet our requirements.
I tend to think that if one item in a dropdown is going to be a default, it ought to be the first one. But, that assumes a relatively short and simple list, and assumes no pre-existing state that would make something else the default...but pre-existing state (like an alternate selection provided in the URL query string) would be something you could deal with separately (and it's not something I would need).
#11
@swelljoe: That's funny, drumm and I decided we liked #5 the best. ;) I think the weird non-row is really strange in #4, and I don't like forcing the default to be the first in the list via #6. The only slight problem with #5 is the edge case of renaming existing components, which all needs to change anyway (there should be a "rename" operation link, not a text field). So, the UI problems with #5 would be short-lived...
#12
Since it isn't visible to my users, I don't actually care. ;-)
Go for 5, if that's your preference.
#13
#5 is my clear favorite -- it made immediate intuitive sense to me.
#14
well, if you think you can solve the default-being-renamed issue in some other way, then I don't see a large difference between #5 and #6. #6 rather tries to solve that issue "in the first place", but again, if it can be solved differently, it's more or less the same as #5.
Though, since you mentioned a "rename operation" - what I like in the UI suggestions here is that the user can still rename existing components easily. But well... pretty much talk about an UI that only a few people actually see. ;)
#15
Renaming is sort of a mess. You really *shouldn't* be able to rename easily. You should go through #140989: need way to rename components safely instead... ;)
So yeah, I committed #5 here. Now we just need to fix #140989... ;)
This isn't going to go out in the current round of d.o deployment (I already imported the latest code into the SVN vendor branch before committing this), but that's ok, since I'd rather wait until #140989 is done before this goes out, anyway...
#16
Automatically closed -- issue fixed for 2 weeks with no activity.
#17
Deployed on drupal.org.