This is a neat approach. You could possibly also do this in the Galaxy database by
associating users and groups with roles that match project names. A select list or
history default that allowed users to select their "current" project/role would
remove the single-project-per-user limitation.
On Jan 13, 2012, at 3:17 PM, Edward Kirton wrote:
correction: i didn't adequately test what happens if the
user_proj_map_db was not defined in the universe file; here's the changes:
157 # BEGIN ADD USER'S PROJ
159 conn = sqlite3.connect(self.app.config.user_proj_map_db)
160 c = conn.cursor()
161 c.execute('SELECT PROJ FROM USER_PROJ WHERE GID=?',
162 row = c.fetchone()
164 native_spec += ' -P ' + row
166 log.debug("Cannot look up proj of user %s" %
167 # /END ADD USER PROJ
also, in the config, define a default instead of using None:
self.user_proj_map_db = resolve_path( kwargs.get( "user_proj_map_db",
"database/user_proj_map.sqlite" ), self.root )
one last note: there doesn't seem to be any error displayed to the user if the job
cannot be scheduled because the galaxy user doesn't have permissions to use the
user's project (although there is a log entry), but the job will never be scheduled.
so be sure the galaxy user has permissions to submit to all possible projects.
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: