chado-level admin permissions

[bradfordcondon]

Im looking at the admin area trying to figure out how we would do this.

Use case a)

An admin is in charge of organism record 42. A user submits an analysis creation request for this organism: we want it to show up in their dashboard.

Other chado use cases for content submissions that would be binned by organism:

• biomaterial.
• featuremap (genetic maps)(via featuremap_organism)
• breeding information --- stocks (has organism_id

use case b) .

The tripal apollo module lets users request access to apollo for specific organisms. The admin dashboard thats similar to HQ's wants to filter a given admin's records to just those relevant to their organism.

use case c)

Non organism-related control. I think the only (?) sane case i can think of is project.

So, how do we support this? how flexibly do we support this? in tripal_hq here is how we fetch content:

  $query = db_select('tripal_hq_submission', 't')
    ->extend('TableSort')
    ->orderByHeader($header)
    ->extend('PagerDefault');

  if ($status) {
    $query->condition('t.status', $status);
  }
  $requests = $query->fields('t')
    ->orderBy('id', 'desc')
    ->limit(10)
    ->execute()
    ->fetchAll();

So the idea would be to join this table somehow to just records that are valid for the given user's permissions.

Let's say that they were admin of organism 42. and lets say an analysis was submitted for organism 42. How would we find it?

If the record existed in chado----> we would join on the entity_id & bundle -> tripal_entity for base table -> chado_bio_data_x for record _id -> relevant column of linker or base table.

BUT, it doesnt! The data is stored as a serialized array!

When the user submits the request, it has to route it somehow. So when the hq_submission is created for an analysis, it looks up the relevant organism from the organism_analysis linker field, looks up relevant users for organism 42 in a theoretical table, and then stores this hq_submission_id in a seperate table for this user. But then this is less extensible for other modules: how can tripal_apollo take advantage of this, where we want to store in this case the apollo_user_record (a user requesting access to organism 42)? (Apollo is organized per organism so its less confusing, actually. It's these cases where the responsible party is found via chado relationship that are challenging me).

[bradfordcondon]

maybe we have a hq_request table. its keys are:

• base table- the the request is made in.
• key. the column/ of the request base table.
• user id. the admin user who has access to this request.

So that way in the above query, we join tripal_hq_submission with this hq_request table on the request ID where the user id = the current user.

I think this works in terms of being sane.

However, it doesnt address the question of how does this table get populated. I guess tripal_hq and tripal_apollo are in charge of populating it themselves, when the apollo request/hq submission is made. Which brings us back to.... how does it figure out WHO TO POPULATE IT WITH.

I feel like this solution is no easier than each module doing its own figuring it out on its own, eaxcept for this undefined way of figuring out how the proposed content is related to however the chado-specific permissions are set up.

[bradfordcondon]

ground work laid for this. closing.