[apollo] user-admin rights

[Jacques Dainat]

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

[Nathan Dunn]

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

Post by Jacques Dainat
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 ?
- 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/

[Jacques Dainat]

Hi !

Post by Nathan Dunn
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 !

Post by Nathan Dunn
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.

Post by Nathan Dunn
- Organism tab would be visible, but only with current organisms that that user is an admin for.

Yes ! As it is the case currently.

Post by Nathan Dunn
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).

Post by Nathan Dunn
- User tab would be visible, but only user’s with permissions on that organism (read or better) would be visible.

Yes exact.

Post by Nathan Dunn
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.

Post by Nathan Dunn
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.

Post by Nathan Dunn
- 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

Post by Nathan Dunn
- 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.

Post by Nathan Dunn
Does this sound about right?
Do other user’s have thoughts on how this might work in their own groups?
Nathan

Best regards,

Jacques

Post by Nathan Dunn

Post by Jacques Dainat
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 ?
- 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/ <http://genomearchitect.org/>

This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/

[Nathan Dunn]

I tried to summarize those thoughts up here:

https://github.com/GMOD/Apollo/issues/1178 <https://github.com/GMOD/Apollo/issues/1178>

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

Post by Jacques Dainat
Hi !

Post by Nathan Dunn
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 !

Post by Nathan Dunn
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.

Post by Nathan Dunn
- Organism tab would be visible, but only with current organisms that that user is an admin for.

Yes ! As it is the case currently.

Post by Nathan Dunn
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).

Post by Nathan Dunn
- User tab would be visible, but only user’s with permissions on that organism (read or better) would be visible.

Yes exact.

Post by Nathan Dunn
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.

Post by Nathan Dunn
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.

Post by Nathan Dunn
- 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

Post by Nathan Dunn
- 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.

Post by Nathan Dunn
Does this sound about right?
Do other user’s have thoughts on how this might work in their own groups?
Nathan

Best regards,
Jacques

Post by Nathan Dunn

Post by Jacques Dainat
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 ?
- 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/ <http://genomearchitect.org/>

This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/ <http://genomearchitect.org/>

This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/

[Chris Childers]

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

Post by Jacques Dainat
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 ?
- 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
2. In the subject line of your email type: unsubscribe apollo | 3. Leave
the message body blank.

[Eric Rasche]

Hi All,

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

Post by Chris Childers
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.

Post by Chris Childers
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.

Post by Chris Childers
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.
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
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 ?
- 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/
<https://urldefense.proofpoint.com/v2/url?u=http-3A__genomearchitect.org_&d=CwMFaQ&c=ODFT-G5SujMiGrKuoJJjVg&r=p9uZby14OqW9zcjBSjiDKw&m=WiL8vDzWx6UYC58WtyNKqCpHxli7y_CU61pe3itIxgk&s=fNtfQqxGd-1L23FV9g73hzzbvZbHTLxb_xrORC_qS3k&e=>
If you wish to unsubscribe from the Apollo List: 1. From the
address with which you subscribed to the list, send a message to
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/

--
Eric Rasche
Programmer II

Center for Phage Technology
Rm 312A, BioBio
Texas A&M University
College Station, TX 77843
404-692-2048 <tel:[phone]>
***@tamu.edu <mailto:***@tamu.edu>
Not responding quickly enough?
<https://calendar.google.com/calendar/embed?src=esr%40tamu.edu&ctz=America/Chicago>

[Nathan Dunn]

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 <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

Post by Eric Rasche
Hi All,
I had the same issue a while back, but I cannot find the email/github ticket I'm afraid.

Post by Chris Childers
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.

Post by Chris Childers
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.

Post by Chris Childers
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
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 ?
- 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/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__genomearchitect.org_&d=CwMFaQ&c=ODFT-G5SujMiGrKuoJJjVg&r=p9uZby14OqW9zcjBSjiDKw&m=WiL8vDzWx6UYC58WtyNKqCpHxli7y_CU61pe3itIxgk&s=fNtfQqxGd-1L23FV9g73hzzbvZbHTLxb_xrORC_qS3k&e=>
This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/ <http://genomearchitect.org/>

--
Eric Rasche
Programmer II
Center for Phage Technology
Rm 312A, BioBio
Texas A&M University
College Station, TX 77843
404-692-2048 <tel:[phone]>
Not responding quickly enough? <https://calendar.google.com/calendar/embed?src=esr%40tamu.edu&ctz=America/Chicago>
This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/