Howdy devs,
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
# Why
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
For example:
<section execute="a@b.co,b@b.co" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="b@b.co" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools - if section level permissions are set, then those are set as defaults for all tools in that section - if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based on user - non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden. - Labels are not hidden at all. - workflows break completely if a tool is unavailable to a shared user and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
Tool names/id/version info can be found in the javascript object due to the call to app.toolbox.tool_panel.items() in templates/webapps/galaxy/workflow/editor.mako, as that returns the raw tool list, rather than one that's filtered on whether or not the user has access. I'm yet to figure out a clean fix for this. Additionally, empty sections are still shown even if there aren't tools listed in them.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of - new method in model.User to check if an array of roles overlaps at all with a user's roles - modifications to appropriate files for reading in the new tool_config.xml's options - modification to get_tool to pass user information, as whether or not a tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
# Fixes
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
+ https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools + (I saw some solution where they were adding "_beta" to tool names which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
Hi Eric, please also take a look at this mailing list thread:
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4...
If you are interested in the is_user_in_group solution, I have a slightly updated version which also uses roles instead of groups.
Nicola
Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:
Howdy devs,
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
# Why
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
For example:
<section execute="a@b.co,b@b.co" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="b@b.co" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools
- if section level permissions are set, then those are set as defaults
for all tools in that section
- if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based on user
- non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden.
- Labels are not hidden at all.
- workflows break completely if a tool is unavailable to a shared user
and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
Tool names/id/version info can be found in the javascript object due to the call to app.toolbox.tool_panel.items() in templates/webapps/galaxy/workflow/editor.mako, as that returns the raw tool list, rather than one that's filtered on whether or not the user has access. I'm yet to figure out a clean fix for this. Additionally, empty sections are still shown even if there aren't tools listed in them.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of
- new method in model.User to check if an array of roles overlaps at all
with a user's roles
- modifications to appropriate files for reading in the new
tool_config.xml's options
- modification to get_tool to pass user information, as whether or not a
tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
# Fixes
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
- https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools
- (I saw some solution where they were adding "_beta" to tool names
which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Nicola,
Oh, excellent. I must've skipped over that, given the strange title of the thread.
Your solution at the end of that thread is very promising, and certainly handles failure MUCH better than mine does (i.e. raising exceptions and not breaking a workflow if the user isn't permitted access.)
(Did you put it on the galaxy wiki anywhere? If it weren't for you linking that, I never would've known about it and that's very useful info!)
In my organisation's case; if a user isn't allowed access to a given tool, we believe that
- - galaxy has no reason to admit it exists - - galaxy should not share default information about a tool
Which is a bit different from the case of having a license to use a tool. For licensing issues, naturally it would be fine to say "yes this exists and if you can't run it, obtain a license".
For my org's case, we might want to store administrative tools (for other services) in galaxy. It's a very convenient platform for more than just bioinformatics and we have some non-technical people on staff who occasionally need to pull various data sets from various services/make database backups/etc. Students and clients who use our galaxy instance don't need to know that these tools are available.
Thoughts?
On 11/06/2013 12:12 PM, Nicola Soranzo wrote:
Hi Eric, please also take a look at this mailing list thread:
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4...
If you are interested in the is_user_in_group solution, I have a slightly updated version which also uses roles instead of groups.
Nicola
Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:
Howdy devs,
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
# Why
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
For example:
<section execute="a@b.co,b@b.co" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="b@b.co" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools
- if section level permissions are set, then those are set as defaults
for all tools in that section
- if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based on user
- non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden.
- Labels are not hidden at all.
- workflows break completely if a tool is unavailable to a shared user
and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
Tool names/id/version info can be found in the javascript object due to the call to app.toolbox.tool_panel.items() in templates/webapps/galaxy/workflow/editor.mako, as that returns the raw tool list, rather than one that's filtered on whether or not the user has access. I'm yet to figure out a clean fix for this. Additionally, empty sections are still shown even if there aren't tools listed in them.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of
- new method in model.User to check if an array of roles overlaps at all
with a user's roles
- modifications to appropriate files for reading in the new
tool_config.xml's options
- modification to get_tool to pass user information, as whether or not a
tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
# Fixes
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
- https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools
- (I saw some solution where they were adding "_beta" to tool names
which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
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/
- -- Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu rasche.eric@yandex.ru
Hi Eric! See my comments inline below.
Il 2013-11-06 19:56 Eric Rasche ha scritto:
Hi Nicola,
Oh, excellent. I must've skipped over that, given the strange title of the thread.
Your solution at the end of that thread is very promising, and certainly handles failure MUCH better than mine does (i.e. raising exceptions and not breaking a workflow if the user isn't permitted access.)
(Did you put it on the galaxy wiki anywhere? If it weren't for you linking that, I never would've known about it and that's very useful info!)
No, the original code is from John, so I blame him for not documenting it ;) Seriously, I can do that, maybe even create a pull request with the code, if there's enough interest.
In my organisation's case; if a user isn't allowed access to a given tool, we believe that
- galaxy has no reason to admit it exists
- galaxy should not share default information about a tool
Which is a bit different from the case of having a license to use a tool. For licensing issues, naturally it would be fine to say "yes this exists and if you can't run it, obtain a license".
For my org's case, we might want to store administrative tools (for other services) in galaxy. It's a very convenient platform for more than just bioinformatics and we have some non-technical people on staff who occasionally need to pull various data sets from various services/make database backups/etc. Students and clients who use our galaxy instance don't need to know that these tools are available.
Thoughts?
In his first reply in the mentioned thread, John explained also how to hide tools using tool filters. Here is his example code:
https://github.com/jmchilton/galaxy-central/commit/b500a24bc1aa94bef48db20a7...
In the mean time, tool filters has been enhanced with this pull request by Bjoern:
https://bitbucket.org/galaxy/galaxy-central/pull-request/179/implement-the-a...
I hope this is what you need.
Best, Nicola
On 11/06/2013 12:12 PM, Nicola Soranzo wrote:
Hi Eric, please also take a look at this mailing list thread:
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4...
If you are interested in the is_user_in_group solution, I have a slightly updated version which also uses roles instead of groups.
Nicola
Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:
Howdy devs,
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
# Why
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
For example:
<section execute="a@b.co,b@b.co" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="b@b.co" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools
- if section level permissions are set, then those are set as
defaults for all tools in that section
- if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based
on user
- non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden.
- Labels are not hidden at all.
- workflows break completely if a tool is unavailable to a shared
user and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
Tool names/id/version info can be found in the javascript object due to the call to app.toolbox.tool_panel.items() in templates/webapps/galaxy/workflow/editor.mako, as that returns the raw tool list, rather than one that's filtered on whether or not the user has access. I'm yet to figure out a clean fix for this. Additionally, empty sections are still shown even if there aren't tools listed in them.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of
- new method in model.User to check if an array of roles overlaps
at all with a user's roles
- modifications to appropriate files for reading in the new
tool_config.xml's options
- modification to get_tool to pass user information, as whether or
not a tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
# Fixes
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools
- (I saw some solution where they were adding "_beta" to tool names
which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
Thanks Eric, I'm sure this will be useful to many Galaxy admins!
I've edited a bit the wiki page, in particular I've updated the code to use roles instead of groups, which is more appropriate in the context of access control.
Best, Nicola
Il 2013-12-07 03:07 Rasche Eric ha scritto:
Hi Nicola, Just thought I'd write back since I added a Wiki page in Admin/Config [11] area for implementing access control. Thank you for sharing the snippets you posted in the email thread you linked me! http://wiki.galaxyproject.org/Admin/Config/Access%20Control [12] Cheers, Eric Rasche 06.11.2013, 18:57, "Eric Rasche" rasche.eric@yandex.ru:
Hi Nicola,
Oh, excellent. I must've skipped over that, given the strange title of the thread.
Your solution at the end of that thread is very promising, and certainly handles failure MUCH better than mine does (i.e. raising exceptions and not breaking a workflow if the user isn't permitted access.)
(Did you put it on the galaxy wiki anywhere? If it weren't for you linking that, I never would've known about it and that's very useful info!)
In my organisation's case; if a user isn't allowed access to a given tool, we believe that
- galaxy has no reason to admit it exists
- galaxy should not share default information about a tool
Which is a bit different from the case of having a license to use a tool. For licensing issues, naturally it would be fine to say "yes this exists and if you can't run it, obtain a license".
For my org's case, we might want to store administrative tools (for other services) in galaxy. It's a very convenient platform for more than just bioinformatics and we have some non-technical people on staff who occasionally need to pull various data sets from various services/make database backups/etc. Students and clients who use our galaxy instance don't need to know that these tools are available.
Thoughts?
On 11/06/2013 12:12 PM, Nicola Soranzo wrote:
Hi Eric, please also take a look at this mailing list thread:
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4...
[7]
If you are interested in the is_user_in_group solution, I have a slightly updated version which also uses roles instead of groups.
Nicola
Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:
Howdy devs,
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
# Why
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
For example:
<section execute="a@b.co [1],b@b.co [2]" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="b@b.co [3]" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools - if section level permissions are set, then those are set as defaults for all tools in that section - if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based on user - non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden. - Labels are not hidden at all. - workflows break completely if a tool is unavailable to a shared user and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
Tool names/id/version info can be found in the javascript object due to the call to app.toolbox.tool_panel.items() in templates/webapps/galaxy/workflow/editor.mako, as that returns the raw tool list, rather than one that's filtered on whether or not the user has access. I'm yet to figure out a clean fix for this. Additionally, empty sections are still shown even if there aren't tools listed in them.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of - new method in model.User to check if an array of roles overlaps at all with a user's roles - modifications to appropriate files for reading in the new tool_config.xml's options - modification to get_tool to pass user information, as whether or not a tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
# Fixes
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
+
https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools
[4] + (I saw some solution where they were adding "_beta" to tool names which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
___________________________________________________________ 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/ [5]
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ [6]
Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu [9] rasche.eric@yandex.ru [10]
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ [8]
iQIcBAEBAgAGBQJSepDzAAoJEMqDXdrsMcpVBjQP/2BEwrE/Ci16lZwikVOrb4xX I7EKtQ/u/w8xUbQBXHePq3lU3a3nQMaPwFTYT/wF31NVgXTQPoCedZcVBIJEadl+ W+WHT9PwJh2Bz/VRJLPygzG4c4MCfpaIYCus1Zc6inazeC5xNv2H19XCfv7Hfv8d LyYFArytnhCkwKUVY4m4juel9JE0VVTK7qvbkdSnNJnUxKggDA4MS2IxsnJBumjY s6PNhhVPGH32qw2YDIrQXz+LZDw74JGD/LyEr+LZlTHnVmiOohaJmaDSffGqPx8Z b8fKkhtAW/Dv6lGCD5z8sSQmiNsJKHekfZIHdhHwQCgmIfkLvf+FmkJJ0eS0shyx Q4HqmbGuCY1HlMVCK3jRSmew+juihDBgxWlujrfdqjmUZ9sQID63PSB2Gvrk8mX6 B3+yzuBQhhAfvS98pKj9baR280/m1FjgOn+MJInqHfnlowSx4HJ6azUHTregvvuF HSK5ON2HSu/B7DCXZi99AtYqG0LKl/E1kOSm/hO3v0vTqI5ZzDNh7AOW6c2Q51E9 2uRWkiUmJ30B76+WBjKFAd5iow6zJLijLK2uHMeYSYywEOiO4QClDGyRJw5fwDtk FmJaLTUt7mGQ3tD5Ox/3fZG5VXOOialpUGVHhexk2Kj6+0o2v+x7jj3oyiTiuh2B fdN1ECNiB/VOAj31xdgb =TQrm -----END PGP SIGNATURE-----
-- Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu [13] rasche.eric@yandex.ru [14]
Links:
[1] mailto:a@b.co [2] mailto:b@b.co [3] mailto:b@b.co [4] https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools [5] http://lists.bx.psu.edu/ [6] http://galaxyproject.org/search/mailinglists/ [7]
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4... [8] http://www.enigmail.net/ [9] mailto:esr@tamu.edu [10] mailto:rasche.eric@yandex.ru [11] http://wiki.galaxyproject.org/Admin/Config/ [12] http://wiki.galaxyproject.org/Admin/Config/Access%20Control [13] mailto:esr@tamu.edu [14] mailto:rasche.eric@yandex.ru
Hi Eric, I've updated again the Python code in the wiki page since the previous version was not correctly retrieving 'required_role' and 'final_destination' attributes for tools installed from a Tool Shed if you was using the short version of the tool ID in job_conf.xml .
Best, Nicola
Il 2013-12-09 12:38 Nicola Soranzo ha scritto:
Thanks Eric, I'm sure this will be useful to many Galaxy admins!
I've edited a bit the wiki page, in particular I've updated the code to use roles instead of groups, which is more appropriate in the context of access control.
Best, Nicola
Il 2013-12-07 03:07 Rasche Eric ha scritto:
Hi Nicola, Just thought I'd write back since I added a Wiki page in Admin/Config [11] area for implementing access control. Thank you for sharing the snippets you posted in the email thread you linked me! http://wiki.galaxyproject.org/Admin/Config/Access%20Control [12] Cheers, Eric Rasche 06.11.2013, 18:57, "Eric Rasche" rasche.eric@yandex.ru:
Hi Nicola,
Oh, excellent. I must've skipped over that, given the strange title of the thread.
Your solution at the end of that thread is very promising, and certainly handles failure MUCH better than mine does (i.e. raising exceptions and not breaking a workflow if the user isn't permitted access.)
(Did you put it on the galaxy wiki anywhere? If it weren't for you linking that, I never would've known about it and that's very useful info!)
In my organisation's case; if a user isn't allowed access to a given tool, we believe that
- galaxy has no reason to admit it exists
- galaxy should not share default information about a tool
Which is a bit different from the case of having a license to use a tool. For licensing issues, naturally it would be fine to say "yes this exists and if you can't run it, obtain a license".
For my org's case, we might want to store administrative tools (for other services) in galaxy. It's a very convenient platform for more than just bioinformatics and we have some non-technical people on staff who occasionally need to pull various data sets from various services/make database backups/etc. Students and clients who use our galaxy instance don't need to know that these tools are available.
Thoughts?
On 11/06/2013 12:12 PM, Nicola Soranzo wrote:
Hi Eric, please also take a look at this mailing list thread:
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4...
[7]
If you are interested in the is_user_in_group solution, I have a slightly updated version which also uses roles instead of groups.
Nicola
Il giorno mer, 06/11/2013 alle 11.38 -0600, Eric Rasche ha scritto:
Howdy devs,
I've implemented some rather basic tool access control and am looking for feedback on my implementation.
# Why
Our organisation wanted the ability to restrict tools to different users/roles. As such I've implemented as an "execute" tag which can be applied to either <section> or <tools> in the tool configuration file.
# Example galaxy-admin changes
For example:
<section execute="a@b.co [1],b@b.co [2]" id="EncodeTools" name="ENCODE Tools"> <tool file="encode/gencode_partition.xml" /> <tool execute="b@b.co [3]" file="encode/random_intervals.xml" /> </section>
which would allow A and B to access gencode_parition, but only B would be able to access random_intervals. To put it explicity
- by default, everyone can access all tools - if section level permissions are set, then those are set as defaults for all tools in that section - if tool permissions are set, they will override the defaults.
# Pros and Cons
There are some good features
- non-accessible tools won't show up in the left hand panel, based on user - non-accessible tools cannot be run or accessed.
There are some caveats however.
- existence of tools is not completely hidden. - Labels are not hidden at all. - workflows break completely if a tool is unavailable to a shared user and the user copies+edits. They can be copied, and viewed (says tool not found), but cannot be edited.
Tool names/id/version info can be found in the javascript object due to the call to app.toolbox.tool_panel.items() in templates/webapps/galaxy/workflow/editor.mako, as that returns the raw tool list, rather than one that's filtered on whether or not the user has access. I'm yet to figure out a clean fix for this. Additionally, empty sections are still shown even if there aren't tools listed in them.
For a brief overview of my changes, please see the attached diff. (It's missing one change because I wasn't being careful and started work on multiple different features)
# Changeset overview
In brief, most of the changes consist of - new method in model.User to check if an array of roles overlaps at all with a user's roles - modifications to appropriate files for reading in the new tool_config.xml's options - modification to get_tool to pass user information, as whether or not a tool exists is now dependent on who is asking.
Please let me know if you have input on this before I create a pull request on this feature.
# Fixes
I believe this will fix a number of previously brought up issues (at least to my understanding of the issues listed)
+
https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools
[4] + (I saw some solution where they were adding "_beta" to tool names which gave permissions to developers somewhere, but cannot find that now)
Cheers, Eric Rasche
___________________________________________________________ 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/ [5]
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ [6]
Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu [9] rasche.eric@yandex.ru [10]
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ [8]
iQIcBAEBAgAGBQJSepDzAAoJEMqDXdrsMcpVBjQP/2BEwrE/Ci16lZwikVOrb4xX I7EKtQ/u/w8xUbQBXHePq3lU3a3nQMaPwFTYT/wF31NVgXTQPoCedZcVBIJEadl+ W+WHT9PwJh2Bz/VRJLPygzG4c4MCfpaIYCus1Zc6inazeC5xNv2H19XCfv7Hfv8d LyYFArytnhCkwKUVY4m4juel9JE0VVTK7qvbkdSnNJnUxKggDA4MS2IxsnJBumjY s6PNhhVPGH32qw2YDIrQXz+LZDw74JGD/LyEr+LZlTHnVmiOohaJmaDSffGqPx8Z b8fKkhtAW/Dv6lGCD5z8sSQmiNsJKHekfZIHdhHwQCgmIfkLvf+FmkJJ0eS0shyx Q4HqmbGuCY1HlMVCK3jRSmew+juihDBgxWlujrfdqjmUZ9sQID63PSB2Gvrk8mX6 B3+yzuBQhhAfvS98pKj9baR280/m1FjgOn+MJInqHfnlowSx4HJ6azUHTregvvuF HSK5ON2HSu/B7DCXZi99AtYqG0LKl/E1kOSm/hO3v0vTqI5ZzDNh7AOW6c2Q51E9 2uRWkiUmJ30B76+WBjKFAd5iow6zJLijLK2uHMeYSYywEOiO4QClDGyRJw5fwDtk FmJaLTUt7mGQ3tD5Ox/3fZG5VXOOialpUGVHhexk2Kj6+0o2v+x7jj3oyiTiuh2B fdN1ECNiB/VOAj31xdgb =TQrm -----END PGP SIGNATURE-----
-- Eric Rasche Programmer II Center for Phage Technology Texas A&M University College Station, TX 77843 404-692-2048 esr@tamu.edu [13] rasche.eric@yandex.ru [14]
Links:
[1] mailto:a@b.co [2] mailto:b@b.co [3] mailto:b@b.co [4] https://trello.com/c/Zo7FAXlM/286-24-add-ability-to-password-secure-tools [5] http://lists.bx.psu.edu/ [6] http://galaxyproject.org/search/mailinglists/ [7]
http://dev.list.galaxyproject.org/pass-user-groups-to-dynamic-job-runner-td4... [8] http://www.enigmail.net/ [9] mailto:esr@tamu.edu [10] mailto:rasche.eric@yandex.ru [11] http://wiki.galaxyproject.org/Admin/Config/ [12] http://wiki.galaxyproject.org/Admin/Config/Access%20Control [13] mailto:esr@tamu.edu [14] mailto:rasche.eric@yandex.ru
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/
galaxy-dev@lists.galaxyproject.org
-
Eric Rasche -
Nicola Soranzo -
Rasche Eric