Hey Ed, 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. --nate 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=?', [job_wrapper.user_id]) 162 row = c.fetchone() 163 c.close 164 native_spec += ' -P ' + row[0] 165 except: 166 log.debug("Cannot look up proj of user %s" % job_wrapper.user_id) 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: