convert project* to CCK

subscribing. i'm all for this change.

I'm like this, it's very much the direction that project* should go. The question is, will we be able to get it done timely? What is the estimated difference in effort between this and the non-CCK Views integration approach?

I haven't used CCK a bunch, so this may be a silly question. But it's my understanding that only part of CCK is in core, and as far as I know the rest of it isn't running on d.o. We already have permission to run Views on d.o, but do we also have permission to run CCK + whatever additional field type modules (if any) we'd need to do the conversion properly?

Seems like a good direction to me. We'd really need to start writing code to know if it really works well. These kind of changes need to be tried in order to understand them. You can get half way through and decide that the hacks you are introducing are worse than the ones you are removing.

As for drupal.org, I think it is plausible that we run a separate site, project.drupal.org, which uses opensearch to integrate search results with drupal.org. we'd ideally unify login as well which is on my long term project list for the Association.

This is a daunting but probably a necessary task. We should look at whether and how we can divide it between a number of developers. I will be happy to take a piece.

Casetracker http://drupal.org/project/casetracker serves as an example that likely we could learn from. This may be an opportunity to merge project.* with casetracker.

A starting place could be mapping our existing fields to CCK equivalents. This will help identify what is covered by existing CCK functionality and what still needs to be developed.

To the extent that we can separate out distinct field types that we need, we'll be able easily to divide up work as a new field type is a discrete task.

Even if we go the custom node type approach (any node type can be a project), we'll need to choose between a pure CCK approach (all fields are CCK or core node) or following the approach of designating a node type as having a set of properties (as is done e.g. by OG) and continuing to store some of our field values in custom tables.

Some potential dev pieces:

1. Automate importing of CCK content types with associated fields. I recently worked on something related, http://drupal.org/node/196468.
2. Two-step nodereference selection. If we use nodereference to link issues to their projects, we need to select the nodereference value before bringing up an issue form as the available fields need to be drawn from the nodereference.
3. Parent fields. Issues need to draw on fields associated with a parent (e.g., component). We need at the least a way to instruct child-node fields (e.g., project issue) to draw available options from parent nodes, possibly based on a nodereference relationship.
4. Field actions. In some cases we attach specific logic to the value of a field selection (e.g., conditionally change state value on cron). Can we generecize a method for attaching actions to values for CCK fields?

dww, so are you proposing that project would provide additional CCK fields? or just default node definitions?

i think that there are a lot of wins from using cck. i just worry that when people start mucking about with the node types, it'll become a support nightmare... "how do i undelete the cvs identifier field?" etc.

Eaton is working on module defined node types complete with fields which can be locked. That work may or may not make it into the next version of CCK.

I pondered this some more and I really don't see how this is a good idea right now given our need to upgrade drupal.org. I'd say we should bite the bullet and make our custom properties like issue status available to Views or even postpone the Views powered upgrade to the same time as CCK upgrade.

Hm. This is too bad. I worry that this might be written off a bit too soon. The "Views integration for free" thing is nothing to take lightly at all, and it seems like it would eliminate a lot of the existing feature requests about wanting to change the what statuses are supported, etc. We could also leverage generic modules that are able to work with general CCK stuff. AFAIK, 'module-defined node types' already works in CCK. We could potentially get the default Views working under 5.x with CCK and then they would magically port... perhaps. ;)

I might see if I can hack away at this over xmas break just for kicks. No promises, though. :P

subscribing. we are looking for this as well.

- Dylan Clear, Advomatic

Sorry, just put a longish comment on http://groups.drupal.org/node/6180 which should really have gone here I think - anyway, cross-posting. (Dont get your hopes up it's not "all done", but I think I have some +ve news for future implementations of some of this stuff).

Well if no-one else will then I'll take a crack at writing a new Project* from CCK alone. Don't worry; I won't be cluttering up Drupal.org with yet-another-implementation-request but if I get anywhere with it I'll let you all know :)

Nothing like the care-free-horrible-code attitude of a student with free time :)

Thats what I reported on in my last post -
Thats exactly what I've just done.

I'm in the middle of debugging it now with a colleague - could always do with help of course :-)

Apologies mark for my downright ignorance of your post. I would be happy to have a look at it; keep me posted :)

No worries...

Contact me direct if you want some more about what I'm trying to do....
And I can get you a login etc.

Todays problem is getting apache to play nicely with autogenerated authz and passwd files.

Joy

Cheers

Mark.

If you would post a patch here (even if it's still very much in progress), it'd be a lot easier for everyone to help!

Hi

I am trying to post patches as I go...
right now, I think the outstanding things are really the new modules (og_gpromote and svn)... I'll post them as soon as I get to some sort of stable state - hopefully early next week - please bug me if not :-)

The help I need is more getting it all together on my web site - I'm thinking that's really down to me :-(

cheers

Mark.

Ok, no worries...
Oh, wow, I did look at the old subversion module, and started form there, but didn't get too far - didn't know about the svn module - sorry - had I know, I'd have offered to pitch in there!

I wont post the SVN, but it may be worth having a look to see what I've done, and if there is anything helpful there. At a guess, there wont be, the only "nice" feature of SVN that I do think should be made available is the "extern" mechanism.

My "svn" module is actually 3 modules... an svn module which handles authz/passwd files (or tries to - I've got loads of bugs that I'm fixing in that bit) This has a load of setup features for setting up new repos etc etc... and critically asks which groups (OG) should have what sort of access to which repos - and from that, I generate the authz/passwd files

Next there are modules to hold the repo and "release path" on the Group home pages.

The svn module trawls through to find all groups nodes with these special CCK field types on them, and then processes from there - if you follow me.

In the end, this seems a nice flexible way of doing things, but - in the end, I'm guessing each person, which each SVN environment is going to want something slightly different. I think the more "kit like" we can make the SVN set up the better.

subscribing - I could really use this ALOT!

This repeats much of what I've said here: http://groups.drupal.org/node/6180

I want to emphasis one thing. Setting this up was EASY. The result is a "just the way I
want it" project management system.

From my side, I now have everything (almost) I need working. One small "nice to have" left.

To re-cap, if you want to do this at home - AND YOU CAN - it's about an hours work:

• Set up a cck type for a project. Put any fields you like in there, that are relevant to your
  projects. You can have any number of different types of project too.
• Make the project types home pages for organic groups. Configure OG the way you want it. Personally, I
  wanted hierarchies of membership of my projects, so that a "user group" (not a project, but an
  organic group) can be "subscribed" to a project - see og_gpromote - I also wanted mail lists
  (og2list), etc. this is bread and butter setting up drupal the way you want it stuff, so shouldn't
  be too hard
• There are, as far as I am aware 2 aspects of project* which are important
  1. SVN/CVS integration and releases The issue here is that there are several mechanisms to do
     it. I've written a module that "works for me", but in doing so - while I tried to keep my module
     general, my conclusion is that SVN integration is going to be a "site by site" thing.
     
     I have complete control over my server, and my server runs the svn stuff - I can, therefore, read/write
     to authz/passwd files, etc etc... run svn commands directly, etc..
     
     Thats not the case for all/many
     
     And, indeed, each svn repo I've seen is set up just slightly differently. So, if your situation
     sounds like mine, by all means get in touch, and I can send you my code. Meanwhile, please track
     the other SVN related projects. All I can say is that the current project* set of modules did not
     help me much with SVN anyway.

     If your SVN mechanism supports it, and it's appropriate to you, you can set up a content type for
     releases, and include a list of releases as a view field on your projects. In my case, "releases"
     are actually tags in a specific SVN repo, so my SVN module provides a way of listing those as a
     cck field.

  2. issue tracking Issue tracking turned out to be trivial and eligant with views and cck. Simply
     set up a content type to hold an issue. Add things like severity, type, description, etc - I also
     added a second type to hold a "use case", and provided a node-reference link in my issue to a use
     case. Personally, I also wanted owner, and %done, and expected time and stuff like that.
     
     Crucially, add a node reference to the project type.
     
     Build a view that takes as arguments the NID of the project, and the type of issue.
     Now, in the project type, add a computed field (A great way of including arbitary text and links
     in your page), In that computed field, add links to your view, using the NID and type as arguments

     Since this is perhaps the only "difficult" step, I've included the code I've used

     $node_field[0]['value'] = '<a href=/todo?filter0=**ALL**&filter1%5B%5D=**ALL**&filter2%5B%5D='.$node->nid.'>All</a><br>'.
     '<a href=/todo?filter0=**ALL**&filter1%5B%5D=bug+report&filter2%5B%5D='.$node->nid.'>Bugs</a><br>'.
     '<a href=/todo?filter0=**ALL**&filter1%5B%5D=support+request&filter2%5B%5D='.$node->nid.'>Support Requests</a><br>'.
     '<a href=/todo?filter0=**ALL**&filter1%5B%5D=feature+request&filter2%5B%5D='.$node->nid.'>Features Requests</a><br>';
     
     

     The view I set up has a url "/todo". It has several filters. "filter2" is the node ID of the
     project, and "filter1" is the type of issue. You should make your view how you want it, and use it -
     you will soon find out which filters do what.

In the end, I have a group page for each project, each project has forums, an email list, issue
tracking and svn integration. I use "books" as documentation, and any book "published" in the group
arrives on the home page as documentation. Thats what I wanted, and it really was easy to set up
with Drupal.

Hope this helps, and please do not hesitate to get in touch if you want my SVN models.

Btw, when we do this, I'd like to see us also allow multiple CCK types to be flagged as "project" types, similar to how OG works.

This would allow us to add totally different fields to modules than we do for themes and different yet again from translations. It would also allow us to make the project pages look different from one another ("Link to videocast" might make sense for a module; probably not so much for a translation.. but a translation might want a "string completion" graph that's prominent). Additionally, it would allow us to create theme listings that are more visual than the standard module listings. And a bunch of other really nice things. :D

Maybe this would be best of all worlds? (OG-like nomination of which content types should be projects).
From my point of view, what I have 'lost' by not using the projects module, I have more than gained by the flexibility of re-implementing it with CCK, and og-forums.....

Brief note -- busy today.

It is worth noting that I was able to clone a very large portion of Project* in D6 with other modules: CCK, Views, Comment CCK, Comment Upload, Notifications. The only pieces of Project that we might need in D6 are Project Release, CVS, and some form_alter() goodness for multi-stage issue forms and the AJAX elements on comment changes.

The problem with that approach is that it introduces multiple module dependencies. However, it might be for the best in the long run, since it will allow us to focus only on the version-control specific items.

Do we have a good test server somewhere to sandbox this installation, or should I see if we can get one running?

Well, the issue with a test server is the CVS integration piece. I'll see what we can do when Crell gets back in the office next week.

Right, but I don't know that we have any CVS admins available to help. I certainly can't.

Subscribing

subscribe

subscribing

So just want to confirm: is the current direction to mostly devolve Project* to delivered modules, more like a recipe of other modules?

Configuration Management, Automation & Features could define a path towards CCK support by simplifying this module and instead using functionality already present in other modules.

CCK would not be a good move today.