On 20/07/11 08:54, Jan Provaznik wrote:
On 07/19/2011 11:30 PM, Scott Seago wrote:
> On 07/19/2011 02:11 PM, Hugh Brock wrote:
>> * We need to make sure self-service really is sane. A big part of
>> self service is image visibility -- i.e. who can launch what where
>> (VMWare's "Catalog" concept answers this requirement for
them). A
>> good self-service solution is going to take thinking through some
>> use cases and some serious UX work as well.
> Speaking of self-service, currently self-service user creation has been
> removed from the UI. It appears to be an inadvertent regression that
> came with the redesigned login page, but now that it's gone, it's been
> suggested that we didn't want it anyway -- that we _want_ explicit admin
> approval before a new account is enabled.
>
Only nit: I made sure that removing self-service from login page is
approved by Angus before ACKing the patch so I think it was more
intention than inadvertent regression.
Jan
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel Both accounts are correct.
Self-service account creation on the login
page was inadvertently removed during the overhaul of the login page,
and I then confirmed to Jan that the patch could/should be ack'ed
despite the apparent regression.
All that serves to open up a conversation about what we actually want to
design into the app.
I'm not at all convinced that there's really a credible use case where
an organisation which deploys Conductor will want to enable *anyone* who
can navigate to the login page to start creating deployments, consuming
resources, and spending money.
In the corporate world, it is far more likely that organisations will
require that users are correctly identified and associated with their
cost centre/business unit etc. first, so that their usage can be
correctly accounted for and charged back etc..
Away from corporate users, any organisation or group of users is going
to want some level of control, since the person who is paying by the
hour for running deployments is, almost by definition, not the
self-service user who creates an account without reference to anyone else.
Even with self service user account creation enabled, we don't
necessarily achieve the goal of reducing administrative overhead, and
letting users just use the app without administrative overhead, since
administrators will still be required to ensure that the roles
associated with a specific user, and the pools to which they have access
etc. are correct.
Another advantage of allowing users to create their own accounts is that
it allows administrators to crowdsource what is otherwise a tedious,
repetitive task. Even when user's credentials are contained in LDAP or
AD, there's still per-user grouping, permissions etc.
I wonder if we'd be better off providing admins with a CSV file format
through which they could specify user parameters in a spreadsheet for
bulk import.
Angus