There are a handful of settings and behaviors that D6 project.module provides for the split between sandbox and full projects. We already have a field for this in D7 thanks to #1546086: Add a field to hold "project type" (sandbox, full, n/a) info and we're using the existence of that field on a given entity bundle to know if that bundle has project nature (no longer true, see #1569524: Add a 'Project settings' tab on node type edit forms), but otherwise, this field doesn't do anything at all. ;) We need to port various things related to sandboxes:
- Separate permissions for creating sandboxes and full projects. #1818104: Port the sandbox-to-full permissions to D7
- Ability to lock down releases on sandboxes. This part is basically blocked on #1546092: Add a field to control if a given project node has releases -- but once that field exists, we're going to want to hide it and force it to false on sandbox projects if that global config setting is set.
- The whole 'Auto generate short name for sandboxes' crap. Not sure if we even need that stuff or not. But even if we use pathauto, I think we need some way to specify different auto-generated aliases for sandboxes vs. full projects. Or something? See #1551344: D7 solution for project shortname aliases for more.
- The promote UI: #1794888: Port the sandbox-to-full-project promotion UI to D7
Required sub-tasks
- #1580246: Port project_projects_select_options() to D7 and make it handle multiple project node types also touches some sandbox vs. full stuff.
- #1818104: Port the sandbox-to-full permissions to D7
- #1794888: Port the sandbox-to-full-project promotion UI to D7
- #1551344: D7 solution for project shortname aliases
- #1800224: Update release's sandbox promotion integration
Optional clean-up tasks
- #1818168: Move all sandbox vs. full functionality into a separate project_promote module
- #1818172: Add requirements check to ensure sandbox vs. full permissions are set for roles that need them
Level Of Effort
7 days of effort is needed to complete this issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | project-select_options-1551346-4.patch | 3.42 KB | rgristroph |
Comments
Comment #1
dave reidPersonal opinion, I would drop the auto-generate short name for sandboxes. Just leave them at node/nid. I don't find having my name in the URL useful at all and it creates problems when the projects are converted to full releases.
Comment #2
mikey_p commentedThe access perms should be pretty easy to alter with hook_node_access() which is already in place for the maintainers system. I'm not 100% if this will need to go through the project_access() or not, but I don't think it will.
Comment #3
rgristroph commentedAs part of doing Port the lame D6 node/add/project-issue UI to D7 on the project_issue module, I needed to bring over the project_projects_ select_options() function, which is a helper function in project.module that is used to generate a pull-down select of projects to attach a project_issue to. (It will also be used by project_release I think.) (Most UI will eventually have the project already filled in on those forms, but this allows the node/add/project-issue URL to work and might be used elsewhere.)
Anyway, I attach the patch to this issue because it has an option to include, exclude, or only show sandboxes. I have tested this and it works. I need this patch to be applied before the patch to Port the lame D6 node/add/project-issue UI to D7 will work. Maybe I can extend this patch and close out this issue ?
Comment #4
rgristroph commentedForgot to attach patch.
Comment #5
dwwThis issue is really a meta issue to track stuff related to sandbox vs. full. Let's handle each piece in a subtask, since this is going to get huge if it's a single patch for everything.
So, I just split this piece off to #1580246: Port project_projects_select_options() to D7 and make it handle multiple project node types -- let's continue over there.
Comment #5.0
dwwLevel of effort change.
Comment #6
dwwUnassigning, since rgristoph isn't heading up this meta issue (now that the scope is more clear).
Comment #6.0
dwwadded a related issues section for #1580246
Comment #6.1
senpai commentedChanging 'related' heading to 'sub-tasks'.
Comment #7
dwwFYI: just updated the summary to link to #1818104: Port the sandbox-to-full permissions to D7 which is blocking #1794888: Port the sandbox-to-full-project promotion UI to D7.
Comment #7.0
dwwadded links to subtask issues
Comment #7.1
dwwadded section for optional cleanup tasks
Comment #8
dwwThe main thing that remains here is the whole question of URL aliases for sandboxes and the related settings. None of that is actually working yet. So, looks like #1551344: D7 solution for project shortname aliases is the last remaining issue for this effort. Just updated the summary accordingly.
Comment #8.0
dwwadded link to #1551344
Comment #8.1
dwwclarified that field_project_type is no longer used to determine the "project nature" of a given node type.
Comment #9
senpai commentedComment #10
drummTaking this.
Comment #11
drummI cleaned up the functionality around numeric machine names for sandbox projects. I believe this issue can be closed out.
Comment #12.0
(not verified) commentedmore issue