Re: [Tikiwiki-devel] Linking registration to a tracker

[David R. N. <d.r...@qu...>]

mose wrote:

> le Wed, Jul 07, 2004 at 11:33:34PM +0100 par Dr. D. R. Newman :
> 
>>I needed, for several Tikiwiki sites, to collect extra information
>>when people register. On www.tikiwiki.org we want to be able to
>>contact people who register in particular constituencies, and
>>invite them to local meetings. On sites set up for my students,
> 
> - no, www.tikiwiki.org don't want to do such things, I prefer it's
> clear that what you talk about is a possible example of need, and not
> a marketing plan for the future :)

My mistake, I meant www.greens-in.org. I was just giving two examples of
why I need to be able to add extra fields to the registration form. There
are plenty of other reasons.

>>The solution I implemented is to link registration to a tracker.
>>
>>1. From the login admin page I can select a tracker.
>>2. From the tracker field admin page I can select particular
>>   fields to be presented on the registration form.
>>3. Then when someone goes to register, they see the standard
>>   registration fields, followed by the selected fields from the
>>   selected tracker.
>>4. When the registration is accepted, the values they completed
>>   for the extra fields is stored in the tracker. (If your tracker
>>   includes fields called 'name' or 'email', the chosen username
>>   or e-mail address is stored in the tracker as well as the
>>   users table.)

Note that I don't think the process above is the best way of doing
it. I was just the simplest way I could quickly come up with doing
half of what is needed.

Ideally, we need a contacts database, containing data both on registered
users, and on all our other contacts. Think of the contacts and
addressbook managers found in lots of groupware and personal information
managers, from the Palm Desktop and MS Outlook to TWIG and eGroupware.
Each user could add in extra contacts, keep track of communications with
those contacts, and agree to share (or not share) particular contacts
with members of particular groups to which they belong.

> - Actually I got exactly the same idea and implemented it in 1.9 since
> january. It's not following exactly the same logics but it's not far.
> It's not obvious so I feel the need to be a little verbose on how it
> works (someone else asked me about it recently).
> 
> 1. in admingroup you select a tracker for extra group information and
> extra user information if they are in that group. The field used to
> match the login is setup there too.

That's better than just expecting the tracker to include a field called
name.

> 2. in trackers the fields scheme includes a password clear field, in
> more than the login field, plus email address, and all the extra
> information I need. And also 1 buttons to automate the registration 
> by the moderator. 

I was only thinking of self-registration through the form, without
moderation. Does your scheme also allow an administrator to add a user
through the tracker (as well as the user admin. page)?

> There is also the need for a user-type
> field with option 1 to specify it's an author field. that field is
> used to grant write access to the user only to his tracker file.

Is that to support user updating of the data, after registration?

> The auto-inclusion in the group could be more easy, to solve it I
> added a second action field, that means that moderation of accounts is
> not a one-click operation yet (but should be, if I implement the
> "multi-action field type").

Is this some kind of rule-based action, like in Galaxia?

> 3. I put on a wiki page a plugin Tracker that will then display the
> form of account request, replacing the register page.

Does that mean a designer can add extra explanations before and after
the registration fields?

> 4. user tracker items are configured as pending at creation, then
> admin has to review accounts requests in the tracker and when an
> account is okey to click on the action button. The action field type
> in 1.9 adds the possibility to use all the fields in the current
> tracker item to build a post or a get request to another page. I used
> it there for egistering accounts but it could be used fore many other
> things.

How about making the rule fire automatically on registration, without
human intervention (if the administrator sets it up to do so)?

> 5. When the user account is created, his usertracker id follow him,
> and a new tab in user-information page displays the extra informations
> extracted from tracker item.

Great, I wanted to do that, but didn't have time.

> - your system sounds good, simple and not heavy. Mine is already
> integrated in 1.9 and required huge patching, with adding a special
> perms scheme for tracker items depending on author field (which is
> quite new in tiki, as we usually use the perms system rather than
> direct from-object permissions).

Again, I only did half (or less) of the job I think needs doing. Your
approach goes further. Maybe the person who wrote the TikiCRM page
can find a way of combining them, or even a design for a Tiki contact/user
manager.

As for the permissions, I cheated. On registration I ignore the permissions,
as a user is entering his/her own data. But afterwards, only those with
permission to read the tracker can see the data: this may exclude the user.
The permission system cries out for redesign. But as it is a lot of work,
I'm not surprised that noone has done it.

> I documented it extensively, but in french, thinking that translators
> could help porting it on doc.tw.o. : http://fr.tikiwiki.org/Formulaires
> and more specificaly http://fr.tikiwiki.org/tiki-index.php?page_ref_id=34
> for the topic we are talking about.
> 
> Well, translating that doc should be a focus for the 1.9 final. Anyone
> can help ?

Quand j'essais parler francais, falo Portugues.

-- 
Dr. David R. Newman, Queen's University Belfast, School of
Management and Economics, Belfast BT7 1NN, Northern Ireland (UK)
Tel. (direct) +44 (0)28 9027 3643 (office) +44 (0)28 9033 5011
FAX: +44 (0)28 9033 5156  mailto:d.r...@qu...
http://www.qub.ac.uk/mgt/staff/dave/