allow filtering by bundle

HQ_Permissions adds chado-based deputies. The admin email config page, and the emails themselves, should take this into account and notify deputies. One way to address would be ot add a third checkbox for deputies to the config page. the other is to make deputies implied with the "admin" box.

I dont know why its looking for an uniquename column for the features table.

meg said she liked these...

artist credit: Jason Kang, Copyright 2010-2018 Blizzard Entertainment
https://www.deviantart.com/kangjason/art/Hearthstone-BlackHowl-Gunspire-738554497

oops, my bad. now when we submit a proposal, it just creates the entity :P

Noticed taht the bims module has a bims_user table that links user_id to "breeder" as well as contact.

Should we think about cross-compatibility or anything like that? (more for part B) than this module perhaps?

I think this is a drupal thing, but beware. Assigning the permission to the authenticated user role wont work.

This is because it doesnt get put in the user_role table.

See: https://drupal.stackexchange.com/questions/57444/authenticated-users-missing-from-users-roles-table

Error: Call to undefined function tripal_hq_permissions_process_submission() in tripal_hq_save_submission() (line 308 of /var/www/html/sites/all/modules/custom/custom/tripal_hq/includes/tripal_hq_user_data.form.inc).

when submitting content request. we need to either a) have hq DEPEND on hq_permissions so it gets enabled, or b) wrap the function in a check.

heres what im thinking.

Admin sets the tripal_hq_permission. Linking a user to a given record (im split if that should be a chado or entity id). So this would link admin A to project X.
A user submits a request to create analysis Y in project X. tripal_hq checks the permissions based on the project field, reads the rule in tripal_hq_permissions linking admin A to project X, and therefore assigns them to analysis Y in tripal_hq_submission_permissions.

longwinded/insane? maybe...

<?php

/**
 * Implements hook_schema.
 *
 * @return array
 */
function tripal_hq_permissions_schema() {

  $schema['tripal_hq_permissions'] = [
    'description' => 'Link users to specific chado records.  These are set by the site admin, and determine which submissions the admin listed here will be able to view.',
    'fields' => [
      'id' => [
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ],
      'uid' => [
        'description' => "Drupal user ID of admin.",
        'type' => 'int',
        'not null' => TRUE,
      ],
      'bundle_id' => [
        'description' => 'The bundle id. Foreign key to `tripal_bundle.id`.',
        'type' => 'int',
        'not null' => TRUE,
      ],
      'entity_id' => [
        'description' => 'the entity id.  Users admin permission based on this entity.',
        'type' => 'int',
        'not null' => TRUE,
      ],
    ],
    'primary key' => [
      'id',
    ],
  ];


  $schema['tripal_hq_submission_permissions'] = [
    'description' => 'Submissions that a given admin has admin rights to.',
    'fields' => [
      'id' => [
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ],
        'hq_permission_id' => [
          'type' => 'int',
          'not null' => TRUE,
          'description' => 'The tripal_hq_permission id.  This is the general Chado permission set which is responsible for this child permission.'
        ],
      'submission_id' => [
        'type' => 'int',
        'not null' => TRUE,
      ],

    ],
    'primary key' => [
      'id',
    ],
    'foreign keys' => [
      'submission_id' => [
        'table' => 'tripal_hq_submission',
        'columns' => [
          'submission_id' => 'id',
        ],
      ],
    ],
  ];

  return $schema;
}

/**
 * Uninstall the module.
 */
function tripal_hq_permissions_uninstall() {
  if (db_table_exists('tripal_hq_permissions')) {
    db_drop_table('tripal_hq_permissions');
  }
}

When editing a submission, a new submission is created rather than updating the old one. To fix we need make sure the form_state has the submission id hidden field.

It'd be nice if the admin could choose which fields are visible and editable to the end user.

see: tripal/tripal#703 (comment)

I'm pretty pumped. this works great. Admins just need to be careful not to hide widgets that are required for the field, and to remember to enable VIEWING the field for all users.

page is at /tripal_hq/admin_dash/.

For admins and content admins to approve/deny chado creation requests.

Currently

Improvements

• This page should perhaps be a view, so as to provide sorting, filtering, searching. However, I'm not sure how that would combine with advanced chado permissions we might implement.
• Summarize pending requests? (IE you have x pending requests to review...)
• Separate table for obsolete requests?
• Title should be either customizable by the site admin, or set based on site title? Or not be branded by module...

clicking submit redirects to:

http://localhost:8083/tripal_hq/admin/approve/1
which is not defined and not in the .module file. The status of the record is not updated to approved but is still pending afterwards.

users should be able to opt out of emails.

• Email can link to the opt out page

• by title
• by user (maybe?)
• by bundle

submit a request, then delete said request. it tries to delete the entity, but there is none.

Notice: Undefined property: TripalEntity::$id in tripal_entity_form_submit() (line 683 of /Users/bc/tripal/sites/all/modules/tripal/tripal/includes/TripalEntityUIController.inc).

epic issue for email events.

Needed events:

To user:

• Submission
• Approve message
• Deny message

To admin:

• Submission recieved for approval.

i was thinking maybe you coudl allow comments so that an uploader and an admin could go back and forth about changes?

my first thoguht was if it was a node we could enable that no problem. What do you think @almasaeed2010

We need a way for submitters to delete submissions.

tripal_hq_save_submission was given a type for the object (stdObj). but the passed object is TripalEntity.

From @mpoelchau

readme looks pretty good, only found a few typos: “HQ also provides a a Chado-specific permission” and “Select one or more organism for this user anda click “Submit”.”
It might be nice to add a figure to the description at the top that describes what it does
like user -> Genome analysis submission -> Admin/Deputy approval -> chado insertion
but that might be overkill

Each event has a user/admin email.

• submission

• edit

• accept

• reject

This may impact the IDE and reset it's settings after a pull so keep that in mind when pulling.

right now its pending only

abdullah requests refactoring the email calls into an api. would just require an event key and the $values array.

the relationship field validation returns a bunch of errors but we already submitted a pr to core to fix this: tripal/tripal#711

Once that's merged we can close this issue.

site-level admin configuration.

• Submission needs to get stored (in a table? drupal variable?)

• Default configuration on fresh install should be sane

Notice: Undefined index: chado-analysis_relationship__type_id in sbo__relationship_widget->validate() (line 368 of /Users/chet/UTK/tripal/sites/all/modules/tripal/tripal_chado/includes/TripalFields/sbo__relationship/sbo__relationship_widget.inc).

It's not just the relationship wiget though. Every field with cardinality appears to be create a new null record upon submission. I'm guessing this is because of the wonky way fields handle submissions--- ie we serialize a null value when the actual submission would unset the field.

see below image aftr i've submitted a bunch of edits.

if i submit an analysis and an organism, theres hould be a column in the dashboard that says which is which

• base organism field

• organism linker field

• base project field (does this exist?)

• project linker field (doesnt exist i dont think).

i ran into this problem again on teh i5k demo site. it created into chado until i cleared cache.

we should add this module to our showcase website (https://statonlab.github.io/hardwoods_tripal_showcase/)

if an admin becomes admin to project X, theyll be in charge of a new request for organism A in project X. great.

But what about current/pending requests when the new permission is set?

• we could check all existing pending records, reconstitute it via the serialzied array, and infer permissions.
• we could store the parent permission info on request creation. This seems a little wasteful because maybe no one even has the permission set up for organism, say...

splinter from #53

the approve/reject buttons really need to depend based on the case. So...
pending would have approve reject
approved would have.... nothing? just reject?
rejected would have ... nothing? just approve?
obsolete should have no button.

What happens when "all" selected? Buttons need to make sense when all the statuses are mixed together

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).

Looks like the submit function is not getting overridden after #29

it occurs ot me that we actually have 3 classes of email recipients.

Consider this event: user x submits a request, and admin v rejects it. What email should go out for the admin adn the user notices?

user x should get an email from the site y saying its rejected. but what about the admin email? Does it to the admins z & v, or the site, or both? Do we need to add a third box to the email config form for "site admin" and clarify that admin emails are for users with hq_admin permissions? (think down the road when we implement chado-specific permissions. we'll email just the organism X people about submissions)

  $user_email = 'x';
  $site_email = variable_get('site_mail');
  $relevant_admins = ['z', 'v'];

  $submission = tripal_hq_get_submission_by_id($sid);

  if ($op === 'reject') {
    $rejected = tripal_hq_reject_submission($submission);
    if ($rejected) {


      //From site, to end user
      drupal_mail('tripal_hq', 'user_reject_notice', $user_email, language_default(), $values, $site_email, TRUE);
      //from site to site_admin
      drupal_mail('tripal_hq', 'admin_reject_notice', $relevant_admins, language_default(), $values, $site_email, TRUE);

      drupal_set_message('Submission rejected successfully');
      drupal_goto('tripal_hq/admin');
    }
    else {
      drupal_set_message('Unable to reject submission', 'error');
    }

    return;
  }

Name: tripal_hq_submissions

fields

uid, type (edit/credit), status (approve, deny, pending), date created (maybe?), data (serialized array), entity_id (for linking to approved, or preexisting record for edits)

The site administrator will want to determine which bundles are open to users to propose records for.

• On install, we can check all bundles defined and create permissions for each. (administer and propose)
• if a new bundle is defined, can we hook into that event and create a permission for it?

suggesting an organism, as an admin

Notice: Undefined property: TripalEntity::$id in tripal_replace_entity_tokens() (line 1332 of /Users/bc/tripal/sites/all/modules/tripal/tripal/api/tripal.entities.api.inc).
Notice: Undefined property: TripalEntity::$id in tripal_replace_entity_tokens() (line 1334 of /Users/bc/tripal/sites/all/modules/tripal/tripal/api/tripal.entities.api.inc).
Notice: Trying to get property of non-object in taxrank__infraspecific_taxon->load() (line 183 of /Users/bc/tripal/sites/all/modules/tripal/tripal_chado/includes/TripalFields/taxrank__infraspecific_taxon/taxrank__infraspecific_taxon.inc).
Notice: Trying to get property of non-object in taxrank__infraspecific_taxon->load() (line 190 of /Users/bc/tripal/sites/all/modules/tripal/tripal_chado/includes/TripalFields/taxrank__infraspecific_taxon/taxrank__infraspecific_taxon.inc).
Notice: Undefined index: TAXRANK:0000045 in _tripal_replace_entity_tokens_for_elements() (line 1399 of /Users/bc/tripal/sites/all/modules/tripal/tripal/api/tripal.entities.api.inc).

COnfusing that there are also module-level settings.

Currently we attach everything and save an entity without triggering the save and postsave hooks which may be causing problems when we retrieve it back. What if instead we serialized and saved the form and form state rather than the entity. That way we save the entered values but we don't have to create about the final entity will look like until all the hooks are ready to be triggered.

To do this we simply need to add the serialized form and form_state to the data column and deal with retrieving it correctly.

 vendor/bin/tripaltest db:seed

In database.inc line 2227:

  SQLSTATE[42703]: Undefined column: 7 ERROR:  column "timestamp" of relation "tripal_hq_submission" does not exist
  LINE 1: ... public.tripal_hq_submission (uid, title, status, timestamp,...
                                                               ^


db:seed [<name>]

i would bet we updated teh schema but not the seeder

splinter of #26. Provide a base EDIT notify email. Uncomment that part of the admin form.