If it can be made for the next release I would say let's keep it simple for now, 3 roles : 

-admin : can do all the CRUD operations + creating/deleting users
-developer: can do all the CRUD operations
-simple: can just do read operations

The default user (admin/123) should have the "admin" role.

Users created by the admin can have the role developer or simple 

Users created by the admin will have the default 123 password to be changed the first time they log in.

But !

The big questions remains around design, how to design that ? 

Seb






On Tue, Nov 5, 2013 at 4:09 PM, Matthias Wessendorf <matzew@apache.org> wrote:
What's the plan moving forward here ? 

-Matthias



On Thu, Oct 17, 2013 at 4:17 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
Well, yes now that you said that :) Security based on Grouping.


On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew@apache.org> wrote:
you mean grouping ? 


On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew@apache.org> wrote:
any corp. org. may want some with just read-only access;
The project lead is allowed to update the keys etc, but all the /normal/ developers can just see the IDs/secrets (so that they can use it in their server apps).

This is also an interesting point, at some point don't we want the "read" rights limited to a single/set of pushapps or even a level deeper based on variants ? 
Maybe in a big company, Bob the slacker intern has read access for his supracool push app but also has access to the Public Relation Push App  keys ...



I guess that's not really (at least for me) closely related to a 'test via admin ui' feature

-M


On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych@gmail.com> wrote:
Not sure about the role: user.

What will be the use case for this one?
One use case, I see is if the 'user' is a tester. If we had the feature to send push notification test via admin UI (as we discussed in [1] and [2]).

++
Corinne
[1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-UI-td2678.html#a2718
[2] https://issues.jboss.org/browse/AGPUSH-38

On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew@apache.org> wrote:

>
>
>
> On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
>
>
>
> On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:
>
> On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc@gmail.com> wrote:
>
>> So for the next Unified Push Release (0.9) it would be nice if we could have some decent User Management, so I'm bumping this thread again.
>> Some existing pointer :
>>
>> -   this thread :)
>> -  https://issues.jboss.org/browse/AGPUSH-351
>> -  https://gist.github.com/sebastienblanc/6547605
>>
>> First point to define is :
>> -  What roles do we want ? And what can these Roles do ?
>
> Admin - Can do all things including creating other users
> Developer - can create apps and such. no access to the user management UI
> User - read only - not sure if this one is needed
> Yes, not sure also but why not ? Could be useful for a monitoring app/RHQ plugin that just want to retrieve the list of active pushapps ...
>
>
> +1 - I like these three different roles, including their rights
>
>
>
>
>> -  How can these Roles be created (granted ...)
>> -  Design
>
> I think we are still waiting on Hylke for this?   not sure
>
>>
>> Seb
>>
>>
>>
>> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <matzew@apache.org> wrote:
>>
>>
>>
>> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis <aemmanou@redhat.com> wrote:
>> Following the discussion on GitHub [1], here are some points to be
>> discussed about the user management flow:
>>
>> - Does it make sense to add a role select field (admin, developer) on
>> the enrollment page?
>>
>> hrm, and (perhaps later) a section where to define the roles ? I think it's a good point, but not sure we need all this 'now' :-)
>>
>> - Should we add an additional password field (password confirmation) on
>> the enrollment page?
>>
>> yeah, would be nice
>>
>> - I think that the current logged in user shouldn't be available for
>> deletion
>>
>> yep, I agree
>>
>> [1]:
>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6
>>
>>
>>
>> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote:
>> > A Jira has been created https://issues.jboss.org/browse/AGPUSH-351
>> > And draft structure has been created
>> > here https://gist.github.com/sebastienblanc/6547605 that can be used
>> > as base for the Pull Request.
>> >
>> >
>> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx@qmx.me> wrote:
>> >         On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira
>> >         wrote:
>> >         > Would be nice to have a 8 hands document on it
>> >
>> >
>> >         who's going to start the pull request on it? it's SPECTIME!
>> >
>> >         --
>> >         qmx
>> >         _______________________________________________
>> >         aerogear-dev mailing list
>> >         aerogear-dev@lists.jboss.org
>> >         https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev