User referred to as "openiduser44" in event RSVP

The LoCo Directory only allows Launchpad OpenID which is what is used on all Ubuntu-related pages.

Can you maybe clarify how this bug is different from bug 540532 and bug 495046? I'm not sure I understand.

"openiduser44" isn't, as far as I can see, a Launchpad username...

I can't find a launchpad user id for "openiduser44" either. It seems either Launchpad or django_openid_auth returned incorrect data, or somehow the user used a different openid provider to log in.

Ok, now I understand. The only thing I can imagine is that once a user openiduser44 existed and the account was renamed later on - there's no way for us to know about this.

I'll talk to Launchpad developers about this.

Discussion with a Launchpad developer:
<flacoste> dholbach: users on launchpad SSO don't have a Launchpad profile created automaticlaly anymore
 dholbach: only if they log on launchpad directly
 dholbach: that's following the SSO separation
<dholbach> flacoste: erm, so what does this mean? :)
<flacoste> dholbach: it means that the user will only have a Launchpad profile once he logs in launchpad
<dholbach> ahhh :-(
<flacoste> dholbach: he can create a Launchpad SSO account to lo log on your loco site
<dholbach> flacoste: should django-openid-auth be checking this somehow?
 hm, maybe not
 maybe we should check via the api if the user exists
<flacoste> dholbach: that would defeat the purpose :-)
 dholbach: you could restrict to a team
 dholbach: and make that team an open team
<dholbach> I can understand loco teams that want to have a link to actual people that will turn up to their events, etc :)
<flacoste> dholbach: that way they have to join the team on Launchpad to log in
<flacoste> thus ensuring that they have a launchpad profile

The problem arises when the user logs in with an OpenID account that doesn't have a "nickname" filled out. This seems to be possible for Ubuntu SSO accounts that do not have Lauchpad profiles created.

So one solution would be to require ~locoteams membership.

That doesn't seem too unreasonable IMO. If it is a LoCo event, they should really be in the LoCo team :)

Do we want to limit access to register as coming to an event to people who are members of a loco team?

Why such a limitation? All the ubuntu users should be welcome to register to an event, not only the members of ~locoteams. By the way, not all the loco teams use their Launchpad group as a Local user group (we don't in the french team) so lot of users aren't on this group.

Can't we just detect this type of accounts by testing the nickname, and reject all the openiduserxxxx to a message "fill your nickname" ?

All ubuntu users *are* welcome. The LoCo Directory design is based on the fact that there are underlying Launchpad teams to arrange the users. Whilst nobody is saying a LoCo *needs* to make use of Launchpad for this feature, I have no issues with maintaining the approach of getting a richer experience if teams do.

The LoCo Directory should strive to be as inclusive as possible, but LoCo's are not mandated to use it.

I further suggest:
-> Login
      If member of ~locoteams: proceed
      else: redirect to page suggesting join.

LoCo Directory being a LoCo resource, if attendee's aren't a member of a LoCo; then I would suggest they are 'invited' by members of the LoCo and use the "guests" feature.

If this bug is fixed in this manner, I would suggest opening a new bug of "Ability to mark attending an event, if not a LoCo member", and these users are shown in a separate table.

The problem with requiring ~locoteams membership is that some loco teams are not 'open' teams.

I think we need a balance between being useful, reasonable to implement and "best practice". As i said previously, we can't mandate how LoCo teams run their admin, but we can provide a richer experience for their users if they decide to make it open membership.

For my opinion, users have no place adding events or marking attendance if they are not a member of ~locoteams. If the user:
A) Hasn't yet joined a LoCo team (giving them membership of ~locoteams), they should be encouraged to do so.
B) If a user CAN'T join their LoCo team as it isn't open, then that is an issue at the team level that needs to be resolved - which i see as unrelated to the LoCo Directory.

-- If a potential user wants to come, but isn't a member - then i don't think it's unreasonable for them to be a ~locoteam members "Guest".

ok, firstly teams should be open and if there not, there is a serious issue here!

Secondly, I can appreciate many people will attend an event that are part of a locoteam and will have already signed up to LP, but I am also thinking that some people may not be signed up to a team so in the case of say an Ubuntu hour where we are encouraging people to randomly just drop by and come along we do ask that they sign up to give us a clue on number, but they probably aren't going to be a part of our locoteam at first.

-- If a potential user wants to come, but isn't a member - then i don't think it's unreasonable for them to be a ~locoteam members "Guest". +1

I would second the idea of a guestXXXX where XXXX is incremented for each event by each people who want to attend that doesn't have a LP account.
I think it is necessary to not only limit the ability to say "Count me on" to people with LP account.

SSO people are still people too :'(

Is there any way LP can forward SSO data via LP? I mean, Ubuntu SSO still has the basics ( username, email, real name ), and just grant them guest rights to the LD.

I guess I don't know enough about LP / SSO to really comment about this in a useful way.

There's no reason for a team to be an open team.

There's even less reason to restrict event attendance to members of that team. The technical restriction (assuming we want to change nothing regarding SSOs yet want to always have a 'real' name) is that the user has a LP profile. We should not place an artificial restriction above that. (I'm not even sure we want to put a hard restriction on that, perhaps saying "you'll be anonymous if you continue, which isn't as helpful as creating a LP profile before continuing!" is a better solution.)

Use case: User A is a member of LoCo Team B. She is on travel and happens to be in the area of LoCo Team C. She decides to attend that event and let people know she is coming on the loco directory.

User A is not a member of Team C (she doesn't really have to be a member of team B either, she might not be 'into' the whole LoCo thing, instead deciding to spend her time as a developer, MOTU, Marketing Team, Artwork Team, etc, or even working on some other project that makes use of launchpad).

I meant, of course:
There's no reason to require a team to be an open team.

Not that there's never a reason for a team to be an open team.

LoCo events are often about reaching out to new users. I don't see any reason why we should require new users to not only create an Ubuntu SSO account (which is broken and not supported on the LoCo directory), or a Launchpad account (which is a software developer service) and then join a Launchpad team when they may or may not have anything to do with the LoCo.

And this is just to RSVP! This would be a horrible introduction to a new or potential Ubuntu user who was curious about "this Ubuntu thing" and just wanted to sign up. Especially if that attitude is "If you're not a locoteam member you have no business RSVPing on the LoCo directory".

If that's the case, then I would actually consider the LoCo Directory project harmful to the kind of open attendance events I usually plan and would stop using the directory altogether. Please consider the intended audience of the directory when dealing with this bug.

Requiring loco teams membership IMHO is stupid.

We already require users to use launchpad's openid provider instead of any open id provider (even for users simply trying to confirm their attendance to an event)

Event attendance and other admin functions should not be related. I think (although this might be a different bug) we need to allow ANY openid provider for users to sign up for events. (If we want events with big turn outs)

My understanding of the using the loco directory instead of FB and Gcal would be some sort of openness in some form or manner limiting users to LP (for none admin functions) seems to defeat the point of this.

Either way this is a bug and effects my team as well and I would love to know how they event got to the "openiduser" status??

http://loco.ubuntu.com/events/team/666/detail/

You don't have to be a member of a loco team to RSVP to an event. All you have to do is have an LP account.

We are unable to fix these errors in the past, however the code has been fixed to where these errors will no longer appear.

This appears to still be affecting one of our members:

http://loco.ubuntu.com/events/ubuntu-michigan/2049/detail/

User Launchpad profile: https://launchpad.net/~lmorchard

Is there something special that needs to be done?