On Sat, Jul 2, 2011 at 12:48 AM, Luke <[email protected]> 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 ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
