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? 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. The hosting companies are the only ones for whom this will likely be a problem, and we have to assume they will be more security conscious than the regular or even power users. My $.02, and I'm fine with whatever ultimately, but the above would be my preference. Luke ------------------------------------------------------------------------------ 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
