Skip to content

Commit 942aca1

Browse files
committed
Add basic documentation for admins
1 parent 68bccbe commit 942aca1

2 files changed

Lines changed: 103 additions & 0 deletions

File tree

doc/source/admin/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,7 @@ This documentation is in the midst of being ported and unified based on resource
2626
dependency_resolvers
2727
container_resolvers
2828
conda_faq
29+
user_defined_tools
2930
db_migration
3031
reports
3132
useful_scripts
Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
# User-Defined Tools (Beta)
2+
3+
Starting with Galaxy 25.0, users can create their own tools without requiring administrator privileges to install them. These tools are written in YAML, defined through the Galaxy user interface, and stored in the database.
4+
5+
## Differences from Standard Galaxy Tools
6+
7+
Standard Galaxy tools are written in XML and have broad access to the Galaxy database and filesystem during the command and configuration file templating phase, which uses the Cheetah templating language.
8+
9+
For example, the following XML tool command section queries the Galaxy database and writes a file to the home directory of the system user running the Galaxy process:
10+
11+
```xml
12+
<command><![CDATA[
13+
#from pathlib import Path
14+
#user_id = $__app__.model.session().query($__app__.model.User.id).one()
15+
#open(f"{Path.home()}/a_file", "w").write("Hello!")
16+
]]></command>
17+
```
18+
19+
This level of access is acceptable when only administrators install tools. However, allowing regular users to define and execute arbitrary tools requires stricter controls.
20+
21+
To address this, Galaxy now supports a restricted tool language for user-defined tools. This format is modeled after the XML tool definition but replaces Cheetah templating with sandboxed JavaScript expressions that do not have access to the database or filesystem.
22+
23+
Example: Concatenate Files Tool (YAML)
24+
```yaml
25+
class: GalaxyUserTool
26+
id: cat_user_defined
27+
version: "0.1"
28+
name: Concatenate Files
29+
description: tail-to-head
30+
container: busybox
31+
shell_command: |
32+
cat $(inputs.datasets.map((input) => input.path).join(' ')) > output.txt
33+
inputs:
34+
- name: datasets
35+
multiple: true
36+
type: data
37+
outputs:
38+
- name: output1
39+
type: data
40+
format_source: datasets
41+
from_work_dir: output.txt
42+
```
43+
44+
Equivalent Tool in XML:
45+
```xml
46+
<tool id="cat" version="0.1">
47+
<description>tail-to-head</description>
48+
<requirements>
49+
<requirement type="container">busybox</requirement>
50+
</requirements>
51+
<command><![CDATA[
52+
cat
53+
#for dataset in datasets:
54+
'$dataset'
55+
#end for
56+
> '$output1'
57+
]]></command>
58+
<inputs>
59+
<input name="datasets" format="data" type="data" multiple="true"/>
60+
</inputs>
61+
<outputs>
62+
<output name="output1" format_source="datasets" />
63+
</outputs>
64+
</tool>
65+
```
66+
67+
While the structure is similar, several key differences exist:
68+
69+
- The YAML version includes a required `class: GalaxyUserTool` line to signal the use of the restricted `UserToolSource` schema.
70+
- All user-defined tools must be executed inside a container, specified using the `container` key.
71+
- The command to be executed is defined under the `shell_command` key, using a string with embedded JavaScript expressions inside $(). In the example above, the expression iterates over the input dataset paths and joins them into a single command string.
72+
73+
## Enabling User-Defined Tools
74+
75+
To enable this feature:
76+
77+
1. Set `enable_beta_tool_formats: true` in your Galaxy configuration.
78+
2. Create a role of type `Custom Tool Execution` in the admin user interdace.
79+
3. Assign users or groups to this role.
80+
81+
## Sharing User-Defined Tools
82+
83+
User-defined tools are private to their creators. However, if a tool is embedded in a workflow, any user who imports that workflow will automatically have the tool created in their account.
84+
85+
These tools can also be exported to disk and loaded like regular tools, enabling instance-wide availability if needed.
86+
87+
## Security considerations
88+
89+
User-defined tools share the same security risks as interactive tools..
90+
See https://training.galaxyproject.org/training-material/topics/admin/tutorials/interactive-tools/tutorial.html#securing-interactive-tools for an extended discussion.
91+
While the feature is in beta we recommend that only trusted users are allowed to use this feature.
92+
93+
## Limitations
94+
95+
The user-defined tool language is still evolving, and additional safety audits are ongoing.
96+
97+
Current limitations include:
98+
99+
- [configfiles](https://docs.galaxyproject.org/en/master/dev/schema.html#tool-configfiles) are not supported
100+
- Access to reference data is not supported
101+
- Access to metadata and metadata files (such as BAM indexes) is not supported
102+
- Access to the `extra_files` directory is not supported

0 commit comments

Comments
 (0)