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
> 158 try:
> 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()
> 163 c.close
> 164 native_spec += ' -P ' + row
> 165 except:
> 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:
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: