Dynamically create drupal user?

Well, in general I would be willing to code as much as it would take to implement the feature. Unfortunately, for the project I needed this for, I decided against storm, so it may take me awhile to get back to it.

The two problems I had with storm were the connection between users and stormpersons, and the general lack of integration with cck. I think I could have worked around the user-stormperson bit, but then I got to looking at stormproject and the first thing I wanted to do was remove a few of the fields that were unnecessary, and add a few as well. If they were cck, it would have been fine, but even as attributes, disabling them didn't seem to have the expected effect. They still showed up on the create form, for example. I dunno, maybe there was a workaround for this, but the only thing I saw in the issue queue was people themeing the fields away. I didn't like that approach.

Since I saw a lot of those types of problems coming my way, I ditched storm and just built a (much simpler) tool with cck, nodereference and rules.

I would like to come back to storm at some point but the lack of integration with cck is a real killer, imo. There were some other minor issues related to menu locations, and whether the system could handle renaming the content types and url aliases, as I wanted to 'brand' the tool for my client (the first wuestion from them was can we change the 'storm' name'?)

As far as the topic at hand, I'm wondering if it can be solved by using a combination of cck, rules, and content_profile. Then, you would make stormperson the profile content type for users, and then implement rules to tie the two together.

I'd be happy to experiment with that approach...it wouldn't be code per se, but a 'recipe' for users who want that feature, but it will have to wait until I finish this current deliverable and have time to implement storm on one of my private sites.

Magnity,

I think I might be circling back around on this idea. I've been thinking a lot about it over the weekend, and realized that even if I go my own way and role my own pm app based on cck, views, and rules, I'm still going to hit the same 90% ceiling that all these other apps end up hitting too.

Now I'm thinking again about patching up storm to do what I want. I would concentrate on a few areas:

Rules integration. There wouldn't be a dependency, just integration by supporting the API
functions for tying together stormpersons and users, perhaps using rules ( if present )
Ability to rename certain aspects of the GUI ('Branding')
some fixups on the treatment of menus and breadcrumbs
make the attribute code work as most people expect, as in , if you remove or disable an attribute, it vanishes from forms etc (i dunno, did I read maybe that is fixed now?)
support for cck.

I know cck is coming in d7 due to fields support, but honestly, it's going to be another year (or two) before widespread adoption of d7 happens.

I also don't want to introduce a hard dependency on views or cck to keep in the spirit of the module. Nor do I want to introduce massive complexity in the codebase.

What I am thinking about is a way to make the existing attribute code 'wrap' cck definitions. I haven't looked at the code yet, but my idea is for the attribute code to detect cck fields defined and treat them as 'attributes'. Then if you want, you can use it out of the box. If you want to add attributes, you can. Or, if attributes aren't doing it for you , you can add cck fields, and storm will know what to do with them. This is all very sketchy of course... it's just a few things I've been thinking about.

Anyway, I'm willing to contribute code for this, but I am concerned about the magnitude of the changes I am suggesting. How would you feel about creating a 6--2-dev branch or something like that? Or, I can start contributing patches to prove some of the concepts I am taking about and you can decide to branch later.

regards,

>Perhaps if you'd be able to separate these out into separate issues, one issue per topic? Then we can discuss per topic without making this a mega-issue!

Will, do, I'll start adding issues later tonight, or tomorrow morning

>We can have a DRUPAL-6--2 branch if need be, but let's talk about that when it becomes needed.

Agreed.

>Is this still a client project? If so (or otherwise), is there a particular timescale you're working to (just out of interest).

Yes, I started with storm, then scrapped it, then built a basic pm app and showed it to them. They liked it, but I could tell by the questions they started asking and features they started requesting that it was going to be one of these death by a thousand cuts type of thing. It's the classic tale; first they say, 'we want no frills pm, something dead simple'. Then I build that and then they say, well, could we have button here, and field here, and a reference here, and oh, btw, we also need to capture all of this other data that we didn't tell you anything about. etc, etc. Don't get me wrong, they pay me by the hour, so whatever they want....

But over the weekend I thought it might be better, since I only spent two days building the cck-version pm, to just back it out and drop storm back in, and work from there. So I started doing that today. So yes, it's still a client project, and the timescale is probably 4-6 weeks, so I will be coding hard, but some of the features they want are not all the same features I want. Of course, I'm going to work on what makes sense and try to deliver both, but they are paying the bill, so there is a hierarchy of needs.

If they ask for some custom field here or there, than I'll try my best to build it extensibly and not just butcher up the code or ad-hoc drop a 'cck island' field in. I'll try to integrate it smoothly with attributes.

>Re D7: Due to D7CX, I suspect the adoption rate will be a lot higher than for D6 - these changes also need to bear in mind D7 - and easy upgrade process would be preferable!

well that is my hope too! My suspicion is...well, we'll see! ;)