Re: Can't Save Preferences

[Luke <..hidden..>]

On Mon, 18 Apr 2011, Chris Travers wrote:

> On Mon, Apr 18, 2011 at 10:47 PM, Luke <..hidden..> wrote:
> > On Mon, 18 Apr 2011, Chris Travers wrote:
> >
> > > > Could the fact that the login in the table is "user", but the login used
> > > > to log in is "user@co" be relevant?
> > >
> > > My reading of the code says that this would cause the problem.
> >
> > Can you direct me to the code in question?
[.]
> > Originally, in SL, you could have users like:
> >
> > A@X
> > B@X
> > A@Z
> > C@Z
>
> Ok, so you are right.  There might be a fix in admin.pl/Admin.pm possible.
>
> A@X should be stored in the central db.
> A would go in the employees table.

Right, so we have in users and users_conf, the user ID (say 8), and the 
username of "A@X".
Then in the company, in employee, we have the employee ID (say 10219), and 
the login of "A".

Now, do I understand correctly that AM.pm is going wrong around line 1319, 
where it is comparing employee.login against $form->{login} (which is 
presumably the version with the @ sign)?

Actually, if that's true, AM.pm isn't wrong at all.  What is wrong, is 
whatever piece of code is taking away the RHS of the @ version usernames, 
before they make it into employee.login.
I think I understand why that is happening, but I haven't found where yet.

"Why", is probably that original use case for at-sign usernames that I was 
talking about.  Once you got into the right database, the RHS would no 
longer be needed.  However it is kept at the database level and 
authentication level, then dropped at the application level.  It should 
have been retained at the application level, and the checking for group 
association done some other way.

I could either try to fix the root problem, which would require an SQL 
fix to be run, as well as some code changes; or I could try to patch for 
this case in AM.pm.
[Assuming I'm right about what is going on.]

Hopefully I'm not on the wrong track.

Luke