Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The default list of components for new projects is currently hard coded. Project owners can change the list of components after the fact, but it would be nice if the list of default components was configurable.
The attached patch provides this feature. It adds a whole new configuration screen for a single option, but that seems to fit in best with the few project_issue related config items right now.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 390282-13.configurable_components.patch | 3.25 KB | dww |
| #12 | configurable_components_5.patch | 2.43 KB | marcp |
| #8 | configurable_components_4.patch | 1.83 KB | marcp |
| #4 | configurable_components_3.patch | 2.55 KB | marcp |
| #3 | configurable_components_2.patch | 2.56 KB | marcp |
Comments
Comment #1
dwwCool, thanks! This is a great start to a useful feature. A few items:
A) I see no reason for a whole separate page for this setting, it should just go on the main "Project issue settings" page. The separate page for dealing with the status values is the exception (b/c that's already a complicated, busy UI) not the rule.
B) if we add a site-wide default, I'm worried that people will be confused when they change the defaults and existing projects won't see the change. I wonder if we should change it so that the project only stores its own components if it overrides the site defaults, and otherwise, we use the current site values. Make sense? This would be a bigger change, and might be a can of worms, but we should at least consider it now.
A is a blocker before this could go in. B just needs discussion. If it's relatively easy and you reroll with that, too, all the better. ;)
Thanks!
-Derek
Comment #2
marcp commentedA) Yep, that makes sense. If we decide to pass on B) then I'll re-roll it with the settings on the "Project issue settings" page.
B) A bigger change that opens up a can of worms.
I was initially concerned about the component filter in the views integration, but that looks pretty straightforward, as does most of the rest of the code that will be affected. The biggest usability issue would be the case where there's a set of default components that shrinks such that there are loads of issues out there with a now non-existent component. I suppose we could catch this when saving the new list of default components, but what would we do at this point -- set the available components for the project to the new default list plus any other components that are set in issues for that project?
It seems like the configuration for this is only going to be used by experienced administrators, so I think we can get away with the easier solution here, in particular if we put up a message upon saving the new defaults that alerts the user to the fact that existing projects won't have their component options changed.
Ideally, we'd only have to store the options once for all projects, but since we're allowing projects to customize their own options, we can't really go backwards. Unless, maybe, there's a separate table of component options and we map projects to components... Pretty big departure, though.
Comment #3
marcp commentedHere's another shot at it with the settings on the project issue settings page.
It's straightforward, except for the fact that the default components are saved in the variables table as a string that comes from the textarea on the config page. Since the form goes through system_settings_form(), it's not easy [enough] to save the field out as a serialized array. So, when a new project is created, we convert from the eol delimited string to serialized array.
I think B) above needs some more thought. It always feels like a good idea to reduce duplicate data (ie. the same ol' list of components for 90% of the projects), but in this case, it's probably the least confusing and most efficient way to do things.
Comment #4
marcp commentedRe-rolled for HEAD. In the interest of getting a 6.x version released, if this feature is going to make it in, it should probably happen before any architecture change to the way components are stored.
Comment #5
dwwReviewed, tested, and committed to HEAD. Thanks!
Comment #6
hunmonk commentedthis looks like a sensible start to me, although i think i'd like to see that user warning message you mentioned in #2
Comment #7
dwwOh, yeah, good point. We should set a message when the admin changes the global defaults that components existing projects aren't changed. Should be a fairly easy patch.
Comment #8
marcp commentedHere's the patch with just the message when the global defaults have changed.
Comment #9
dwwCool, thanks. That basically works. A few (minor) problems:
A) You (obviously) get the warning message even when there's a validation error on the form. Currently, the only way to do that is to delete all the default components entirely, which is a little weird. I haven't thought about it much, so there might be an easy solution to this, but maybe not. Either way, it's probably not even worth fixing. ;) Just thought I'd point it out in case you have any quick thoughts on the matter.
B) Even though the components are actually trimmed before being used on projects, the code is still triggered if you just add whitespace to the end of a component (even though that's actually ignored). Incredibly rare and minor edge case. Again, probably not worth fixing.
C) This is a bit clumsy: "Existing projects will retain their component choices, however the project owner may change them on the project's edit/issues page."
- The sentence starts about plural projects, but the 2nd part switches to singular in a slightly awkward way.
- Admins can edit this too.
- "edit/issues page" is potentially confusing (seems like you mean "edit or issues page"). "... on the 'issues' subtab of the 'edit' tab on each project" or something would be more verbose and accurate (and probably just as confusing). ;)
All of this is minor, and probably not even worth troubling with. But, if you (or anyone else) feel inspired to come up with better wording for the message itself, and perhaps address the other points, that'd be swell. Otherwise, this could also just go in as-is and I wouldn't cry.
Thanks!
-Derek
Comment #10
marcp commentedYeah, all good points that I was hoping you wouldn't raise -- I'll get out another patch.
Looks like the project_issue_default_components_original variable's getting saved to the variables table too, which wasn't my intention. FAPI doesn't have a generic way of getting the original variable values out in the validate and/or submit handlers for comparison's sake, does it? Seems like I'm always having to do something special to see if settings have changed.
Comment #11
dwwOh yeah, didn't think of that. ;) Isn't #default_value still in $form at that point?
Comment #12
marcp commentedYep, #default_value is all that's needed -- I wonder how many times I've missed that?!
Here's another shot at it. I got rid of most of the wording on the message since it seems like "more is worse" in this case.
If just the order of components has changed there's no message. I'm not sure that's desired.
One additional feature that could be added is to trim whitespace from each component and push the trimmed strings back up into the form_values...
Comment #13
dwwThanks for re-rolling. I played with this a bit more, made a few changes, and committed the attached patch to HEAD. Changes include:
A) Trimming of whitespace (and blank lines) before saving values (both for the defaults and the per-project components settings).
B) The message now reads:
"The list of default components for new projects has changed. This will not affect existing projects."
I also made it of type 'warning' since it's a warning to the admin not to assume this changed existing projects, and to help it visually stand out from the "The configuration options have been saved." message. The "This will only affect newly created projects." seemed potentially confusing, as if it only affects projects that were newly created. The point of this warning is that it won't affect existing projects, regardless of how new they are. ;) Figured this was the clearest.
C) Removed the sorting -- if you reorder the components, that *does* matter for the projects, since that's how you change the order in the end-user's UI. So, even if all they do is reorder existing components, that will result in a visible change for new projects, and we should say so.