Alex,
This sounds labor intensive, and a great idea for a perl hack.
You guys know what fields from each program Community needs to run with, so it would be easier if you guys came up with at least the shell of this.
But, a program that asks for each of the programs you want to import from, and does a "merge" on the users. If it finds users with the same ID it flags them, and moves them to a new list. Because of encryption, it's probably not easy to see if the passwords match (unless they always encrypt to the same string), but if the passwords can be matched, it's a safe bet the same ID/PW combination is the same user (or same validated email address).
Unique ID's are imported from the program they are originally found in, duplicate ID's are entered into a new database for special handling.
A person could "group" their ID's if they log on to the interface, and enter the correct password for each ID they want to merge.
This is going to be a *big* problem for the near future, for loads of sites that set up years ago, and now need to merge a forum, links and email. Automating it would be a really, really *big* thing to get people to migrate.
I have about 30 needs for this. I'd like to merge _all_ my sites into one uniform log on, but that seems to be down the road a bit. But, for the sites that I'm setting up now, which have a Links and Forum, merging the two is a need. Doing it manually is problematic -- at best.
- What about a "unified logon".
A version of community that runs like an "arbitrator" rather than a "passport". This version of community tracks the ID's entered on other community systems, and either rejects, or allows an ID, depending on whether it already exists on another site. When it's set up, it imports the Community database of each of the communities set up. When a user registers with a community, the "arbitrator" site is checked first, the ID flagged as pending, and when the user successfully registers with that community site, the ID is flagged "taken". If not, it times out in 5 days (several days longer than the default community time-out).
When the "remote logons" feature of Community is enabled, this "arbitrator" is the site that is used to set up the "main" community site. It knows all the ID's on all the other communities, and can import them and set them up.
- And, for the importing of a single site with multiple apps, if a new user database is set up, with an ID field, not just the Username, as PK, then all records could be imported, duplicate ID's can be selected out, into a second database, and the rest of the ID's imported from that file into community. The duplicate Username file, could be managed manually (if the accounts have the same email, the admin can set up one account, set up a password, and the usre would have to request it next time they log on, but they would have a unified account). If the usernames are belonging to different people, the admin would have to come up with a way to arbitrate them. I think Gossamer Forum would take priority, since it's interactive, and people actually know you by the ID.
Just some ideas, but if you (GT) can work out a shell for this, I would be willilng to flesh it out, and I'm sure Andy would help. This is a big deal, and the importance of working out a script to do it at this time can't be over stressed.
PUGDOG� Enterprises, Inc. The best way to contact me is to
NOT use Email.
Please leave a PM here.
Re: [antoined] Gmail integration! with G community
Re: [Alex] Gmail integration! with G community
Re: [Alex] Gmail integration! with G community