creating a hierarchy of students teachers and courses
Hello galaxy team, First and foremost, I would like to thank you for your assistance with my galaxy installation with apache proxy. It works very well. Secondly, I would like your help with creating users, groups, roles and permissions that would allow me to: 1. differentiate a student from a teacher 2. differentiate a student in course A or in course B 3. teachers having read access to students' work 4. teachers sharing with students Right now, I just have created users. There is no group or roles or permissions or datasets. On another note, how can I disable the account of one specific user or a whole group ? Cordialement / Regards, Edgar Fernandez System Administrator (Linux) Direction Générale des Technologies de l'Information et de la Communication * Bur. : 1-514-343-6111 poste 16568 Université de Montréal PAVILLON ROGER-GAUDRY, bureau X-218
Galaxy can do some these and maybe not others. This is a really big topic, and I hope you let us all know how progress on this goes - it is a really interesting use case. I can comment a little on each part of this, but they are all connected and there are different ways to approach each of these things. On Tue, Jan 14, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca> wrote:
Hello galaxy team,
First and foremost, I would like to thank you for your assistance with my galaxy installation with apache proxy.
It works very well.
Secondly, I would like your help with creating users, groups, roles and permissions that would allow me to:
1. differentiate a student from a teacher
Are you creating these accounts inside of Galaxy or using an external authentication method? Because if your are creating these accounts yourself - I would suggest using naming scheme to distinguish these: std_cls_lastname teach_cls_lastname Another idea to consider is to make all teachers admins. This provides a lot of extra functionality that can cover some additional requirements below and can serve as the basis for differentiating.
2. differentiate a student in course A or in course B
You could use a naming scheme, or your could create a group and role for each course. It looks like there is an API for managing groups and roles. This can help automate some of this - it would be very laborious to do this through the UI I imagine.
3. teachers having read access to students’ work
This one is why I would give the teachers admin access - I think they could impersonate the students to access their work (set allow_user_impersonation = True in universe_wsgi.ini). It would mean that every teacher would have full access to every students work - if this is a problem you might want to consider standing up a Galaxy instance per class - there is some up front overhead with this - but it would make cleaning things up really easy. If these aren't realistic solutions, I think producing course documentation describing for students how to manually share their work with teachers is probably the best bet. Any user can share a history with any other user or produce links and e-mail these to the teacher.
4. teachers sharing with students
I would look at having the teachers setup pages for individual courses or lesson plans. These can be made public and students would be able to import histories, datasets, and workflows right in from these. If more targeted sharing is needed again I think the best bet right now might just use Galaxy's history sharing capabilities.
Right now, I just have created users. There is no group or roles or permissions or datasets.
On another note, how can I disable the account of one specific user or a whole group ?
To enable this functionality for individual users and groups in the UI you need to set allow_user_deletion to True in universe_wsgi.ini. I don't think deleting a group will delete all the users in it though. This can be automated either by extending the API to support deleting users and then writing a script to iterate over a group and delete all the users or by writing a script that talks to the database directly or using scripts/db_shell.py (which provides an external script access to the Galaxy's data connection and model classes). Hope this helps, -John
Cordialement / Regards,
Edgar Fernandez
System Administrator (Linux)
Direction Générale des Technologies de l'Information et de la Communication
( Bur. : 1-514-343-6111 poste 16568
Université de Montréal
PAVILLON ROGER-GAUDRY, bureau X-218
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hello John, Thank you very much for your answer! It's sounds logical and do-able. However, I've thought of the following and I would like your opinion about it: (this is to create a workspace for each student which is accessible only by them and their teacher) 1. create a data library for each user (student, teacher and class) 2. the data library for each student will have the following permissions: a. modify library item = student private role (email address) b. access library = student private role (email address) and teacher private role c. add library item = student private role (email address) d. manage library permissions = student private role (email address) 3. the data library for each teacher will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) d. manage library permissions = teacher private role (email address) 4. the data library for each class will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) and all students privates roles d. manage library permissions = teacher private role (email address) Now, here's the one million dollar questions: Will the permission 4c permit to every student to drop some work into the class workspace but not cheap by seeing the work of another student ? Cordialement / Regards, Edgar Fernandez -----Message d'origine----- De : jmchilton@gmail.com [mailto:jmchilton@gmail.com] De la part de John Chilton Envoyé : January-15-14 12:12 PM À : Fernandez Edgar Cc : galaxy-dev@bx.psu.edu Objet : Re: [galaxy-dev] creating a hierarchy of students teachers and courses Galaxy can do some these and maybe not others. This is a really big topic, and I hope you let us all know how progress on this goes - it is a really interesting use case. I can comment a little on each part of this, but they are all connected and there are different ways to approach each of these things. On Tue, Jan 14, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca> wrote:
Hello galaxy team,
First and foremost, I would like to thank you for your assistance with my galaxy installation with apache proxy.
It works very well.
Secondly, I would like your help with creating users, groups, roles and permissions that would allow me to:
1. differentiate a student from a teacher
Are you creating these accounts inside of Galaxy or using an external authentication method? Because if your are creating these accounts yourself - I would suggest using naming scheme to distinguish these: std_cls_lastname teach_cls_lastname Another idea to consider is to make all teachers admins. This provides a lot of extra functionality that can cover some additional requirements below and can serve as the basis for differentiating.
2. differentiate a student in course A or in course B
You could use a naming scheme, or your could create a group and role for each course. It looks like there is an API for managing groups and roles. This can help automate some of this - it would be very laborious to do this through the UI I imagine.
3. teachers having read access to students' work
This one is why I would give the teachers admin access - I think they could impersonate the students to access their work (set allow_user_impersonation = True in universe_wsgi.ini). It would mean that every teacher would have full access to every students work - if this is a problem you might want to consider standing up a Galaxy instance per class - there is some up front overhead with this - but it would make cleaning things up really easy. If these aren't realistic solutions, I think producing course documentation describing for students how to manually share their work with teachers is probably the best bet. Any user can share a history with any other user or produce links and e-mail these to the teacher.
4. teachers sharing with students
I would look at having the teachers setup pages for individual courses or lesson plans. These can be made public and students would be able to import histories, datasets, and workflows right in from these. If more targeted sharing is needed again I think the best bet right now might just use Galaxy's history sharing capabilities.
Right now, I just have created users. There is no group or roles or permissions or datasets.
On another note, how can I disable the account of one specific user or a whole group ?
To enable this functionality for individual users and groups in the UI you need to set allow_user_deletion to True in universe_wsgi.ini. I don't think deleting a group will delete all the users in it though. This can be automated either by extending the API to support deleting users and then writing a script to iterate over a group and delete all the users or by writing a script that talks to the database directly or using scripts/db_shell.py (which provides an external script access to the Galaxy's data connection and model classes). Hope this helps, -John
Cordialement / Regards,
Edgar Fernandez
System Administrator (Linux)
Direction Générale des Technologies de l'Information et de la Communication
( Bur. : 1-514-343-6111 poste 16568
Université de Montréal
PAVILLON ROGER-GAUDRY, bureau X-218
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
On Wed, Jan 15, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca> wrote:
Hello John,
Thank you very much for your answer! It's sounds logical and do-able.
However, I've thought of the following and I would like your opinion about it: (this is to create a workspace for each student which is accessible only by them and their teacher) 1. create a data library for each user (student, teacher and class) 2. the data library for each student will have the following permissions: a. modify library item = student private role (email address) b. access library = student private role (email address) and teacher private role
Here is where this starts to break down. I think roles do not work the way most people I talk to about them find intuitive (myself included). When determining if action X can be performed on a library item - a user must belong to an intersection of all of the roles not a union of them. Put another way - each role is restricting the universe of people that can perform action X on an item not expanding it. So I am pretty sure Galaxy will not even let you specify this. The workaround is to create a new role for each student and teacher combination. This joint role would be the access role and all of the rest would be the student private role.
c. add library item = student private role (email address) d. manage library permissions = student private role (email address) 3. the data library for each teacher will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) d. manage library permissions = teacher private role (email address) 4. the data library for each class will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) and all students privates roles
I think add library item has to be a subset of access library. So I suspect this will not work (though feel free to try). A work around here might again be to create a new data library for each combination of student and teacher. This is obviously more overhead for the teacher though :(. -John
d. manage library permissions = teacher private role (email address)
Now, here's the one million dollar questions: Will the permission 4c permit to every student to drop some work into the class workspace but not cheap by seeing the work of another student ?
Cordialement / Regards, Edgar Fernandez
-----Message d'origine----- De : jmchilton@gmail.com [mailto:jmchilton@gmail.com] De la part de John Chilton Envoyé : January-15-14 12:12 PM À : Fernandez Edgar Cc : galaxy-dev@bx.psu.edu Objet : Re: [galaxy-dev] creating a hierarchy of students teachers and courses
Galaxy can do some these and maybe not others. This is a really big topic, and I hope you let us all know how progress on this goes - it is a really interesting use case. I can comment a little on each part of this, but they are all connected and there are different ways to approach each of these things.
On Tue, Jan 14, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca> wrote:
Hello galaxy team,
First and foremost, I would like to thank you for your assistance with my galaxy installation with apache proxy.
It works very well.
Secondly, I would like your help with creating users, groups, roles and permissions that would allow me to:
1. differentiate a student from a teacher
Are you creating these accounts inside of Galaxy or using an external authentication method?
Because if your are creating these accounts yourself - I would suggest using naming scheme to distinguish these:
std_cls_lastname teach_cls_lastname
Another idea to consider is to make all teachers admins. This provides a lot of extra functionality that can cover some additional requirements below and can serve as the basis for differentiating.
2. differentiate a student in course A or in course B
You could use a naming scheme, or your could create a group and role for each course. It looks like there is an API for managing groups and roles. This can help automate some of this - it would be very laborious to do this through the UI I imagine.
3. teachers having read access to students' work
This one is why I would give the teachers admin access - I think they could impersonate the students to access their work (set allow_user_impersonation = True in universe_wsgi.ini). It would mean that every teacher would have full access to every students work - if this is a problem you might want to consider standing up a Galaxy instance per class - there is some up front overhead with this - but it would make cleaning things up really easy.
If these aren't realistic solutions, I think producing course documentation describing for students how to manually share their work with teachers is probably the best bet. Any user can share a history with any other user or produce links and e-mail these to the teacher.
4. teachers sharing with students
I would look at having the teachers setup pages for individual courses or lesson plans. These can be made public and students would be able to import histories, datasets, and workflows right in from these. If more targeted sharing is needed again I think the best bet right now might just use Galaxy's history sharing capabilities.
Right now, I just have created users. There is no group or roles or permissions or datasets.
On another note, how can I disable the account of one specific user or a whole group ?
To enable this functionality for individual users and groups in the UI you need to set allow_user_deletion to True in universe_wsgi.ini. I don't think deleting a group will delete all the users in it though. This can be automated either by extending the API to support deleting users and then writing a script to iterate over a group and delete all the users or by writing a script that talks to the database directly or using scripts/db_shell.py (which provides an external script access to the Galaxy's data connection and model classes).
Hope this helps,
-John
Cordialement / Regards,
Edgar Fernandez
System Administrator (Linux)
Direction Générale des Technologies de l'Information et de la Communication
( Bur. : 1-514-343-6111 poste 16568
Université de Montréal
PAVILLON ROGER-GAUDRY, bureau X-218
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Would direct-sharing histories work as a significantly lighter weight solution? Each student could just create a history named "DannonBaker_SharedResults" or the like, share it directly with their instructor, and put via dataset copy and/or perform any work to be shared in that? -Dannon On Wed, Jan 15, 2014 at 11:21 PM, John Chilton <chilton@msi.umn.edu> wrote:
On Wed, Jan 15, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca> wrote:
Hello John,
Thank you very much for your answer! It's sounds logical and do-able.
However, I've thought of the following and I would like your opinion about it: (this is to create a workspace for each student which is accessible only by them and their teacher) 1. create a data library for each user (student, teacher and class) 2. the data library for each student will have the following permissions: a. modify library item = student private role (email address) b. access library = student private role (email address) and teacher private role
Here is where this starts to break down. I think roles do not work the way most people I talk to about them find intuitive (myself included). When determining if action X can be performed on a library item - a user must belong to an intersection of all of the roles not a union of them. Put another way - each role is restricting the universe of people that can perform action X on an item not expanding it.
So I am pretty sure Galaxy will not even let you specify this. The workaround is to create a new role for each student and teacher combination. This joint role would be the access role and all of the rest would be the student private role.
c. add library item = student private role (email
address)
d. manage library permissions = student private role (email
address)
3. the data library for each teacher will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) d. manage library permissions = teacher private role (email address) 4. the data library for each class will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) and all students privates roles
I think add library item has to be a subset of access library. So I suspect this will not work (though feel free to try).
A work around here might again be to create a new data library for each combination of student and teacher. This is obviously more overhead for the teacher though :(.
-John
d. manage library permissions = teacher private role (email
address)
Now, here's the one million dollar questions: Will the permission 4c permit to every student to drop some work into
the class workspace but not cheap by seeing the work of another student ?
Cordialement / Regards, Edgar Fernandez
-----Message d'origine----- De : jmchilton@gmail.com [mailto:jmchilton@gmail.com] De la part de
Envoyé : January-15-14 12:12 PM À : Fernandez Edgar Cc : galaxy-dev@bx.psu.edu Objet : Re: [galaxy-dev] creating a hierarchy of students teachers and courses
Galaxy can do some these and maybe not others. This is a really big topic, and I hope you let us all know how progress on this goes - it is a really interesting use case. I can comment a little on each part of this, but they are all connected and there are different ways to approach each of
John Chilton these things.
On Tue, Jan 14, 2014 at 12:03 PM, Fernandez Edgar <
Hello galaxy team,
First and foremost, I would like to thank you for your assistance with my galaxy installation with apache proxy.
It works very well.
Secondly, I would like your help with creating users, groups, roles and permissions that would allow me to:
1. differentiate a student from a teacher
Are you creating these accounts inside of Galaxy or using an external authentication method?
Because if your are creating these accounts yourself - I would suggest using naming scheme to distinguish these:
std_cls_lastname teach_cls_lastname
Another idea to consider is to make all teachers admins. This provides a lot of extra functionality that can cover some additional requirements below and can serve as the basis for differentiating.
2. differentiate a student in course A or in course B
You could use a naming scheme, or your could create a group and role for each course. It looks like there is an API for managing groups and roles. This can help automate some of this - it would be very laborious to do this
edgar.fernandez@umontreal.ca> wrote: through the UI I imagine.
3. teachers having read access to students' work
This one is why I would give the teachers admin access - I think they
could impersonate the students to access their work (set allow_user_impersonation = True in universe_wsgi.ini). It would mean that every teacher would have full access to every students work - if this is a problem you might want to consider standing up a Galaxy instance per class - there is some up front overhead with this - but it would make cleaning things up really easy.
If these aren't realistic solutions, I think producing course
documentation describing for students how to manually share their work with teachers is probably the best bet. Any user can share a history with any other user or produce links and e-mail these to the teacher.
4. teachers sharing with students
I would look at having the teachers setup pages for individual courses
or lesson plans. These can be made public and students would be able to import histories, datasets, and workflows right in from these. If more targeted sharing is needed again I think the best bet right now might just use Galaxy's history sharing capabilities.
Right now, I just have created users. There is no group or roles or permissions or datasets.
On another note, how can I disable the account of one specific user or a whole group ?
To enable this functionality for individual users and groups in the UI
This can be automated either by extending the API to support deleting users and then writing a script to iterate over a group and delete all the users or by writing a script that talks to the database directly or using
you need to set allow_user_deletion to True in universe_wsgi.ini. I don't think deleting a group will delete all the users in it though. scripts/db_shell.py (which provides an external script access to the Galaxy's data connection and model classes).
Hope this helps,
-John
Cordialement / Regards,
Edgar Fernandez
System Administrator (Linux)
Direction Générale des Technologies de l'Information et de la Communication
( Bur. : 1-514-343-6111 poste 16568
Université de Montréal
PAVILLON ROGER-GAUDRY, bureau X-218
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hello John,
Thank you very much for your answer! It's sounds logical and do-able.
However, I've thought of the following and I would like your opinion about it: (this is to create a workspace for each student which is accessible only by them and their teacher) 1. create a data library for each user (student, teacher and class) 2. the data library for each student will have the following permissions: a. modify library item = student private role (email address) b. access library = student private role (email address) and teacher private role Here is where this starts to break down. I think roles do not work the way most people I talk to about them find intuitive (myself included). When determining if action X can be performed on a library item - a user must belong to an intersection of all of the roles not a union of
Hello Dannon, You are right, I've just tried it and it is extremely lighter than my previous solution. I've successfully made a teacher share a complete history with her students and vice-versa a student sharing its history with teacher. Cordialement / Regards, Edgar Fernandez De : Dannon Baker [mailto:dannon.baker@gmail.com] Envoyé : January-16-14 8:24 AM À : John Chilton Cc : Fernandez Edgar; galaxy-dev@bx.psu.edu Objet : Re: [galaxy-dev] creating a hierarchy of students teachers and courses Would direct-sharing histories work as a significantly lighter weight solution? Each student could just create a history named "DannonBaker_SharedResults" or the like, share it directly with their instructor, and put via dataset copy and/or perform any work to be shared in that? -Dannon On Wed, Jan 15, 2014 at 11:21 PM, John Chilton <chilton@msi.umn.edu<mailto:chilton@msi.umn.edu>> wrote: On Wed, Jan 15, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca<mailto:edgar.fernandez@umontreal.ca>> wrote: them. Put another way - each role is restricting the universe of people that can perform action X on an item not expanding it. So I am pretty sure Galaxy will not even let you specify this. The workaround is to create a new role for each student and teacher combination. This joint role would be the access role and all of the rest would be the student private role.
c. add library item = student private role (email address) d. manage library permissions = student private role (email address) 3. the data library for each teacher will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) d. manage library permissions = teacher private role (email address) 4. the data library for each class will have the following permissions: a. modify library item = teacher private role (email address) b. access library = teacher private role (email address) c. add library item = teacher private role (email address) and all students privates roles
I think add library item has to be a subset of access library. So I suspect this will not work (though feel free to try). A work around here might again be to create a new data library for each combination of student and teacher. This is obviously more overhead for the teacher though :(. -John
d. manage library permissions = teacher private role (email address)
Now, here's the one million dollar questions: Will the permission 4c permit to every student to drop some work into the class workspace but not cheap by seeing the work of another student ?
Cordialement / Regards, Edgar Fernandez
-----Message d'origine----- De : jmchilton@gmail.com<mailto:jmchilton@gmail.com> [mailto:jmchilton@gmail.com<mailto:jmchilton@gmail.com>] De la part de John Chilton Envoyé : January-15-14 12:12 PM À : Fernandez Edgar Cc : galaxy-dev@bx.psu.edu<mailto:galaxy-dev@bx.psu.edu> Objet : Re: [galaxy-dev] creating a hierarchy of students teachers and courses
Galaxy can do some these and maybe not others. This is a really big topic, and I hope you let us all know how progress on this goes - it is a really interesting use case. I can comment a little on each part of this, but they are all connected and there are different ways to approach each of these things.
On Tue, Jan 14, 2014 at 12:03 PM, Fernandez Edgar <edgar.fernandez@umontreal.ca<mailto:edgar.fernandez@umontreal.ca>> wrote:
Hello galaxy team,
First and foremost, I would like to thank you for your assistance with my galaxy installation with apache proxy.
It works very well.
Secondly, I would like your help with creating users, groups, roles and permissions that would allow me to:
1. differentiate a student from a teacher
Are you creating these accounts inside of Galaxy or using an external authentication method?
Because if your are creating these accounts yourself - I would suggest using naming scheme to distinguish these:
std_cls_lastname teach_cls_lastname
Another idea to consider is to make all teachers admins. This provides a lot of extra functionality that can cover some additional requirements below and can serve as the basis for differentiating.
2. differentiate a student in course A or in course B
You could use a naming scheme, or your could create a group and role for each course. It looks like there is an API for managing groups and roles. This can help automate some of this - it would be very laborious to do this through the UI I imagine.
3. teachers having read access to students' work
This one is why I would give the teachers admin access - I think they could impersonate the students to access their work (set allow_user_impersonation = True in universe_wsgi.ini). It would mean that every teacher would have full access to every students work - if this is a problem you might want to consider standing up a Galaxy instance per class - there is some up front overhead with this - but it would make cleaning things up really easy.
If these aren't realistic solutions, I think producing course documentation describing for students how to manually share their work with teachers is probably the best bet. Any user can share a history with any other user or produce links and e-mail these to the teacher.
4. teachers sharing with students
I would look at having the teachers setup pages for individual courses or lesson plans. These can be made public and students would be able to import histories, datasets, and workflows right in from these. If more targeted sharing is needed again I think the best bet right now might just use Galaxy's history sharing capabilities.
Right now, I just have created users. There is no group or roles or permissions or datasets.
On another note, how can I disable the account of one specific user or a whole group ?
To enable this functionality for individual users and groups in the UI you need to set allow_user_deletion to True in universe_wsgi.ini. I don't think deleting a group will delete all the users in it though. This can be automated either by extending the API to support deleting users and then writing a script to iterate over a group and delete all the users or by writing a script that talks to the database directly or using scripts/db_shell.py (which provides an external script access to the Galaxy's data connection and model classes).
Hope this helps,
-John
Cordialement / Regards,
Edgar Fernandez
System Administrator (Linux)
Direction Générale des Technologies de l'Information et de la Communication
( Bur. : 1-514-343-6111<tel:1-514-343-6111> poste 16568
Université de Montréal
PAVILLON ROGER-GAUDRY, bureau X-218
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Hi I am sorry for hijacking someone else's thread:
3. teachers having read access to students’ work
This one is why I would give the teachers admin access - I think they could impersonate the students to access their work (set allow_user_impersonation = True in universe_wsgi.ini). It would mean that every teacher would have full access to every students work - if this is a problem you might want to consider standing up a Galaxy instance per class - there is some up front overhead with this - but it would make cleaning things up really easy.
"allow_user_impersonation" does not work when using external authentication. Are there any fixes for this in progress? If not shall I create a Trello card? Regards, Hans-Rudolf
On Thu, Jan 16, 2014 at 3:39 AM, Hans-Rudolf Hotz <hrh@fmi.ch> wrote:
"allow_user_impersonation" does not work when using external authentication. Are there any fixes for this in progress?
If not shall I create a Trello card?
If there's no Trello card for it, I doubt it's currently being worked on. And, of course, feel free! -Dannon
Card exists and it has 10 votes, that is the most I have seen in a while. https://trello.com/c/zwqNwflD I have added myself as a member to the card, I will see if I can find some time to work on this. -John On Thu, Jan 16, 2014 at 7:27 AM, Dannon Baker <dannon.baker@gmail.com> wrote:
On Thu, Jan 16, 2014 at 3:39 AM, Hans-Rudolf Hotz <hrh@fmi.ch> wrote:
"allow_user_impersonation" does not work when using external authentication. Are there any fixes for this in progress?
If not shall I create a Trello card?
If there's no Trello card for it, I doubt it's currently being worked on. And, of course, feel free!
-Dannon
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Imagine that, actually two cards for it! On Thu, Jan 16, 2014 at 8:33 AM, John Chilton <chilton@msi.umn.edu> wrote:
Card exists and it has 10 votes, that is the most I have seen in a while.
I have added myself as a member to the card, I will see if I can find some time to work on this.
-John
On Thu, Jan 16, 2014 at 7:27 AM, Dannon Baker <dannon.baker@gmail.com> wrote:
On Thu, Jan 16, 2014 at 3:39 AM, Hans-Rudolf Hotz <hrh@fmi.ch> wrote:
"allow_user_impersonation" does not work when using external authentication. Are there any fixes for this in progress?
If not shall I create a Trello card?
If there's no Trello card for it, I doubt it's currently being worked on. And, of course, feel free!
-Dannon
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
participants (4)
-
Dannon Baker -
Fernandez Edgar -
Hans-Rudolf Hotz -
John Chilton