Currently, we just have a hard-coded column in {project_release_projects} to control if a given project has releases. Instead, we want a field for this that you could attach to any node type you want (along the lines of #1546086: Add a field to hold "project type" (sandbox, full, n/a) info) and then the value of this field on each node controls if that node has releases.

There's going to be some magic and overlap with the setting for sandboxes that prevents releases. See #1551346: [META] Port sandbox vs. full project functionality for that. But otherwise, this should be fairly straight-forward.

Comments

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Title: Add a field to control if a given node type has releases » Add a field to control if a given project node has releases

The title was confusing here. We don't need the presence of this field to determine the release-nature of a node type. That's a job for the project_behavior_[node-type] setting from #1569524: Add a 'Project settings' tab on node type edit forms. In fact, I just committed fixes for that part to my local 1551384-release-deep-port feature branch (which I haven't yet pushed, sorry).

All this issue cares about is a field that project_release can create and then inject into the default 'project' node type to control if each given project node actually wants releases or not.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Assigned: Unassigned » drumm
drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Active » Needs review

Added this with http://drupalcode.org/project/project.git/commit/2d0606d. The new field is named field_project_has_releases. For sanbox projects, I added project_release_node_validate to be sure sandbox projects can not have releases when not allowed.

The project promotion form may need some work after #1551346: [META] Port sandbox vs. full project functionality

Senpai’s picture

Senpai CreditAttribution: Senpai commented
Assigned: drumm » bdragon

Reassigning to @bdragon for a review of the commit in #3. Kick it back to @drumm as 'needs work' if need be, or mark it as fixed.

bdragon’s picture

bdragon CreditAttribution: bdragon commented
Assigned: bdragon » drumm
Status: Needs review » Needs work

@drumm:
Please default to autocomplete on field_release_project -- we are needing that to be the default to avoid out-of-memory issues on large sites like drupal.org, and it's easier for the user to change it back to select than it is for us to change it to autocomplete (due to the field settings form crashing for the same reason.)

See
http://drupalcode.org/project/project_issue.git/commitdiff/81b6e36f7470a...

Other than that, looks fine.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Guess it doesn't really matter, but we're mixing up issues here a lot. This was supposed to be focused on the field on project nodes to control if they want releases or not. Now it's turning into a quasi-fork of #1551384: Port project_release to D7 with the fields on the release node type itself. Oh well...

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented

#5 - I actually made field_release_project hidden in a later commit. On node add, it is populated from the URL. On node edit, locking a release to a specific project seems like a good thing.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Needs work » Fixed

(See #7)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) CreditAttribution: commented
Issue summary: View changes

added link to #1551346