We need a way to know if a given node (type) is a project node type. D7 OG works by providing a field that you can attach to any node type which controls how nodes of that type interact with OG (be a group, be a group post, ignore). I think we can do something very similar here by having a field that records the project type (I know this terminology is overloaded) -- is it a full project, a sandbox, or not a project at all. That way, you can add this field to any node types you want (e.g. on d.o, we'd have different node types for modules, themes, etc) but we could still do things like "show me all the project nodes owned by user foo" without hard-coding node types. And, it gives us an obvious way to handle the whole sandbox vs. full project stuff (which is now just a custom column in the {project_projects} table).

Comments

mikey_p’s picture

I looked briefly into the code to support this the other day, mainly to see if there is a cache of fields per node type that we could use to setup a function that determines whether or not an entity is a project. There is a cache for this so I assume that we can retrieve this and iterate over it without too much additional expense.

One crazy question is, if it's just a field, how do we handle non-node entities? I can't imagine supported anything other than nodes for the foreseeable future.

dww’s picture

Not sure about your crazy question. ;) Yeah, I think we don't want users or comments or other entities to behave like projects and have issue queues and stuff. ;) Maybe there's a good way to restrict this field to only attach to node entities. But, for now, I don't really care. If you do something crazy, I don't care if crazy things blow up for you. At least not for now...

Thanks!
-Derek

hunmonk’s picture

Status: Active » Fixed

pushed this fix to 7.x-2.x. field_project_type is created on install, and added to the default project node type that we also create on install. this allows the field to appear in the UI as an existing field, and all the field settings that we count on internally are disabled on the edit form for the field.

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