Re: LSMB 1.3: Same user, multiple companies?

[Chris Travers <..hidden..>]

On Sat, Jul 2, 2011 at 12:48 AM, Luke <..hidden..> wrote:
> On Fri, 1 Jul 2011, Chris Travers wrote:
>
>> I will then propose the following solution:
>>
>> Adding an argument to the user saving routine, and checking whether
>> the user already exists if that is not set, and exposing that to the
>> user interface, with a default to check and raise an exception if it
>> is not set.
>
> To elaborate that a bit, you're saying:
>
> Add an argument to the user saving routine.
> If it is set, intercompany users are not checked for.
> If it is unset, user creation fails for intercompany users with one
> company to their name.
> It will have a corresponding element in the UI to control it.
> The UI version will default to unset.
>
> The result will be, that by default it will still fail on intercompany
> users unless some UI element is altered?
>
> Do I understand?

Yes.
>
> I see this as more of a non-UI issue.
>
> The hosting companies are not going to want a company admin to be able to
> change this setting.  And it still gives regular users another hoop to
> jump through.
>
> I really think allowing it by default with a warning, is the way to go
> here.

Perhaps I don';t understand what you are proposing.  If it fails, you
click back, change the setting and click forward.  If we want to make
it a warning, we can intercept the error, throw a warning and allow a
retry with the other setting set.

Part of the problem here is that creating a new user and importing an
existing one are deceptively different.  For example,  we wouldn't set
the password if importing an existing one (new users currently have
their passwords set to expire after 1 day unless they change them, but
we may want to change this default, which also affects help-desk
password resets).  With a UI component, we can hide irrelevant
elements (like the password field when importing a user) using
Javascript and CSS so that this is less confusing.  If we have to go
with a warning, I think we'd have to be explicit about ignoring the
password change that was requested.

IOW, with password settings, if creating a new user we'd set the
password as valid for a period of time (right now its 1 day, but that
could be changed to, say, 7 days on new users and 1 day on existing
ones).  When importing a new user we wouldn't set the password or its
expiration.  I would rather the UI be clear about what's going on than
a "do what I mean" that might be confusing later.

Does this make sense?  If you'd like to see a warning, would you be
interested in submitting suggested text?

Best Wishes,
Chris Travers