Forum OpenACS Development: Screen name / real name parameter

Not directly responding to your question, but you might want to look at Lars' work on external authentication, so that your changes and his don't conflict.

This looks like a useful feature. 😊

I've thought about some of the difficulties associated with the screen/real name parameter and I think I have come up with a solution that is workable.

Setting the screen name parameter before any user signs up isn't a big problem.  The user will always be prompted to input a user name at registration.  The main problems arise when the switch is toggled after a number of users have registered.  Previous users won't have a screen name because they weren't prompted for one at user sign up.  To solve this problem, when the screen_name parameter is turned on, users will be identified by screen_name, if it exists, or their real name if it does not.

This is perhaps an overly simple solution, but one that would eliminate the necessity of modifying ad_maybe_redirect_for_registration, because every user would be identifyable by some handle.  Of course, I'm not sure as of yet how the external authentication package will impact this, but I'll push forward to get this implemented.

My plan is to do this in the 4.6 branch unless I am told that it would be better done in HEAD.

I'm ready for an update on my progress on adding this parameter. I'd also like some comments about my approach.

I've added a ScreenNameP parameter to acs-subsite, which defaults to 0. The registration procedure governed by acs-subsite honors the parameter and will require the user to choose a screen name at the time of registration.

To aid package develpers, I've also modified and added some procs and sql functions (postgres only at this point, but I'll have oracle by the time I'm done). These are all housed in the acs-subsite package:

TCL Procs

user_display::get_screen_name_p

Takes no parameters. This proc returns the value of the ScreenNameP parameter of the closes acs-subsite ancestor package.

user_display::get_name

Requires a user_id and optionally takes a -screen_name_p parameter. If screen_name_p is not provided, it will be found by calling the get_screen_name_p procedure above. If screen_name_p is 0, this proc will turn the real name of the user. If screen_name_p is 1, the screen_name will be returned if it exists, otherwise the real name will be returned.

SQL Function

user_display__get_name (postgres)

This function requires a user_id and screen_name_p. The return for this function is the same as the tcl get_name function.

As a test, I've modified the forum package using both the tcl and sql functions, and it appears to work well. I'm not sure how this approach will affect performance, but we should be able to improve things by caching the tcl procs.

Will this approach be sufficient to allow us to start modifying packages to honor this parameter? I'm interested if this approach is something the community would approve for inclusion into the toolkit.

This feature will be very useful for a small website I'm working on every now and then.

If possible it would be good to have real names optional if ScreenNameP=1.

And it would be very nice to have this on cvs HEAD, or any branch that will include the i18n ability.

Do you plan to add another parameter for keeping email addresses (and real names) private?  Or is that implicit in ScreenNameP=1 ?

A bit related:

Won't the ability to keep email addresses private call for some inter-user-communication features?

A web interface for sending a message to a user's hidden email address, like is possible at Yahoo groups, or a webmail-like private messaging system (messages stored on the web server) like phpBB.com features?

Is there any functionality like this available for OpenACS?  I might try to implement something like that...

Looks like you're nearly done, Benjamin ... let me know when you've got a patch ready to submit and we can slip it in after testing.

Til,

I have Ben's patches, that were originally made for oacs-4-6. I have been adapting them to HEAD but with the entire reorganization of the registration process, and move to /lib, plus external authentication, I have not finished it yet.

The fact that I'm in the middle of my midterms did not help either, but I should commit everything this weekend.

Did I accidentally commit a user_display:: proc? I didn't mean to.

-Roberto

Isn't the whole point of the user_display::get_name that it gets used _everywhere_ instead of displaying the column values directly, which means it needs a lot of replacing in all existing packages, including some kind of audit to make sure there is no place left where the privacy rules are not obeyed?

Do the patches you are planning to commit contain such changes to packages or are they just the api?

Since this touches a lot of things, can we postpone this until after 5.0?

I agree with leaving it out at this point.  My original intent was to get the user_display procs into 4.6 HEAD early, so work could be done to get as many packages as possible to honor the new parameter.

I actually finished my work in mid-late August, but the process of getting bigger core changes, made by a non-committer, into the toolkit is not very well defined. This whole process from the beginning has been pretty frustrating, actually. I would have liked a little more comment from the core developers and community members before I went ahead on such a big change, but that didn't happen.  I did my best to implement what I thought would be the most useful, but without more community support, I had little hope of my patches actually making it in.  I guess that's why the TIP process was created, I was just a bit too early.

What I'd like to do now is wait for 5.0 to release, and then reimplement it on the new code base.  With 4.6 dead, trying to fit my work back in to the much-changed 5.0 would be almost as much work as starting over. After 5.0 is out the door, I'll write up a TIP.

I wish this little project had turned out better.  One reason I posted so early to the forums about my ideas for implementation was to hopefully avoid major clashes with the authentication code going in.  The necessary communication didn't take place.

So much development is going on in private, with no access to the code until it's completely done, that it's almost impossible to contribute anything meaningful to the core, especially if you're an independent developer.

I don't know that TIPs or increased governance are really going to be an answer to get more of the "little people" or "worker bees" to contribute more than just simple patches.

I'm currently following another project with literally dozens of people making meaningful, useful, and rapid improvements and additions.  Anyone who sees an itch to scratch has all to tools they need to get their work done and still be current with the newest developments of the main branch.  In addition, their work is easily merged into the main development line. I hope one day we will have such a system here.

The project is Arch (now Gnu Arch).  It's a fairly small project now, with a dictatorship style of leadership, but it is already a very useful tool (version 1.1 is scheduled to release beginning of November).

Arch is a distributed version control system (self-hosting, of course), which is why so many people are able to contribute to it. Developers can make their own repositories and branches, make their changes, and have their work merged back into the main tree.  Most developers set up their own "read-only" repositories, and submit bug fixes or new features by telling the lead developer which repository/branch/patch to merge from.

For me it wasn't clear from reading this thread in the beginning that it would be such a major change which would require touching almost every package - this could have been stated more clearly, then propably more people would have joined the discussion.

I disagree that having commit rights is the solution for these kind of problems, since a major change like this should definitely be preceded by a public discussion with everyone having the chance to participate. Since there is the TIP process now, this problem is solved (kudos to those who implemented it!!!).

Benjamin,

Which development are you talking about that's going on in private?

Development of external authentication, at least, has been quite open. The spec has been up for months in a public, advertised place. Our design documents, too, have been public and announced. And during development, we have at most been one day's worth of work away from the last commit to the OpenACS repository. So it can't be external authentication.

Which developments are you talking about going on in private, then?

/Lars

Hi Benjamin,

Thanks for airing your complaints. We want this to work (for all our sakes), so if you think of any concrete ways we can change things, let us know. We don't want to frustrate new developers -- we want to welcome them in and make it as easy for them as possible. So please let us know what else we can do.

I wish this discussion had received this much attention a few months ago.

In retrospect, the solution I came up with and implemented is insufficent.  With external authentication, we now have 3 main possibilities for what name the user should go by: Real Name(with all it's variations), Username, and screen name.

I think all of these variations should be user-configurable.  If a user really does want to be know by his real name, instead of his screen-name, let him do it.  Likewise, if his username is already generic and anonymous enough, why require a seperate screen name?

My previous work put all of these decisions in the hands of the administrator, I think they should be up to the user with the administrator setting the defaults.

Thoughts?

Also, regarding the attention this is getting ... it's a volunteer effort, so you can't do much to force anyone to pay attention, you can only encourage ... Such is life :)

If you decide to add the IM addresses without looking or even installing the jabber package, which takes care of this, please contact me the moment you commit to CVS, so we have a chance to modify the jabber module and package

That has been discussed before.
I will try to get my changes from acs-person (which is deprecated) into the community-core upgrade so we at least have a usable HR-XML type DB.
I have everything done, except for the fact that I need some PG 7.3 functionallity (specifically drop columns and create or replace views). This has already been approved but put on hold pending the final status of PG 7.2 support.