Great idea, Nate (hint! hint!).
On Thu, Jan 19, 2012 at 10:27 AM, Nate Coraor <nate(a)bx.psu.edu> wrote:
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: