user-admin rights

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

user-admin rights

Jacques Dainat-3
Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: user-admin rights

nathandunn

Jacques,

You ask an excellent question.  We’ve definitely thought about this, but my no means is this solution perfect and user-input (and how different groups work) is very welcome.  

So, the goal we had for organism “admins” are user’s that can effectively administrate organism, but is not necessarily a full admin.   I guess in our initial pass we thought that it made the most sense that the organism admin would be a more trusted user that would manage (including adding) a group of organisms and access to the organism permissions.   To add existing users to a group, they would necessarily need to be able to see all user’s and groups.   I think the report / admin tabs should probably be more restricted than they are, but that is something that can be fixed.    

I think what you are proposing is to have a user that can add and manage users and groups that only contains those organisms (please clarify if not).  A super-admin (as opposed to the organism-admin) would have to add existing users to a new or current organism.  

Just to clarify, you are saying an organism/user-admin should have the following permissions:

- Organism tab would be visible, but only with current organisms that that user is an admin for.  organism-admin would not be allowed to make modifications to information about that user.
- User tab would be visible, but only user’s with permissions on that organism (read or better) would be visible.   organism-admin can make detail changes other than the global role. Organisms would only be those that they have admin permissions for.   Groups available be those that they have admin permissions for (? this will take a bit more thought). 
- Group tab would be visible, but only for group’s where they have membership.  If they create a group, they should automatically become members of that group (? maybe ?).  
- Admin tab will be visible, but only for reports (maybe reports should go on a separate tab) and reports should only show organisms the have admin permissions on and user’s belonging to their groups.    This might be difficult as you can have permissions that come and go within a user / group / annotation / organism.  Would have to put some more thought into that. 

Does this sound about right?   

Do other user’s have thoughts on how this might work in their own groups? 

Nathan

On Jul 12, 2016, at 6:05 AM, Jacques Dainat <[hidden email]> wrote:

Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service




This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: user-admin rights

Chris Childers
In reply to this post by Jacques Dainat-3
Hi Jacques,

We have a similar scenario with our project:  We host dozens of projects, and each organism has one or more coordinators or deputy coordinators that manage the specifics for that project.  Our model can probably be better described as offering Apollo as a service; instead if it being our projects, we work with many different projects, each one is coordinated separately. 

Currently our solution is to handle the organism level admin privileges (we call them project coordinators) outside of Apollo.  As you say, once a user has admin privileges on one species, the gates are open for all the organisms in many of the services Apollo.  We (the staff or system admins) are the only "admin" accounts, and all users (coordinators and non-privileged annotators) have standard account permissions. 

Our current production system uses some custom Drupal modules to manage which organisms are currently accepting applicants, and collects some basic information to help the coordinators decide whether to approve or decline the application.  On approval, the account creation and permission settings are automated, but the coordinator has no direct access to admin privileges in Apollo.

A solution we've been developing makes use of the groups feature: First we make multiple groups per organism (e.g. a user and a coordinator group). Then in our external app, we can query the users groups to know if they have access rights or permission to manage applicants for any given organism.  This is still in a prototype stage.  While the prototype works, we have identified several issues that have to be rethought and resolved before we can put it into production. 

I would also be happy to hear more about how other groups are managing their user communities.

I hope this helps,
Chris

 



On Tue, Jul 12, 2016 at 9:05 AM, Jacques Dainat <[hidden email]> wrote:
Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.







This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: user-admin rights

Eric Rasche-3
Hi All,

I had the same issue a while back, but I cannot find the email/github ticket I'm afraid.

On 12. juli 2016 19:50, Chris Childers wrote:
Hi Jacques,

We have a similar scenario with our project:  We host dozens of projects, and each organism has one or more coordinators or deputy coordinators that manage the specifics for that project.  Our model can probably be better described as offering Apollo as a service; instead if it being our projects, we work with many different projects, each one is coordinated separately.
Same.

Currently our solution is to handle the organism level admin privileges (we call them project coordinators) outside of Apollo.  As you say, once a user has admin privileges on one species, the gates are open for all the organisms in many of the services Apollo.  We (the staff or system admins) are the only "admin" accounts, and all users (coordinators and non-privileged annotators) have standard account permissions. 
Same here. We have a few admin accounts, and then let another service handle the user/permission config.

Our current production system uses some custom Drupal modules to manage which organisms are currently accepting applicants, and collects some basic information to help the coordinators decide whether to approve or decline the application.  On approval, the account creation and permission settings are automated, but the coordinator has no direct access to admin privileges in Apollo.

A solution we've been developing makes use of the groups feature: First we make multiple groups per organism (e.g. a user and a coordinator group). Then in our external app, we can query the users groups to know if they have access rights or permission to manage applicants for any given organism.  This is still in a prototype stage.  While the prototype works, we have identified several issues that have to be rethought and resolved before we can put it into production. 

I would also be happy to hear more about how other groups are managing their user communities.

I hope this helps,
Chris

 



On Tue, Jul 12, 2016 at 9:05 AM, Jacques Dainat <[hidden email]> wrote:
Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.







This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank. 


--

Eric Rasche
Programmer II

Center for Phage Technology
Rm 312A, BioBio
Texas A&M University
College Station, TX 77843
<a href="tel:404-692-2048">404-692-2048
[hidden email]
Not responding quickly enough?




This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: user-admin rights

nathandunn

Eric,

I think this is the issue you were looking for, where you’d advocated another level of admin:  https://github.com/GMOD/Apollo/issues/771

First, I’m glad the web services are working for users.   I know there are going to be many different use-cases, so its good that we’re supporting additional flexibility.  

Mostly, what I’m wondering if there would be changes to our permissions that would minimize the number of custom web-services that need to be scripted (especially if its the same permission change over and over), but still allow for plenty of flexibility.  

Chris, I’m very curious to see what comes out of your prototyping.  

Nathan

On Jul 12, 2016, at 12:58 PM, Eric Rasche <[hidden email]> wrote:

Hi All,

I had the same issue a while back, but I cannot find the email/github ticket I'm afraid.

On 12. juli 2016 19:50, Chris Childers wrote:
Hi Jacques,

We have a similar scenario with our project:  We host dozens of projects, and each organism has one or more coordinators or deputy coordinators that manage the specifics for that project.  Our model can probably be better described as offering Apollo as a service; instead if it being our projects, we work with many different projects, each one is coordinated separately.
Same.

Currently our solution is to handle the organism level admin privileges (we call them project coordinators) outside of Apollo.  As you say, once a user has admin privileges on one species, the gates are open for all the organisms in many of the services Apollo.  We (the staff or system admins) are the only "admin" accounts, and all users (coordinators and non-privileged annotators) have standard account permissions. 
Same here. We have a few admin accounts, and then let another service handle the user/permission config.

Our current production system uses some custom Drupal modules to manage which organisms are currently accepting applicants, and collects some basic information to help the coordinators decide whether to approve or decline the application.  On approval, the account creation and permission settings are automated, but the coordinator has no direct access to admin privileges in Apollo.

A solution we've been developing makes use of the groups feature: First we make multiple groups per organism (e.g. a user and a coordinator group). Then in our external app, we can query the users groups to know if they have access rights or permission to manage applicants for any given organism.  This is still in a prototype stage.  While the prototype works, we have identified several issues that have to be rethought and resolved before we can put it into production. 

I would also be happy to hear more about how other groups are managing their user communities.

I hope this helps,
Chris

 



On Tue, Jul 12, 2016 at 9:05 AM, Jacques Dainat <[hidden email]> wrote:
Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank. 


--

Eric Rasche
Programmer II

Center for Phage Technology
Rm 312A, BioBio
Texas A&M University
College Station, TX 77843
<a href="tel:404-692-2048" class="">404-692-2048
[hidden email]
Not responding quickly enough?



This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: user-admin rights

Jacques Dainat-3
In reply to this post by nathandunn
Hi !

On 12 Jul 2016, at 20:33, Nathan Dunn <[hidden email]> wrote:


Jacques,

You ask an excellent question.  We’ve definitely thought about this, but my no means is this solution perfect and user-input (and how different groups work) is very welcome.  

So, the goal we had for organism “admins” are user’s that can effectively administrate organism, but is not necessarily a full admin.   I guess in our initial pass we thought that it made the most sense that the organism admin would be a more trusted user that would manage (including adding) a group of organisms and access to the organism permissions.   To add existing users to a group, they would necessarily need to be able to see all user’s and groups.   I think the report / admin tabs should probably be more restricted than they are, but that is something that can be fixed.    

I think what you are proposing is to have a user that can add and manage users and groups that only contains those organisms (please clarify if not).
Yes exact, It would be great !

 A super-admin (as opposed to the organism-admin) would have to add existing users to a new or current organism. 
Yes ! As it is currently.


Just to clarify, you are saying an organism/user-admin should have the following permissions:

- Organism tab would be visible, but only with current organisms that that user is an admin for.
Yes ! As it is the case currently.
 organism-admin would not be allowed to make modifications to information about that user.
I don’t get that sentence. If you meant “organism” instead of “user” I say yes !! The organism-admin may be even “blind” about what’s happening on the server/machine side ( I mean Directory and Blat database paths).

- User tab would be visible, but only user’s with permissions on that organism (read or better) would be visible.
Yes exact.
  organism-admin can make detail changes other than the global role. Organisms would only be those that they have admin permissions for.  
Yes as it’s already the case.
Groups available be those that they have admin permissions for (? this will take a bit more thought). 
Actually I don't really get how to use “Groups” in a clever way. In my sens, the super-admin should be able to access users by species. So, I would love to see a group by species created automatically. We can call it species-group. When we link the user to a species he should be automatically assign to the corresponding species-group. It should be created as well automatically a group containing all organism-admin to keep track of them. Of course, it’s nice to keep the possibilities to create any kind of group as it is currently. The super-admin should have access to all those groups (not one created by a organism-admin ). Organism-admin should have access to groups he created, and the species-group he is linked to.

To summarise with the user tab, and comment what you said at the beginning, I would avoid that the organism-admins have access to all user’s and groups. I would prefer that people doesn’t know who is implied within the different projects. Even if they are more trusted, we never know about potential conflicts of interest. But in that case, If the organism-admin has access only to users already linked to organisms he is admin for, how to avoid he creates a user already existing in another project ( duplicated users… ) ? Maybe instead of creating the user (or organism-admin) accounts with username/password we should investigate to do it by “invitation” by email address containing a link. I don’t know how it could work, but the link may redirect you to the webapollo portal and you can connect (if you already have an account) or create an account (but only if you had this email with this specific link and only in a limited time). I don’t know what is feasible, but that might be a direction for reflection.

- Group tab would be visible, but only for group’s where they have membership.  If they create a group, they should automatically become members of that group (? maybe ?).
I agree

- Admin tab will be visible, but only for reports (maybe reports should go on a separate tab) and reports should only show organisms the have admin permissions on and user’s belonging to their groups.    This might be difficult as you can have permissions that come and go within a user / group / annotation / organism.  Would have to put some more thought into that. 
It sounds nice that admin tab stays available (visible) only for the super-admin, and a new report tab created. This report tab will contain only information of organisms which the current user is part of.


Does this sound about right?   

Do other user’s have thoughts on how this might work in their own groups? 

Nathan


Best regards,

Jacques


On Jul 12, 2016, at 6:05 AM, Jacques Dainat <[hidden email]> wrote:

Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service




This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: user-admin rights

nathandunn

I tried to summarize those thoughts up here:


It looks like you want a new permission level.   We’re happy to discuss further or if you want to issue a PR that solves your use-case.   I purposefully left room in the permission levels for additional administrative levels.  


Nathan

On Jul 13, 2016, at 8:37 AM, Jacques Dainat <[hidden email]> wrote:

Hi !

On 12 Jul 2016, at 20:33, Nathan Dunn <[hidden email]> wrote:


Jacques,

You ask an excellent question.  We’ve definitely thought about this, but my no means is this solution perfect and user-input (and how different groups work) is very welcome.  

So, the goal we had for organism “admins” are user’s that can effectively administrate organism, but is not necessarily a full admin.   I guess in our initial pass we thought that it made the most sense that the organism admin would be a more trusted user that would manage (including adding) a group of organisms and access to the organism permissions.   To add existing users to a group, they would necessarily need to be able to see all user’s and groups.   I think the report / admin tabs should probably be more restricted than they are, but that is something that can be fixed.    

I think what you are proposing is to have a user that can add and manage users and groups that only contains those organisms (please clarify if not).
Yes exact, It would be great !

 A super-admin (as opposed to the organism-admin) would have to add existing users to a new or current organism. 
Yes ! As it is currently.


Just to clarify, you are saying an organism/user-admin should have the following permissions:

- Organism tab would be visible, but only with current organisms that that user is an admin for.
Yes ! As it is the case currently.
 organism-admin would not be allowed to make modifications to information about that user.
I don’t get that sentence. If you meant “organism” instead of “user” I say yes !! The organism-admin may be even “blind” about what’s happening on the server/machine side ( I mean Directory and Blat database paths).

- User tab would be visible, but only user’s with permissions on that organism (read or better) would be visible.
Yes exact.
  organism-admin can make detail changes other than the global role. Organisms would only be those that they have admin permissions for.  
Yes as it’s already the case.
Groups available be those that they have admin permissions for (? this will take a bit more thought). 
Actually I don't really get how to use “Groups” in a clever way. In my sens, the super-admin should be able to access users by species. So, I would love to see a group by species created automatically. We can call it species-group. When we link the user to a species he should be automatically assign to the corresponding species-group. It should be created as well automatically a group containing all organism-admin to keep track of them. Of course, it’s nice to keep the possibilities to create any kind of group as it is currently. The super-admin should have access to all those groups (not one created by a organism-admin ). Organism-admin should have access to groups he created, and the species-group he is linked to.

To summarise with the user tab, and comment what you said at the beginning, I would avoid that the organism-admins have access to all user’s and groups. I would prefer that people doesn’t know who is implied within the different projects. Even if they are more trusted, we never know about potential conflicts of interest. But in that case, If the organism-admin has access only to users already linked to organisms he is admin for, how to avoid he creates a user already existing in another project ( duplicated users… ) ? Maybe instead of creating the user (or organism-admin) accounts with username/password we should investigate to do it by “invitation” by email address containing a link. I don’t know how it could work, but the link may redirect you to the webapollo portal and you can connect (if you already have an account) or create an account (but only if you had this email with this specific link and only in a limited time). I don’t know what is feasible, but that might be a direction for reflection.

- Group tab would be visible, but only for group’s where they have membership.  If they create a group, they should automatically become members of that group (? maybe ?).
I agree

- Admin tab will be visible, but only for reports (maybe reports should go on a separate tab) and reports should only show organisms the have admin permissions on and user’s belonging to their groups.    This might be difficult as you can have permissions that come and go within a user / group / annotation / organism.  Would have to put some more thought into that. 
It sounds nice that admin tab stays available (visible) only for the super-admin, and a new report tab created. This report tab will contain only information of organisms which the current user is part of.


Does this sound about right?   

Do other user’s have thoughts on how this might work in their own groups? 

Nathan


Best regards,

Jacques


On Jul 12, 2016, at 6:05 AM, Jacques Dainat <[hidden email]> wrote:

Hello !

Sorry for the inconvenience if it has been already discussed before.

I’m managing a Webapollo installation containing many organisms. For each organism I was thinking to create a user with extra rights to give the possibilities to add users. In other term, I’ m the admin of the webapollo instance, And I would like to create an “organism's admin” for each organism. To do so, under user tab, I go to the Organisms sub-tab and add the admin right to the user. Until here everything is fine. 
But I realised that the “organism's admin” can access to all the users, even those from other organisms, see them and is able to remove them. 
He can as well see under the Admin tab information from other organisms like using the Report::Organism link.

Is it a behaviour that can be modified ? If not, is it something you plan to fix/modify in futur webapollo versions ?

In my sense, the perfect behaviour, for this kind of "user-admin” would be:
- not be allowed to add New organism in the Organism tab
- not see the Users that are not working on the same organism (in the Users tab)
- not be allowed to remove users that are not related to its organism (related to the previous point)
- see only the groups he created / or he is part from (Groups tab)
- Avoid to access information not related to organism he is related to in the Admin tab (or even not at all access this tab)


Thank you for your work and the very nice tool you provide !!

Best regards,

Jacques Dainat, PhD
NBIS (National Bioinformatics Infrastructure Sweden)
Genome Annotation Service




This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.