Add a 'Project settings' tab on node type edit forms

See #1569988: [Meta] Project issue settings D7 cleanup for more.

Thanks for getting this rolling. Here are my concerns with the proof-of-concept:

A) We don't want a single "settings" array like that. Each setting can just be its own setting. Makes life easier all the way around.

B) Let's not reinvent the wheel. As I stated at #1569988: [Meta] Project issue settings D7 cleanup we want to use the D7 #states system for this (here's an example form using #states). If you're trying to write JS for this issue, You're Doing It Wrong(tm). ;)

C) Labels are "Sentence case" not "Always Capitalized".

D) $curr_project is a very misleading name for that variable. And frankly you shouldn't need it as a separate variable at all if you use #states.

E) The other variable you introduce is misspelled (and misleading) but that should be killed entirely (see point A). ;)

However, to avoid collisions with other issues and patches, maybe it's best to use this issue for *just* the vertical tab where this checkbox can live. The setting for auto-close can use #states to refer to the state of this checkbox over at #1571400: Port auto-closing functionality to D7 (for example).

Also, I'm wondering if it makes sense to have this fieldset/vtab be called something like "Project settings" since we're going to need a similar checkbox for "is this node type a project release?" over at #1551384: Port project_release to D7.

And as I'm writing this, it's occurring to me that it's slightly weird that the project-nature of something is determined by adding this special "Project type" field, while the issue-nature and release-nature is controlled by these settings. Maybe it makes more sense to tie the project-nature of a node type to another setting like this. In that case, the first setting under "Project settings" would actually be a set of radio buttons:

---
How does this content type relate to the Project system?
(*) Not related at all
( ) Used for projects
( ) Used for project issues
( ) Used for project releases
---

(more or less). ;) Then, we use #states based on your selection of the radio to reveal any other settings that matter for a node type once we know how it ties into Project*. Make sense? If we go that route, project.module should provide the fieldset and the first two radios. project_issue and project_release further alter to add their own choices to the main question and any dependent settings.

Thoughts?

Thanks!
-Derek

p.s. Further justification for my proposed UI using radios instead of checkboxes -- I think my head (and our code) would explode if a single node type was both an issue and a project. ;) So, I think it's best if we just force it to only be one or the other, not allowing both.

In the past, we've just ensured that the sub-modules are weighted heavier than project.module itself. I think that's sane. Hard-coding hook_form_alter() invocations like that seems a bit wonky to me.

Thanks!
-Derek

Okay, fair enough. I was never thrilled with weights as the solution to this, but that's what Drupal's always provided and used. Weights are everywhere. They're almost as essential for Drupal as hooks are. But sure, we don't have to use them. I guess we could have a magic little API for this that project invokes, so long as we document it in project.api.php I'm okay with invoking our own custom option alter hook here or something.

fixing link to #1569988

I just updated the summary with the current proposal. Moving this and rescoping to more accurately reflect what we're talking about here.

Note: so this patch doesn't get too huge and unwieldy, let's just use this issue for the UI and form altering API itself. We can actually fix the project-ness plumbing over at #1549538: Add a function to determine if a node or node type is a project after we get the UI working properly here.

Thanks,
-Derek

added the current UI and API proposal to the summary

Also note that node_type_form_submit() already has code to save all of $form_state['values'] as persistent variables with variable_set(). So, we don't need to duplicate that here. We just need to make sure we name the form elements well. ;)

Yeah, maybe even just project_behavior_[node-type] as the setting/variable name, and then the values can be '' (default, ignored), 'project', 'release', 'issue', etc. I think that's pretty self-documenting.

I had another random thought while pondering this issue -- if you're configuring an issue or release node type, does it make sense to be able to select a subset of project node types that can act like the projects for that particular issue/release node type? For example, you could have separate issue node types for each of your project types or something. And then those issues can only move around between projects of the configured types, instead of all possible project nodes across all types on the system. Does that make sense? Is that needless complication? Useful/powerful flexibility so sites can do interesting things?

Re: my random thought in #16: let's just discuss that separately at #1597556: Allow issue node types to restrict which project node types they can use as projects so as not to further complicate this issue. ;)

Cool, I'll take a look ASAP. Can we please update the status to "needs review" when we post patches that need review? ;) Helps both me and the test bot know what's up.

Thanks!
-Derek

Okay, that was a good start, but there were a lot of problems with the patch. Senpai is encouraging me to keep using issues as a learning opportunity, but not to introduce so much latency with lots of back and forth iterations. So, I took your patch, and fixed it up for all my concerns, and just pushed that directly:

https://drupal.org/commitlog/commit/122/e364e20909c0259b60e3c808066b1a93...

I'm attaching a diff here relative to your patch. I hope that makes sense. Here's a summary of what I'm doing differently:

A) The setting names matter. 'is_project' is misleading, since we're deciding how a node type behaves (could be a project, release, issue, etc). As I wrote in #16, project_behavior_[node-type] is a better name since it says how should this node type behave relative to projects. Also 'was_project' was totally unused and bloat, so I removed it.

B) Fixed incorrect PHPDoc comments in various places. See the diff here for details.

C) Renamed various local variables to be self-documenting.

D) Removed bogus form #descriptions. Mostly they just added visual clutter to the UI, and in many cases were actually saying incorrect things.

E) We don't want a sub-fieldset for each Project* module, especially not in cases like project itself where there are no dependent settings.

F) We shouldn't rely on hook implementations to return us an array keyed by module name. Sadly, there's no version of module_invoke_all() that just does that for us (see #890660: add an alternative way of doing module_invoke_all() which sets a 'module' key in the returned info for that) but we can easily iterate over module_implements() and know for sure what module is providing which settings.

G) Renamed the hook to hook_project_node_type_settings().

H) Added project.api.php docs for the new hook.

I) Changed the magic label from just '#name' to '#behavior_label' to hopefully be more self-documenting.

J) Removed the unneeded validate and submit handlers.

K) Added code in project_uninstall() to cleanup the project_behavior_* variables.

Definitely let me know what you think and/or if you have any questions. Hopefully this all makes sense and you can see why I made the changes I did.

Thanks!
-Derek

p.s. Since this issue moved scope, I just opened #1597836: Fix project_issue to use the new Project* node-type settings system for the original point of this issue to kill the dorky "Project issue" checkbox. ;) Assigned to ChinggizKhan for now, but feel free to reassign as appropriate.