Merge branch '7.x-3.x' into 649-tv3-add_unpublish_functionality

.github/ISSUE_TEMPLATE/feature_request.md

@@ -12,11 +12,12 @@ INSTRUCTIONS: The following template is meant to structure your feature request.
   if it's decided the feature is not a good fit for Tripal Core.
 --->
 
-<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- Go over all the following points, and select the option in the brackets that applies to you. -->
 <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
-- [ ] does this feature attempt to solve an existing problem with Tripal?
-- [ ] are you open to developing or collaborating on an extension module if this is not a good fit for Tripal Core (no pressure here -just good to know upfront :-) )
-- [ ] do you **Need** this feature ASAP?
+* This feature [does / does not] attempt to solve an existing problem with Tripal
+* I [am/am not] open to developing or collaborating on an extension module if this is not a good fit for Tripal Core
+<!--- (no pressure here -just good to know upfront :-) ) -->
+* This feature is [URGENT/Not Urgent]
 
 ### Description
 <!--- A clear and concise description of what you want to happen. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,34 +1,31 @@
+<!--- Thank you for contributing! -->
 <!--- Provide a general summary of your changes in the Title above -->
 <!--- See our Contribution Guidelines here:
           https://github.com/tripal/tripal/blob/7.x-3.x/CONTRIBUTING.md -->
-          
-<!--- If it fixes an open issue, please add the issue link below. -->
-Issue #
 
-## Type(s) of Change(s)
-<!--- What types of changes does your code introduce? 
-         Put an `x` in all the boxes that apply: -->
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
-- [ ] API-specific change (fix or addition to an API function)
-- [ ] Updates documentation (inline or markdown files)
+
+<!---  Please set the header below based on the PR type:
+# New Feature
+# Bux Fix
+# Documentation  --->
+
+#
+
+Issue #
 
 ## Description
 <!--- Describe your changes in detail -->
 <!--- Why is this change required? What problem does it solve? -->
 
 ## Testing?
-<!--- Please describe in detail how you tested your changes. -->
-<!--- Include details of your testing environment, tests ran to see how -->
-<!--- your change affects other areas of the code, etc. -->
+<!--- Please describe in detail how to test these changes. -->
 <!--- Reviewers will use this section to test the submission! -->
+<!--- If you've implemented PHPUnit tests, you can describe the test cases here. -->
+<!--- Unit testing guidelines: https://github.com/tripal/tripal/blob/7.x-3.x/tests/README.md -->
 
 ## Screenshots (if appropriate):
 
 ## Additional Notes (if any):
-<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
-<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
-- [ ] My code follows the code style of this project.
-- [ ] My change requires a change to the documentation.
-- [ ] I have updated the documentation accordingly.
+
+<!--- New features should include in-line code documentation. -->
+<!--- Would a user or developer guide be helpful for this feature? -->

.travis.yml

@@ -12,7 +12,7 @@ php:
   - 7.1
 
 env:
-  - BASE_URL="http://localhost:8080"
+  - BASE_URL="http://127.0.0.1:8080"
 
 install:
   - composer global require drush/drush:8
@@ -31,6 +31,8 @@ before_script:
   - drush dl drupal-7 -y
   - mv drupal-7* drupal
   - cd drupal
+  # Run the php server
+  - php -S 127.0.0.1:8080 &
   - drush si -y --db-url='pgsql://postgres:dbpass@localhost:5432/test_db'
                 --account-name='admin'
                 --account-pass='admin_pass'
@@ -45,9 +47,6 @@ before_script:
   - drush en -y field_group, field_group_table, field_formatter_class, field_formatter_settings, ctools, date, devel,
               ds, link, entity, libraries, redirect, token uuid, jquery_update, views, webform
 
-  # Run the drush server
-  - drush runserver localhost:8080 &
-
 script:
   # Link our repo to the modules directory
   - mv ../tripal sites/all/modules/tripal
@@ -73,6 +72,7 @@ script:
 
   # Run PHPUnit tests
   - composer update
+  - cp tests/.travis.env tests/.env
   - ./vendor/bin/phpunit
 
   # Test Tripal v2 to v3 upgrade steps

CONTRIBUTING.md

@@ -1,126 +1 @@
-# Guidelines for Contribution to Tripal
-
-The following guidelines are meant to encourage contribution to Tripal source-code on GitHub by making the process open, transparent and collaborative. If you have any feedback including suggestions for improvement or constructive criticism, please [comment on the github issue](https://github.com/tripal/tripal/issues/344). **These guidelines apply to everyone contributing to Tripal whether it's your first time (Welcome!) or project management committee members.**
-
-**Note:** _These guidelines are specifically for contributing to_ [_https://github.com/tripal/tripal_](https://github.com/tripal/tripal)_. However, we encourage all Tripal extension modules to consider following these guidelines to foster collaboration among the greater Tripal Community._
-
-Guidelines serve as suggestions ( **should** ) or requirements (**must).** _When the word "should" is used in the text below, the stated policy is expected but there may be minor exceptions.  When the word "must" is used there are no exceptions to the stated policy._
-
-## Github Communication Tips
-
-- Don't be afraid to mention people (@username) who are knowledgeable on the topic or invested.*- We are academics and overcommitted, it's too easy for issues to go unanswered.
-  - Likewise, don't be shy about bumping an issue if no one responds after a few days.  Balancing responsibilities is hard.
-- Want to get more involved? Issues marked with "Good beginner issue" are a good place to start if you want to try your hand at submitting a PR.
-- Everyone is encouraged/welcome to comment on the issue queue!** Tell us if you
-    - are experiencing the same problem
-    - have tried a suggested fix
-    - know of a potential solution or work-around
-    - have an opinion, idea or feedback of any kind!
-- Be kind when interacting with others on github!** (see Code of Conduct below for further guidelines). We want to foster a welcoming, inclusive community!
-    - Constructive criticism is welcome and encouraged but should be worded such that it is helpful :-) Direct criticism towards the idea or solution rather than the person and focus on alternatives or improvements.
-
-## Bugs
-
-- Every bug **should** be reported as a github issue.
-  - Even if a bug is found by a committer who intends to fix it themselves immediately, they **should** create an issue and assign it to themselves to show their intent.
-- Please follow the issue templates as best you can.  This information makes discussion easier and helps us resolve the problem faster.
-  - Also provide as much information as possible :-)  Screenshots or links to the issue on a development site can go a long way!
-- Bonus points for unit tests to ensure the bug does not return :-)
-
-## Feature Requests
-
-- Every feature request should start as an issue so that discussion is encouraged :-)**
-- Please provide the following information (bold is required; underlined strengthens your argument):
-    - **Use Case:** fully describe why you need/want this feature
-    - Generally Applicable: Why do you feel this is generally applicable? Suggest other use cases if possible. Mention (@) others that might want/need this feature.
-    - Implementation: Describe a possible implementation. Bonus points for configuration, use of ontologies, ease of use, permission control, security considerations
-- All features **should** be optional so that Tripal admin can choose to make it available to their users.
-    - When applicable, new features should be designed such that tripal-site admin can disable them.
-    - Bonus points: for making new features configurable and easily themed.
-- Feature requests will be voted on by the project management and advisory/steering committees to determine if it should be included in core, an existing extension module or it's own extension module.
-    - Votes should be based on whether this feature is generally applicable and doesn't exclude existing users and not be biased by the needs of your own Tripal site.
-- If a feature isn't suitable for inclusion within Tripal core, use the issue discussion as a springboard to create a Tripal extension module!
-
-**Note:** _In the future there will be a set of guidelines for what should be included in core. This will make the process of requesting new features more streamlined, inclusive and transparent._
-
-## Pull Request (PR) Guideline
-
-The goal of this document is to make it easy for **A)** contributors to make pull requests that will be accepted, and **B)** Tripal committers to determine if a pull request should be accepted.
-
-- PRs that address a specific issue **must** link to the related issue page.
-  - Really in almost every case, there should be an issue for a PR.  This allows feedback and discussion before the coding happens.  Not grounds to reject, but encourage users to create issues at start of their PR.  Better late than never :).
-- Each PR **must** be tested/approved by at least 2 users with at least one user being a "trusted committer."
-  - Testers **should** describe how the testing was performed if applicable (allows others to replicate the test).
-  - Tripal's guiding philosophy is to encourage open contribution.  With this in mind, committers should **work with contributors** to resolve issues in their PRs.  PRs that will not be merged should be closed, **transparently citing** the reason for closure.  In an ideal world, features that would be closed are discouraged at the **issue phase** before the code is written!
-  - The pull request branch should be deleted after merging (if not from a forked repository) by the person who performs the merge.
-- PRs that include new functionality **must** also provide Unit Tests.
-  - Tests **must** test the new functionality added.
-  - Bonus points for testing all surrounding functionality.
-    - _Note: testing surrounding functionality is highly encouraged if the submitter is on the PMC ;-)_
-  - For example, when adding feature X to custom tables, the PR must include tests for feature X and we would be greatly appreciative if it included tests for custom tables in general :-D.
-- PRs **should** pass all Travis-CI tests before they are merged.
-- Branches **should** follow the following format:
-    - [issue\_number]-[tripal\_version]-[short\_description]
-  - tripal\_version being Tv2, Tv3, etc.
-  - "-[short\_description]" being optional but highly encouraged
-- **Must** follow Drupal code standards: [https://www.drupal.org/docs/develop/standards](https://www.drupal.org/docs/develop/standards)
-- PRs for new feature should remain open until adequately discussed (see guidelines below) and approved by a vote (all members of the PMC must vote in favour).
-
-**Note:** _See the Tripal PR Tutorial for more guidance on how to actually create a PR if contribution via github is new to you (_ [_KnowPulse workflow for inspiration_](https://github.com/UofS-Pulse-Binfo/KnowPulse/blob/master/Workflow.md)_)_
-
-## General Project Management
-
-- **Every task related to Tripal should be in github, either as it's own issue or grouped with like tasks into a single issue.** This effectively puts our todo list on github making it transparent to anyone who wants to help. It has the benefit of showing how active our community is, keeps everyone informed with where Tripal is headed and makes it easy for others to chime in with experience, comments and support.
-- **Guidelines for Tagging Issues:**
-    - The first committer who comments on an issue should tag it with the version of Tripal it applies to.
-    - Issues with a suggested fix or work-around should be tagged with "Fix Required" to let others know a PR is needed.
-    - Only tag an issue with "bug" once it has been shown to be reproducible. If it's not reproducible by a committer but you feel it is a bug then tag it as "potential bug".
-    - If multiple users have commented that a bug affects them, tag it as "affects multiple users".
-    - Issues that require a PR and someone with relatively little Tripal experience could fix should be tagged with "Good beginner issue"
-    - All feature requests should be tagged as an "enhancement"
-    - If you are the first reviewer to confirm a PR works, tag it with "Reviewer #1 Approval"
-- **Guidelines for Discussion:**
-    - No requirement for discussion (still requires 2 reviews): Minor bug fixes, changes to inline comments, addition of unit tests, minor code typos
-    - Requires Discussion: Major changes, new features, and issue at the discretion of the PMC
-      - Add the "discussion" tag to any issue requiring discussion
-      - Discussion Tag is removed when adequate discussion has taken place (at the discretion of the person who added the tag)
-      - Additionally, new features require that all members of the PMC have had a chance to contribute to the discussion and feel satisfied.
-- Please use the **assignment** feature to clarify who will be contributing the code to prevent duplication of effort.
-    - When assigning yourself, comment on what your timeline is. This allows others to jump in if they have time sooner.
-    - If you would like to **take over a PR assigned to someone else** , comment asking for an update and offer your services.
-    - If the author of the issue plans on contributing the fix themselves but is not a committer, they should indicate that in the issue.  A committer will assign them the issue.
-- When you start working on an issue, you **should** create the branch and push to it regularly. If you are working on a fork, you're **encouraged** to link to it in the issue.
-    - Committers can work on a fork or directly.  If the branch is on tripal/tripal, then other committers should contribute via PR unless otherwise agreed
-- If an issue is identified as being relevant to another repository (ie a tripal module, not core), a new issue **should** be created, cross referenced, and the original issue should be closed encouraging discussion in the module.
-
-## Code of Conduct
-
-- Be nice!  If that's insufficient, Tripal community defers to https://www.contributor-covenant.org/
-
-## Testing/CI
-
-Exhaustive guides to testing are available at tripal.info (here for now: [https://www.bradfordcondon.com/2018/05/02/tripal\_testing\_guidelines/](https://www.bradfordcondon.com/2018/05/02/tripal_testing_guidelines/)).  Below are guiding principles.
-
-- All tests pass.
-- Tests don't modify db: use transactions and factories.
-- Tests are organized properly: by submodule and function.
-- Tests run quietly.
-
-## Changes to this Document
-
-These guidelines are binding to the Tripal Community. If you have comments, suggestions or constructive criticism please bring it up in a [comment on the github issue](https://github.com/tripal/tripal/issues/344). Changes to this document will be made after adequate discussion has occurred and the project management committee has voted in favour of the change.
-
-# Tripal Governance
-
-The above document makes us a sort of hybrid between a [meritocracy and liberal contribution model](https://opensource.guide/leadership-and-governance/#what-are-some-of-the-common-governance-structures-for-open-source-projects).
-
-
-The Tripal project recognizes these roles:
-
-- Users - They have downloaded Tripal!  Maybe they even have a site!
-- Contributors - contributing!  Code, comments, discussion, questions, bug reports.
-- Committers - write access to the repository
-- PMC - Makes **code relevant** decisions.
-- Oversight committee - Makes **policy leve** decisions.  This may overlap with PMC, but the idea is the oversight committee includes parties who are **not necessarily coders** and therefore not reviewing Pull requests etc.
-
-More guidelines coming soon.
+Please see the [Tripal online documentation](https://tripal.readthedocs.io/en/latest/dev_guide/contributing.html) for more information about contributing to Tripal and Tripal governance.

README.md

@@ -57,51 +57,11 @@ are available in Tripal v3.
 
 
 # Installation
-Please follow the instructions in the online Tripal User's Guide for [Tripal v2](https://tripal.info/tutorials/v2.x/installation) or [Tripal v3](https://tripal.info/tutorials/v3.x/installation).
+Please follow the instructions in the online Tripal User's Guide for [Tripal v2](https://tripal.info/tutorials/v2.x/installation) or [Tripal v3](https://tripal.readthedocs.io/en/latest/user_guide.html).
 
 
 # Upgrade from Tripal v2.x to v3.x
-Note:  Upgrade can only be performed using the `drush` command.
-
-Note: Deprecated API functions from Tripal v1.x have been removed from Tripal
-v3.  Therefore, use of deprecated API functions in templates or custom 
-modules may cause a white screen of death (WSOD).  Check teh server logs if this
-occurs to find where deprecated functions may be used.
-
-Upgrade Instructions:
-
-Step 1: Put the site in maintenance mode.
-
-Step 2: Disable tripal modules. Disabling the core module will disable all
-other Tripal modules:
-
-  `drush pm-disable tripal_core`
-  
-Step 3: Remove old Tripal v2 package and replace with Tripal v3 package
-Step 4: Enable the tripal module
-
-  `drush pm-enable tripal`
- 
-Step 5: Enable the tripal_chado module  
-
-  `drush pm-enable tripal_chado`
-  
-Step 6:  Tripal v2 modules are now called 'legacy modules'. these are the
-modules that were disabled in step #2.  For backwards compatibility, you 
-should re-enable these modules:
-
-```
-  drush pm-enable tripal_core, tripal_views, tripal_db, tripal_cv, \
-    tripal_analysis, tripal_organism, tripal_feature, tripal_pub, \
-    tripal_stock
-```
-
-
-Be sure to enable any additional modules not included in the example
-drush command above.
-
-Step 7:  Return to your Tripal site, and click the link that appears for
-preparing Chado and launch the job.
+Please follow the [Upgrade Instructions](https://tripal.readthedocs.io/en/latest/user_guide/install_tripal/upgrade_from_tripal2.html) in the Tripal v3 User's Guide
 
 
 # Customization

docs/README.md

@@ -0,0 +1 @@
+Please see the [Tripal online documentation](https://tripal.readthedocs.io/en/latest/dev_guide/contributing.html) for contribution instructions.

docs/dev_guide.rst

@@ -9,8 +9,11 @@ Developer's Guide
    dev_guide/introduction
    dev_guide/data_structures
    dev_guide/best_practices
+   dev_guide/chado
    dev_guide/custom_modules
    dev_guide/custom_field
+   dev_guide/exporting_field_settings
    dev_guide/custom_data_loader
    dev_guide/custom_web_services
+   dev_guide/contributing
    dev_guide/tutorials

docs/dev_guide/chado.rst

@@ -0,0 +1,296 @@
+Accessing Chado
+================
+
+Primarily biological data made available to Tripal is stored in the GMOD Chado
+schema. As such, you will likely need to interact with Chado at some point.
+Tripal has developed a number of API functions and classes to make this
+interaction easier and more generic.
+
+The Chado Query API
+--------------------
+
+Provides an API for querying of chado including inserting, updating, deleting and selecting from specific chado tables. There is also a generic function, ``chado_query()``, to execute and SQL statement on chado. It is ideal to use these functions to interact with chado in order to keep your module compatible with both local & external chado databases. Furthermore, it ensures connection to the chado database is taken care of for you.
+
+Generic Queries to a specifc chado table
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Selecting Records
+""""""""""""""""""
+
+``chado_select_record( [table name], [columns to select], [specify record to select], [options*] )``
+
+This function allows you to select various columns from the specified chado table. Although you can only select from a single table, you can specify the record to select using values from related tables through use of a nested array. For example, the following code shows you how to select the name and uniquename of a feature based on it's type and source organism.
+
+.. code-block:: php
+
+  $values =  array(
+    'organism_id' => array(
+      'genus' => 'Citrus',
+      'species' => 'sinensis',
+    ),
+    'type_id' => array (
+      'cv_id' => array (
+        'name' => 'sequence',
+      ),
+      'name' => 'gene',
+      'is_obsolete' => 0
+    ),
+  );
+
+  $result = chado_select_record(
+    'feature',                      // table to select from
+    array('name', 'uniquename'),    // columns to select
+    $values                         // record to select (see variable defn. above)
+  );
+
+Inserting Records
+""""""""""""""""""
+
+``chado_insert_record( [table name], [values to insert], [options*] )``
+
+This function allows you to insert a single record into a specific table. The values to insert are specified using an associative array where the keys are the column names to insert into and they point to the value to be inserted into that column. If the column is a foreign key, the key will point to an array specifying the record in the foreign table and then the primary key of that record will be inserted in the column. For example, the following code will insert a feature and for the type_id, the cvterm.cvterm_id of the cvterm record will be inserted and for the organism_id, the organism.organism_id of the organism_record will be inserted.
+
+.. code-block:: php
+
+  $values =  array(
+    'organism_id' => array(
+        'genus' => 'Citrus',
+        'species' => 'sinensis',
+     ),
+    'name' => 'orange1.1g000034m.g',
+    'uniquename' => 'orange1.1g000034m.g',
+    'type_id' => array (
+        'cv_id' => array (
+           'name' => 'sequence',
+        ),
+        'name' => 'gene',
+        'is_obsolete' => 0
+     ),
+  );
+  $result = chado_insert_record(
+    'feature',             // table to insert into
+    $values                // values to insert
+  );
+
+Updating Records
+""""""""""""""""""
+
+``chado_update_record( [table name], [specify record to update], [values to change], [options*] )``
+
+This function allows you to update records in a specific chado table. The record(s) you wish to update are specified the same as in the select function above and the values to be update are specified the same as the values to be inserted were. For example, the following code species that a feature with a given uniquename, organism_id, and type_id (the unique constraint for the feature table) will be updated with a new name, and the type changed from a gene to an mRNA.
+
+.. code-block:: php
+
+  $umatch = array(
+    'organism_id' => array(
+      'genus' => 'Citrus',
+      'species' => 'sinensis',
+    ),
+    'uniquename' => 'orange1.1g000034m.g7',
+    'type_id' => array (
+      'cv_id' => array (
+        'name' => 'sequence',
+      ),
+      'name' => 'gene',
+      'is_obsolete' => 0
+    ),
+  );
+  $uvalues = array(
+    'name' => 'orange1.1g000034m.g',
+    'type_id' => array (
+      'cv_id' => array (
+        'name' => 'sequence',
+      ),
+      'name' => 'mRNA',
+      'is_obsolete' => 0
+    ),
+  );
+  $result = chado_update_record('feature',$umatch,$uvalues);
+
+Deleting Records
+"""""""""""""""""
+
+``chado_delete_record( [table name], [specify records to delete], [options*] )``
+
+This function allows you to delete records from a specific chado table. The record(s) to delete are specified the same as the record to select/update was above. For example, the following code will delete all genes from the organism Citrus sinensis.
+
+.. code-block:: php
+
+  $values =  array(
+    'organism_id' => array(
+        'genus' => 'Citrus',
+        'species' => 'sinensis',
+     ),
+    'type_id' => array (
+        'cv_id' => array (
+           'name' => 'sequence',
+        ),
+        'name' => 'gene',
+        'is_obsolete' => 0
+     ),
+  );
+  $result = chado_select_record(
+     'feature',                      // table to select from
+     $values                         // records to delete (see variable defn. above)
+  );
+
+Generic Queries for any SQL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Often it is necessary to select from more then one table in chado or to execute other complex queries that cannot be handled efficiently by the above functions. It is for this reason that the ``chado_query( [sql string], [arguments to sub-in to the sql] )`` function was created. This function allows you to execute any SQL directly on the chado database and should be used with care. If any user input will be used in the query make sure to put a placeholder in your SQL string and then define the value in the arguments array. This will make sure that the user input is sanitized and safe through type-checking and escaping. The following code shows an example of how to use user input resulting from a form and would be called with the form submit function.
+
+.. code-block:: php
+
+  $sql = "SELECT F.name, CVT.name as type_name, ORG.common_name
+           FROM feature F
+           LEFT JOIN cvterm CVT ON F.type_id = CVT.cvterm_id
+           LEFT JOIN organism ORG ON F.organism_id = ORG.organism_id
+           WHERE
+             F.uniquename = :feature_uniquename";
+  $args = array( ':feature_uniquename' => $form_state['values']['uniquename'] );
+  $result = chado_query( $sql, $args );
+  foreach ($result as $r) { [Do something with the records here] }
+
+If you are going to need more then a couple fields, you might want to use the Chado Variables API (specifically ``chado_generate_var()``) to select all of the common fields needed including following foreign keys.
+
+Loading of Variables from chado data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These functions, ``chado_generate_var()`` and ``chado_expand_var()``, generate objects containing the full details of a record(s) in chado. These should be used in all theme templates.
+
+This differs from the objects returned by ``chado_select_record`` in so far as all foreign key relationships have been followed meaning you have more complete details. Thus this function should be used whenever you need a full variable and ``chado_select_record`` should be used if you only case about a few columns.
+
+The initial variable is generated by the ``chado_generate_var([table], [filter criteria], [optional options])`` function. An example of how to use this function is:
+
+.. code-block:: php
+
+  $values = array(
+    'name' => 'Medtr4g030710'
+  );
+  $features = chado_generate_var('feature', $values);
+
+This will return an object if there is only one feature with the name Medtr4g030710 or it will return an array of feature objects if more than one feature has that name.
+
+Some tables and fields are excluded by default. To have those tables & fields added to your variable you can use the ``chado_expand_var([chado variable], [type], [what to expand], [optional options])`` function. An example of how to use this function is:
+
+.. code-block:: php
+
+  // Get a chado object to be expanded
+  $values = array(
+    'name' => 'Medtr4g030710'
+  );
+
+  $features = chado_generate_var('feature', $values);
+
+  // Expand the organism node
+  $feature = chado_expand_var($feature, 'node', 'organism');
+
+  // Expand the feature.residues field
+  $feature = chado_expand_var($feature, 'field', 'feature.residues');
+
+  // Expand the feature properties (featureprop table)
+  $feature = chado_expand_var($feature, 'table', 'featureprop');
+
+
+The Chado Schema API
+--------------------
+
+The Chado Schema API provides an application programming interface (API) for describing Chado tables, accessing these descriptions and checking for compliancy of your current database to the chado schema. This API consists of the ChadoSchema class which provides methods for interacting with the Chado Schema API and a collection of supporting functions, one for each table in Chado, which describe each version of the Chado schema. Each function simply returns a Drupal style array that defines the table.
+
+Ensuring columns Tables & Columns exist
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Generally you can assume the tables and columns in the Chado schema have been unaltered. That said, there are still cases where you might want to check that specific tables and columns exist. For example, when using a custom table, it is best practice to ensure it is there before querying as it can be removed through the administrative interface.
+
+To check the existence of a specific table and column, you can use the following:
+
+.. code-block:: php
+
+  $chado_schema = new \ChadoSchema();
+
+  // Check that the organism_feature_count custom table exists.
+  $table_name = 'organism_feature_count';
+  $table_exists = $chado_schema->checkTableExists($table_name);
+
+  if ($table_exists) {
+
+    // Check that the organism_feature_count.feature_id column exists.
+    $column_name = 'feature_id';
+    $column_exists = $chado_schema->checkColumnExists($table_name, $column_name);
+
+    if ($column_exists) {
+
+      [ do your query, etc. here ]
+
+    } else { [warn the admin using tripal_repot_error()] }
+  } else { [warn the admin using tripal_repot_error()] }
+
+Checking the Schema Version
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you are using chado tables specific to a given version of Chado, it is best practice to check the chado version of the current site before querying those tables. You can use the following query to do this:
+
+.. code-block:: php
+
+  $chado_schema = new \ChadoSchema();
+  $version = $chado_schema-getVersion();
+  if ($version == '1.3') {
+    [do your chado v1.3 specific querying here]
+  } else { [warn the admin using tripal_report_error() ] }
+
+
+Retrieving a list of tables
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To retrieve a list of Chado tables, you can use the following:
+
+.. code-block:: php
+
+  $chado_schema = new \ChadoSchema();
+
+  // All Chado Tables including custom tables
+  $all_tables = $chado_schema->getTableNames(TRUE);
+
+  // All Chado Tables without custom tables
+  $all_tables = $chado_schema->getTableNames();
+
+  // Chado tables designated as Base Tables by Tripal.
+  $base_tables = $chado_schema->getBaseTables();
+
+
+Ensuring your Chado instance is compliant
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Checking compliancy of your Chado instance with the released Chado Schema is a great way to **confirm an upgrade has gone flawlessly**. Additionally, while it is not recommended, sometimes customizations to the Chado schema may be necessary. In these cases, you should **ensure backwards compatibility** through compliance checking to confirm Tripal will work as expected.
+
+Chado compliancy testing is provided with Tripal's automated PHPUnit testing. As such, to test compliancy of your specific Chado instance, you first need to install Composer. Luckily this can be as easy as:
+
+.. code-block:: bash
+
+  php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
+  php -r "if (hash_file('SHA384', 'composer-setup.php') === '544e09ee996cdf60ece3804abc52599c22b1f40f4323403c44d44fdfdd586475ca9813a858088ffbc1f233e9b180f061') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
+  php composer-setup.php
+  php -r "unlink('composer-setup.php');"
+
+Once you have Composer, you need to install PHPUnit. This is installed locally within your Tripal repository. The following bash snippet shows you how to both install composer locally and run compliance checking.
+
+.. code-block:: php
+
+  cd [DRUPAL_ROOT]/sites/all/modules/tripal
+  composer up
+
+  # Now run compliance checking
+  ./vendor/bin/phpunit --group chado-compliance
+
+Schema Definition
+^^^^^^^^^^^^^^^^^^
+
+To retrieve the schema definition for a specific table, you can execute the following:
+
+.. code-block:: php
+
+  $table_name = 'feature';
+  $chado_schema = new \ChadoSchema();
+  $table_schema = $chado_schema->getTableSchema($table_name);
+
+The resulting ``$table_schema`` variable contains a Drupal-style array describing the schema definition of the table specified by ``$table_name``. This is a great tool when trying to develop generic queries, since you can extract information about an unknown table and use it to build a query for that table. For more information on the format of this array, see `the Drupal Schema API documentation <https://api.drupal.org/api/drupal/includes%21database%21schema.inc/group/schemaapi/7.x>`_.

docs/dev_guide/contributing.rst

@@ -0,0 +1,14 @@
+Contributing to Tripal Core Code
+================================
+
+
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Table of Contents
+
+
+   contributing/pull_requests
+   contributing/tests
+   contributing/documentation
+   contributing/governance

docs/dev_guide/contributing/documentation.rst

@@ -0,0 +1,62 @@
+Contributing to the Documentation
+==================================
+
+The Tripal documentation is written in `**Restructured Text** <http://docutils.sourceforge.net/rst.html>`_, compiled with `Sphinx <http://www.sphinx-doc.org/en/master/usage/quickstart.html>`_, and built/hosted with `ReadTheDocs  <https://readthedocs.org/>`_.  The ``docs`` directory, when compiled, is hosted at https://tripal.readthedocs.io/en/latest/.
+
+For minor changes, you can simply `Edit the file using the Github editor <https://help.github.com/articles/editing-files-in-your-repository/>`_, which will allow you to make a Pull Request.  Once approved, your changes will be reflected in the documentation automatically!
+
+Guide
+------
+
+
+Install Sphinx
+~~~~~~~~~~~~~~~~~
+
+For minor changes, you don't need to build the documentation!  If you want to see how your changes will look on the built site, however, you will need Sphinx installed.
+
+For more information, please see the Sphinx setup guide:
+http://www.sphinx-doc.org/en/master/usage/quickstart.html
+
+
+Building your changes
+~~~~~~~~~~~~~~~~~~~~~~~
+
+
+For more extensive edits, or when contributing new guides, you should build the documentation locally. From the ``docs`` root (eg ``/var/www/html/sites/all/modules/tripal/docs/``, execute ``make html``.  The built site will be in ``docs/_build/html/index.html``.
+
+Tripal conventions
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Please follow these guidelines when updating our docs. Let us know if you have any questions or something isn't clear.
+
+Please place images in the same folder as the guide text file, following the convention [file_name].[n].[optional description].[extension].  For example, ``configuring_page_display.3.rearrange.png`` or ``configuring_page_display.1.png`` are both located in ``docs/user_guide/`` and are part of the ``configuring_page_display.rst`` guide.
+
+We currently use the following syntax:
+
+.. code-block:: rst
+
+  Title of File (using title case)
+  =================================
+
+  Introduction text.
+
+  Section Title
+  -------------
+
+  We use double backticks to indicate ``inline-code`` including file names, function and method names, paths, etc.
+
+  Longer code-blocks should begin with the ``.. code-block:: [type]`` directive and should be indented at least one
+  level. There should also be a blank line before and after it as shown below.
+
+  .. code-block:: sql
+    if ($needs_documentation) {
+        use $these_guidelines;
+        $contribute_docs = $appreciated;
+    }
+
+  Section 1.1 Title
+  ^^^^^^^^^^^^^^^^^
+
+  The use of appropriate sections makes reading documentation and later specific details easier. Sub sections such
+  as this one will be hidden unless the main section is already selected.
+  ```

docs/dev_guide/contributing/governance.rst

@@ -0,0 +1,19 @@
+Tripal Governance
+==================
+
+Changes to this Document
+--------------------------
+
+
+These guidelines are binding to the Tripal Community. If you have comments or questions, please `comment on the Github issue <https://github.com/tripal/tripal/issues/344>`_. Changes to this document will be made after adequate discussion has occurred and the project management committee has voted in favor of the change.
+
+Governance Structure
+---------------------
+
+The Tripal project recognizes these roles:
+
+- Users: They have downloaded Tripal!  Maybe they even have a site!
+- Contributors: contributing!  Code, comments, discussion, questions, bug reports.
+- Committers: write access to the repository.
+- PMC: Makes **code relevant** decisions.
+- Oversight committee: Makes **policy level** decisions.  This may overlap with PMC, but the idea is the oversight committee includes parties who are **not necessarily coders** and therefore not reviewing Pull requests etc.

docs/dev_guide/contributing/pull_requests.rst

@@ -0,0 +1,130 @@
+Guidelines for Contribution to Tripal
+========================================
+
+The following guidelines are meant to encourage contribution to Tripal source-code on GitHub by making the process open, transparent and collaborative. If you have any feedback including suggestions for improvement or constructive criticism, please `comment on the Github issue <https://github.com/tripal/tripal/issues/344>`_. **These guidelines apply to everyone contributing to Tripal whether it's your first time (Welcome!) or project management committee members.**
+
+.. note::
+
+  These guidelines are specifically for contributing to `Tripal <https://github.com/tripal/tripal>`_. However, we encourage all Tripal extension modules to consider following these guidelines to foster collaboration among the greater Tripal Community.
+
+.. note::
+
+	Guidelines serve as suggestions ( **should** ) or requirements (**must**). When the word "should" is used in the text below, the stated policy is expected but there may be minor exceptions.  When the word "must" is used there are no exceptions to the stated policy.
+
+
+Github Communication Tips
+---------------------------
+
+- Don't be afraid to mention people (@username) who are knowledgeable on the topic or invested.  *We are academics and overcommitted, it's too easy for issues to go unanswered: don't give up on us!*
+- Likewise, don't be shy about bumping an issue if no one responds after a few days. *Balancing responsibilities is hard.*
+- Want to get more involved? Issues marked with "Good beginner issue" are a good place to start if you want to try your hand at submitting a PR.
+- Everyone is encouraged/welcome to comment on the issue queue! Tell us if you
+    - are experiencing the same problem
+    - have tried a suggested fix
+    - know of a potential solution or work-around
+    - have an opinion, idea or feedback of any kind!
+- Be kind when interacting with others on Github! (see Code of Conduct below for further guidelines). We want to foster a welcoming, inclusive community!
+    - Constructive criticism is welcome and encouraged but should be worded such that it is helpful :-) Direct criticism towards the idea or solution rather than the person and focus on alternatives or improvements.
+
+Bugs
+-----
+
+
+- Every bug **should** be reported as a Github issue.
+    - Even if a bug is found by a committer who intends to fix it themselves immediately, they **should** create an issue and assign it to themselves to show their intent.
+- Please follow the issue templates as best you can.  This information makes discussion easier and helps us resolve the problem faster.
+    - Also provide as much information as possible :-)  Screenshots or links to the issue on a development site can go a long way!
+- Bonus points for unit tests to ensure the bug does not return :-)
+
+Feature Requests
+------------------
+
+- Every feature request should start as an issue so that discussion is encouraged :-)
+- Please provide the following information (bold is required; underlined strengthens your argument):
+    - **Use Case:** fully describe why you need/want this feature
+    - Generally Applicable: Why do you feel this is generally applicable? Suggest other use cases if possible. Mention (@) others that might want/need this feature.
+    - Implementation: Describe a possible implementation. Bonus points for configuration, use of ontologies, ease of use, permission control, security considerations
+- All features **should** be optional so that Tripal admin can choose to make it available to their users.
+    - When applicable, new features should be designed such that Tripal-site admin can disable them.
+    - Bonus points: for making new features configurable and easily themed.
+- Feature requests will be voted on by the project management and advisory/steering committees to determine if it should be included in core, an existing extension module or it's own extension module.
+    - Votes should be based on whether this feature is generally applicable and doesn't exclude existing users and not be biased by the needs of your own Tripal site.
+- If a feature isn't suitable for inclusion within Tripal core, use the issue discussion as a springboard to create a Tripal extension module!
+
+.. note::
+
+  In the future there will be a set of guidelines for what should be included in core. This will make the process of requesting new features more streamlined, inclusive and transparent.
+
+Pull Request (PR) Guideline
+----------------------------
+
+The goal of this document is to make it easy for **A)** contributors to make pull requests that will be accepted, and **B)** Tripal committers to determine if a pull request should be accepted.
+
+- PRs that address a specific issue **must** link to the related issue page.
+    - Really in almost every case, there should be an issue for a PR.  This allows feedback and discussion before the coding happens.  Not grounds to reject, but encourage users to create issues at start of their PR.  Better late than never :).
+- Each PR **must** be tested/approved by at least 2 users with at least one user being a "trusted committer."
+    - Testers **should** describe how the testing was performed if applicable (allows others to replicate the test).
+    - At the Project Management Committee's (PMC) discretion, a PR may be subject to only one review.  Generally these are small and obvious commits.
+    - While Tripal's review body is small, only one of the code reviews must be a thorough functional test.
+    - Tripal's guiding philosophy is to encourage open contribution.  With this in mind, committers should **work with contributors** to resolve issues in their PRs.  PRs that will not be merged should be closed, **transparently citing** the reason for closure.  In an ideal world, features that would be closed are discouraged at the **issue phase** before the code is written!
+    - The pull request branch should be deleted after merging (if not from a forked repository) by the person who performs the merge.
+- PRs that include new functionality **must** also provide Unit Tests.
+    - Tests **must** test the new functionality added.
+    - Bonus points for testing all surrounding functionality.
+    - For example, when adding feature X to custom tables, the PR must include tests for feature X and we would be greatly appreciative if it included tests for custom tables in general :-D.
+- PRs **should** pass all Travis-CI tests before they are merged.
+- Branches **should** follow the following format:
+    - ``[issue\_number]-[tripal\_version]-[short\_description]``
+    - ``tripal\_version`` being Tv2, Tv3, etc.
+    - ``-[short\_description]`` being optional but highly encouraged
+- **Must** follow `Drupal code standards <https://www.drupal.org/docs/develop/standards>`_
+- PRs for new feature should remain open until adequately discussed (see guidelines below) and approved by a vote (all members of the PMC must vote in favour).
+
+
+.. note::
+
+  If you need more instructions creating a pull request, see for example the `KnowPulse workflow <https://knowpulse.readthedocs.io/en/latest/developer_docs/dev_workflow.html#workflow>`_
+
+How PRs and Issues are Handled
+------------------------------
+The Project Management Committee (PMC) and trusted committers will follow specific rules when working with all issues and pull requests. The rules are listed below. Anyone may provide bug fixes in which case some of the following will apply to all:
+
+- **Every task related to Tripal (bug, feature requests, documentation, discussions) should be in Github, either as it's own issue or grouped with like tasks into a single issue.** This effectively puts our todo list on github making it transparent to anyone who wants to help. It has the benefit of showing how active our community is, keeps everyone informed with where Tripal is headed and makes it easy for others to chime in with experience, comments and support.
+- **Guidelines for Tagging Issues:**
+    - The first committer who comments on an issue should tag it with the version of Tripal it applies to.
+    - Issues with a suggested fix or work-around should be tagged with "Fix Required" to let others know a PR is needed.
+    - Only tag an issue with "bug" once it has been shown to be reproducible. If it's not reproducible by a committer but you feel it is a bug then tag it as "potential bug".
+    - If multiple users have commented that a bug affects them, tag it as "affects multiple users".
+    - Issues that require a PR and someone with relatively little Tripal experience could fix should be tagged with "Good beginner issue"
+    - All feature requests should be tagged as an "enhancement"
+    - If you are the first reviewer to confirm a PR works, tag it with "Reviewer #1 Approval"
+- **Guidelines for Discussion:**
+    - Issues that do not require discussion (PRs still require 2 reviews): minor bug fixes, changes to inline comments, addition of unit tests, minor code typos
+    - Issues that require discussion: major changes, new features, and issue at the discretion of the PMC
+      - Add the "discussion" tag to any issue requiring discussion
+      - Discussion Tag is removed when adequate discussion has taken place (at the discretion of the person who added the tag)
+      - Additionally, new features require that all members of the PMC have had a chance to contribute to the discussion and feel satisfied.
+- Please use the **assignment** feature to clarify who will be contributing the code to prevent duplication of effort.
+    - When assigning yourself, comment on what your timeline is. This allows others to jump in if they have time sooner.
+    - If you would like to **take over a PR assigned to someone else** , comment asking for an update and offer your services.
+    - If the author of the issue plans on contributing the fix themselves but is not a committer, they should indicate that in the issue.  A committer will assign them the issue.
+- When you start working on an issue, you **should** create the branch and push to it regularly. If you are working on a fork, you're **encouraged** to link to it in the issue.
+    - Committers can work on a fork or directly.  If the branch is on tripal/tripal, then other committers should contribute via PR unless otherwise agreed
+- If an issue is identified as being relevant to another repository (ie a tripal module, not core), a new issue **should** be created, cross referenced, and the original issue should be closed encouraging discussion in the module.
+
+Code of Conduct
+----------------
+
+
+- Be nice!  If that's insufficient, Tripal community defers to https://www.contributor-covenant.org/
+
+Testing/CI
+------------
+
+
+Comprehensive guides to testing are available in the :ref:`tests` section.  Below are guiding principles.
+
+- All tests pass.
+- Tests don't modify db: use transactions and factories.
+- Tests are organized properly: by submodule and function.
+- Tests run quietly.

docs/dev_guide/contributing/tests.rst

@@ -0,0 +1,188 @@
+.. _tests:
+
+Unit Tests for Tripal
+=======================
+
+This guide is for developers looking to contribute code to the core Tripal project.  It introduces the testing philosophy and guidelines for Tripal core.  Tripal uses Tripal Test Suite, which brings bootstraps your Tripal site for PHPUnit.  It also provides conveniences like name spacing, seeders, transactions, and data factories.
+
+Tripal Test Suite
+-------------------
+
+For a basic introduction of Tripal Testing, please see the `Test Suite documentation <https://tripaltestsuite.readthedocs.io/en/latest/>`_.
+
+Installation
+~~~~~~~~~~~~~~
+
+After cloning the `Tripal Github repo <https://github.com/tripal/tripal>`_, you will need to install the developer dependencies required to run tests locally.  To do this, you'll need to `install Composer <https://getcomposer.org/doc/00-intro.md>`_, and then execute ``composer install`` in your project root.
+
+Remember to run ``composer update`` to update Tripal TestSuite before writing and running new tests. This is especially important when running pull requests that contribute unit tests. If tests are passing on the Travis environment but not on your machine, running composer update might resolve the problem.
+
+Testing criteria
+-----------------
+
+For facilitate accepting your pull requests, your code should include tests.  The tests should meet the following guidelines:
+
+* All tests pass
+* Tests pass in all environments (Travis)
+* Tests don't modify the database (use transactions or clean up after yourself)
+* Tests are properly organized (see organization section below)
+* Tests run quietly
+
+Test organization
+------------------
+
+Tests should be placed in ``tests/``.  This root directory contains the following files:
+ - ``bootstrap.php``: Test directory configuration.  Don't modify this.
+ - ``DatabasSeeders/``: `Database seeders <https://github.com/statonlab/TripalTestSuite#database-seeders>`_, for filling Chado with permanent test data.
+ - ``DataFactory.php``: `Data factories <https://github.com/statonlab/TripalTestSuite#factories>`_, for providing test-by-test Chado data.
+ - ``example.env``: An example environment file.  Configure this to match your development site and save as ``.env``.  Read more here: https://tripaltestsuite.readthedocs.io/en/latest/environment.html
+
+Test files must end with ``Test.php`` to be recognized by PHPUnit.  The tests themselves should be organized by submodule, and category.
+
+Submodules
+~~~~~~~~~~~
+
+* tripal
+* tripal_bulk_loader
+* tripal_chado
+* tripal_chado_views
+* tripal_daemon
+* tripal_ds
+* tripal_ws
+
+Categories
+~~~~~~~~~~
+
+* API
+* theme
+* views
+* drush
+* fields
+* entities
+* admin
+* loaders
+
+So for example, tests for the file ``tripal/api/tripal.jobs.api.inc`` should go in ``tests/tripal/api/TripalJobsAPITest.php``. tests that don't fit in any of these categories should be placed in ``tests/[submodule]/``.
+
+In order for tests to run locally, you'll need an environmental file ``tests/.env`` with the project root, base url, and locale.  See ``tests/example.env`` for an example.
+
+Writing tests
+--------------
+
+Tagging tests
+~~~~~~~~~~~~~~~~
+
+You should tag your test with relevant groups.  For example, our Tripal Chado API tests should be tagged with ``@group api``.  We don't need to tag it with ``@group chado`` because it is in the *testsuite* (the submodule folder) Chado.
+
+If your test is related to a specific issue on the Tripal repo, thats great! You can use the ``@ticket`` tag to link it: ie, ``@ticket 742`` for issue number 742.
+
+Defining the test class
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The test class file should extend ``StatonLab\TripalTestSuite\TripalTestCase`` instead of ``TestCase`` to take advantage of the Tripal Test Suite tools.  Tests should use a database transaction to ensure the database state is the same at the start and end of the test case.  Your test class name should match the file.
+
+
+.. code-block:: php
+
+  use StatonLab\TripalTestSuite\DBTransaction;
+  use StatonLab\TripalTestSuite\TripalTestCase;
+
+  class TripalChadoOrganismAPITest extends TripalTestCase {
+  	use DBTransaction;
+  }
+
+
+Defining individual tests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An ideal test operates *independently* of other tests: by default, unit tests run in random order.  How, then, do we provide our test with relevant data?  We use **Factories**, which you can read about on in the `Tripal Test Suite documentation <https://tripaltestsuite.readthedocs.io/en/latest/factories.html>`_.  In the below example, we create an organism with known information, and assert that we can retrieve it with the Chado API functions.
+
+
+.. code-block:: php
+
+
+  namespace Tests\tripal_chado\api;
+
+  use StatonLab\TripalTestSuite\DBTransaction;
+  use StatonLab\TripalTestSuite\TripalTestCase;
+
+  class TripalChadoOrganismAPITest extends TripalTestCase {
+
+    use DBTransaction;
+
+    /**
+     * Test tripal_get_organism.
+     *
+     * @group api
+     */
+    public function test_tripal_get_organism() {
+
+      $genus_string = 'a_genius_genus';
+      $species_string = 'fake_species';
+
+      $organism = factory('chado.organism')->create([
+        'genus' => $genus_string,
+        'species' => $species_string,
+      ]);
+
+      $results = [];
+
+      $results[] = tripal_get_organism(['organism_id' => $organism->organism_id]);
+      $results[] = tripal_get_organism([
+        'genus' => $genus_string,
+        'species' => $species_string,
+      ]);
+
+      foreach ($results as $result) {
+        $this->assertNotFalse($result);
+        $this->assertNotNull($result);
+        $this->assertObjectHasAttribute('genus', $result);
+        $this->assertEquals($genus_string, $result->genus);
+      }
+    }
+
+    public function test_tripal_get_organism_fails_gracefully() {
+      $result = tripal_get_organism([
+        'genus' => uniqid(),
+        'species' => uniqid(),
+      ]);
+
+      $this->assertNull($result);
+    }
+  }
+
+
+.. note::
+
+  You typically will want at least one test per public method in your file or class. Tests should start with ``test_``, otherwise it wont run by default in PHPUnit (you can also declare that it is a test in the method documentation using ``@test``.
+
+Testing quietly
+~~~~~~~~~~~~~~~~
+
+Tests should run quietly.  If the output goes to standard out, you can use ``ob_start()`` and ``ob_end_clean()``.
+
+
+.. code-block:: php
+
+
+    ob_start();//dont display the job message
+    $bool = tripal_chado_publish_records($values);
+    ob_end_clean();
+
+
+If the message comes from the Tripal error reporter, you must use ``"TRIPAL_SUPPRESS_ERRORS=TRUE"`` to suppress the Tripal error reporter message.
+
+.. code-block:: php
+
+
+  /**
+   * Test chado_publish_records returns false given bad bundle.
+   *
+   * @group api
+   */
+  public function test_tripal_chado_publish_records_false_with_bad_bundle() {
+    putenv("TRIPAL_SUPPRESS_ERRORS=TRUE");//this will fail, so we suppress the tripal error reporter
+    $bool = tripal_chado_publish_records(['bundle_name' => 'never_in_a_million_years']);
+    $this->assertFalse($bool);
+    putenv("TRIPAL_SUPPRESS_ERRORS");//unset
+  }

docs/dev_guide/custom_field.rst

@@ -42,4 +42,5 @@ The rest of this section will walk you through these steps.
 
    custom_field/select_vocab_terms
    custom_field/manual_field_creation
+   custom_field/custom_widget
    custom_field/tripal_field_generator

docs/dev_guide/custom_field/custom_widget.rst

@@ -0,0 +1,113 @@
+Creating a Custom Widget
+========================
+
+In Drupal/Tripal terminology, **widget** refers to the form elements for a specific Tripal Field on the "Edit" form of a piece of Tripal Content. For example, the ``obi__organism`` widget creates the "Organism" drop-down on the edit form of a specific gene. All fields come with a default widget; however, you can create a custom widget if the default one doesn't meet your needs.
+
+.. note::
+  This guide is going to assume you already have your widget file created. For more information, see :doc:`manual_field_creation` or, :doc:`tripal_field_generator`.
+
+.. note::
+	If you are only creating a widget and not the whole field, you still need to follow the expected directory structure. For example, if your widget is going to be named ``obi__organism_fancy`` then your file would be ``[your_module]/includes/TripalField/obi__organism_fancy/obi__organism_fancy_widget.inc``.
+	
+The Form
+--------
+
+The form elements of your widget are defined in the ``form()`` method of your widget according to the `Drupal Form API <https://api.drupal.org/api/drupal/developer%21topics%21forms_api_reference.html/7.x>`_. As such the ``$widget`` variable is actually a nested associative array describing what the widget portion of the form should look like. For example, the following is how the ``obi__organism`` widget creates the drop-down.
+
+.. code-block:: php
+
+  /**
+   * @see TripalFieldWidget::form()
+   */
+  public function form(&$widget, &$form, &$form_state, $langcode, $items, $delta, $element) {
+
+    $field_name = $this->field['field_name'];
+    $field_table = $this->instance['settings']['chado_table'];
+    $linker_field = 'chado-' . $field_table . '__organism_id';
+
+    // The value presented to the user via load.
+    // If $items['delta']['value'] is set then we are updating and already have this
+    // information. As such, simply save it again.
+    $widget['value'] = array(
+      '#type' => 'value',
+      '#value' => array_key_exists($delta, $items) ? $items[$delta]['value'] : '',
+    );
+
+    // Pull out the value previously saved to be used as the default.
+    $organism_id = 0;
+    if (count($items) > 0 and array_key_exists($linker_field, $items[0])) {
+      $organism_id = $items[0][$linker_field];
+    }
+    
+    // Define a drop-down form element where the options are organisms retrieved using
+    // the Tripal API, the default is what we looked up above, and the title and 
+    // description are those set when defining the field.
+    $widget[$linker_field] = array(
+      '#type' => 'select',
+      '#title' => $element['#title'],
+      '#description' => $element['#description'],
+      '#options' => chado_get_organism_select_options(FALSE),
+      '#default_value' => $organism_id,
+      '#required' => $element['#required'],
+      '#delta' => $delta,
+    );
+
+  }
+
+At a minimum, the form must have a ``value`` element.  For Tripal, the ``value`` element of a field always corresponds to the value that is presented to the end-user either directly on the page (with formatting) or via web services, or some other mechanism. Convention is to store the value of the field as a hidden ``value`` form element as is shown in the above example. 
+
+.. note::
+	For more information on how to use the Drupal Form API, check out the `official Drupal Documentation <https://www.drupal.org/docs/7/api/form-api>`_.
+
+.. note::
+	The current item is saved in ``$items[$delta]`` as an array where the keys will match those set by the field ``load()`` function.
+
+
+Validation
+----------
+
+The ``validate()`` function of your widget allows you to confirm that the values entered by the user are valid. It is recommended to consider each form element you created above and consider what is required for that element to be entered "correctly". For example, for an organism drop-down, the organism chosen must exist in our chado database (since this is a ``ChadoFieldWidget``). Luckily this doesn't need to be validated since Drupal ensures only elements in our select list are chosen.
+
+.. warning::
+	The ``value`` key of this field must be set in the ``$form_state['values']`` array to a **TRUE** value (e.g. a string or non-zero integer) anytime data is entered by the user. 
+	
+.. note::
+	For more information on how to validate your data, see the official `Drupal Form Validation Documentation <https://www.drupal.org/docs/7/creating-custom-modules/validating-the-data>`_
+   
+Saving the Data
+---------------
+
+The Drupal Storage Backend handles saving of your widget data. As such, **you do not and should not insert, update or delete the data yourself**. It should happen automatically, assuming you've followed the conventions of the specific storage backend. 
+
+Chado Fields utilize the chado storage backend to save your data. Thus to ensure your data is saved, you set the columns of your chado table to the values you want them set via the ``$form_state['values']`` array using the ``chado-[table]__[column]`` convention. This should be done at the end of the validation function above, if the data submitted is valid. 
+
+For our ``obi__organism`` example, the drop-down returns the chado organism_id of the record chosen by the user. We would like to save that as the organism_id of the chado table the field references, which the following code specifies.
+
+.. code-block:: php
+
+  /**
+   * @see TripalFieldWidget::validate()
+   */
+  public function validate($element, $form, &$form_state, $langcode, $delta) {
+
+    $field_name = $this->field['field_name'];
+    $field_table = $this->instance['settings']['chado_table'];
+    $linker_field = 'chado-' . $field_table . '__organism_id';
+
+    //...
+    // Validate your data here
+    //...
+
+    // In this case, if you have an organism_id, then your user selected this field.
+    $organism_id = $form_state['values'][$field_name]['und'][0][$linker_field];
+    if ($organism_id > 0) {
+      $form_state['values'][$field_name]['und'][0]['value'] = $organism_id;
+      // This is where we tell the storage backend what we want to save.
+      // Specifically, that we want to save $organism_id to $field_table.organism_id
+      $form_state['values'][$field_name]['und'][$delta][$linker_field] = $organism_id;
+    }
+  }
+
+Drupal typically does not provide a submit hook for fields because, as mentioned above, saving should be done by the storage backend. However, the TripalField provides a ``TripalFieldWidget::submit()`` to allow for behind-the-scenes actions to occur. This function should never be used for updates, deletes or inserts for the Chado table associated with the field as these actions should be handled by the storage backend. 
+
+However, it is permissible to perform inserts, updates or deletions within Chado using this function.  Those operations can be performed if needed but on other tables not directly associated with the field. An example is the ``chado.feature_synonym`` table.  The ``chado_linker__synonym`` field allows the user to provide a brand new synonynm and it must add it to the chado.synonym table prior to the record in the chado.feature_synonym table.

docs/dev_guide/exporting_field_settings.rst

@@ -0,0 +1,122 @@
+Exporting Field Settings With Drupal Features
+================================================
+
+This guide will demonstrate using the `Drupal Features <https://www.drupal.org/docs/7/modules/features>`_ to export and import Tripal Bundle Field settings.
+
+Why Drupal Features?
+---------------------
+
+Consider a case where we have a development site where we configure a bundle (let's say the vanilla Analysis bundle) to have a custom set of Tripal Panes, with fields carefully reorganized into the panes.  In particular, we attach a Drupal File field to it, so we can host FASTA files easily.
+
+Once we've configured the field settings, how do we get them to the live site?  One option is to open our field configuration admin UI on both sites, and copy the details one at a time.  This method is `time consuming and error prone <https://www.drupal.org/docs/7/modules/features/features-moving-site-configuration-to-code>`_, although it is relatively safe: we aren't liable to accidentally break our database this way.  Alternatively, trying to transfer via writing database exports is dangerous, and liable to accidentally break our site.
+
+Is there a better way?  By exporting the field configuration as a feature!
+
+.. note::
+
+  Drupal 8 has a `feature designed to handle development deployment <https://www.phase2technology.com/blog/drupal-8-configuration-management>`_: Configuration Management!  Drupal Features remains relevant for sharing field configurations across sites, so this guide may remain useful when Tripal moves to Drupal 8.
+
+.. warning::
+
+  Note that I'm going to talk about features a lot in this post.  **In the context of the Feature module, features are exported configurations within your site**.  It's important that we don't confuse this with Chado features, which are genes, mRNAs, polypeptides, etc.
+
+Version control
+~~~~~~~~~~~~~~~~
+
+Because features get exported as their own module, this means you can treat them as such.  You can initialize a git repo, store them on GitHub, make discrete versions, and in general benefit from version control for something which otherwise would only be done via the UI.
+
+How many Features?
+~~~~~~~~~~~~~~~~~~~
+
+The features documentation links to a great article about `how to manage multiple features <http://kerasai.com/blog/2014/04/08/organizing-features-configuration-managment>`_.  The suggestion that each bundle be its own module is particularly helpful for Tripal, since we have so many bundles and its a reasonable, discrete way to manage and deploy configuration.  This means that mRNA and gene should be separate feature modules even though they are both ``chado.feature`` content types.
+
+A Hazard: Mapping bundle IDs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+The main hurdle to overcome when mapping features is converting the field machine names across site.  This is because each field instance is specific to the bundle it's attached to, and bundle machine-names are from the bundle ID.  We can't assume bundle IDs are consistent across sites!
+
+So what do we do?  Interestingly, roles have a similar problem, and a guide is `available <https://www.drupal.org/docs/7/modules/features/exportables-and-user-role-ids-in-features>`_ for dealing with them.
+
+The general strategy is:
+
+-   remove the exported id value from the ``features.inc`` file
+-   use hook alter to fetch the ID on the target deployment setup
+
+In our example below, the bundle ID's match on our site.  For default Tripal bundles, this should generally be the case.
+
+Drupal Features Tutorial
+-------------------------
+
+
+In this tutorial, we'll add a FASTA file field to the Analysis bundle, and export the configuration.
+
+Configuring the bundle fields
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To begin, let's quickly configure a bundle.  Navigate to the structure of your site and select Analysis (**Admin ->Structure -> Tripal Content -> Analysis -> Manage Fields**).  Scroll to the bottom and add a new field of type File, with a machine name of ``field_fasta_file‎``, and click **Save**. Be sure to change the **Allowed extensions** parameter to accept ``.fasta``, otherwise, it will only allow `.txt` files to be uploaded.  You may also want to increase the file size limit, as the default 2MB can be too small for many FASTA files.
+
+We now have to pick a CV term for our field.  Because we are providing a FASTA file field, we can use a term such as FASTA `(SWO:0000142 <https://www.ebi.ac.uk/ols/ontologies/ero/terms?iri=http%3A%2F%2Fwww.ebi.ac.uk%2Fefo%2Fswo%2FSWO_0000142>`_.  Please see  :ref:`adding_a_cvterm` for help loading a term.  Once the term is in our DB, we can assign it to this field.
+
+
+.. image:: ./exporting_field_settings.1.assign_term.png
+
+
+Now lets configure our field display.  Click the **Manage Display Tab** at the top, and create and enable a "Files" Tripal Pane, placing our new field in the Pane.
+
+
+.. image:: ./exporting_field_settings.2.png
+
+
+You can verify your new field is enabled and working by creating a new Analysis and inspecting the "FASTA file" field.
+
+.. image:: ./exporting_field_settings.3.png
+
+
+Exporting the bundle field displays
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Once we are happy with our bundle field configuration, we can export the display settings using the Drupal Features module.
+
+First, we enable the Features module using drush: ``drush pm-enable features -y``.  This adds a Features area under **Admin -> Structure**.  Navigate there and choose **Create Feature**.
+
+The field information we're looking for is in **Field Bases**, **Field Group**, and **Field Instances**.  We can search for FASTA to find the field base and instance, and "files" (the name of our group) to find the field group.
+
+.. note::
+
+  Both **Field Bases** and **Field Instances** will contain the machine name of the field you want to export. **Field Bases** contains the site-wide information for a field and **Field Instances** contains the bundle-specific (i.e. Tripal Content Type) settings.
+
+  **Field Group** will contain the machine name of the Tripal Pane and allows you to export the grouping settings you set on the **Manage Display Tab**.
+  
+I've also specified a custom path to keep all my Tripal features together under advanced options.
+
+
+.. image:: ./exporting_field_settings.4.png
+
+If we download and unzip our feature module, we can see it includes all the trappings of a Drupal module.
+
+.. image:: ./exporting_field_settings.5.png
+
+
+.. warning::
+
+	As you can see, it makes the assumption that ``bio_data_2``, the bundle ID for Analysis on our source site, is the correct bundle to configure fields for.  However, Tripal makes no guarantee that will hold true on our target site.  One solution would be to manually relabel ``bio_data_x`` to the correct bundle ID.  On a smaller scale, this is a reasonable solution.  If you aren't sure what your bundle ID is, look in the URL when configuring the fields for it:  my constructed URL for example was ``admin/structure/bio_data/manage/bio_data_2/fields``.
+
+  In our case, the site we want to import to has the same Analysis bundle ID, so no further action is necessary.
+
+
+Importing the feature configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Go to our target site, all we need to do is download and unpack the ``.tar`` file we generated and enable the module (assuming the bundle ID issue is addressed).  I downloaded my file to ``/var/www/html/sites/all/modules/custom/analysis_configuration.tar``, decompressed it (``tar -xvf analysis_configuration.tar``), and enabled it (``drush pm-enable tripal_configuration``).
+
+The field should now appear when you go to create a new analysis on your target site.  To check for yourself, create a new Analysis with dummy information: you'll be able to upload a file for the new file field.
+
+Unfortunately, the field still gets imported **disabled** due to Tripal preference, so we have to go to the display settings on our target site and enable the tripal pane/field.
+
+
+.. image:: ./exporting_field_settings.6.png
+
+
+Drag the disabled Tripal pane/field group out of the disabled area, click save, and re-visit your newly created Analysis.  The files pane and uploaded FASTA file will now appear.
+
+.. image:: ./exporting_field_settings.7.png

docs/user_guide.rst

@@ -1,5 +1,5 @@
 User's Guide
-==============
+============
 
 
 .. toctree::
@@ -10,11 +10,10 @@ User's Guide
    user_guide/what_is_tripal
    user_guide/install_tripal
    user_guide/drupal_overview
-   user_guide/example_genomics
    user_guide/learn_chado
-   user_guide/creating_content
-   user_guide/setting_page_urls
-   user_guide/configuring_page_display
+   user_guide/content_types
+   user_guide/example_genomics
+   user_guide/file_management
    user_guide/mviews
    user_guide/searching
    user_guide/job_management

docs/user_guide/bulk_loader.rst

@@ -1,7 +1,10 @@
-
 Bulk Loader
 ===========
 
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`./install_tripal/drupal_home`
+
 The bulk loader is a tool that Tripal provides for loading of data contained in tab delimited files. Tripal supports loading of files in standard formats (e.g. ``FASTA``, ``GFF``, ``OBO``), but Chado can support a variety of different biological data types and there are often no community standard file formats for loading these data. For example, there is no file format for importing genotype and phenotype data. Those data can be stored in the feature, stock and natural diversity tables of Chado. The Bulk Loader was introduced in Tripal v1.1 and provides a web interface for building custom data loader. In short, the site developer creates the bulk loader "template". This template can then be used and re-used for any tab delimited file that follows the format described by the template. Additionally, bulk loading templates can be exported allowing Tripal sites to share loaders with one another.  Loading templates that have been shared are available on the Tripal website here: http://tripal.info/extensions/bulk-loader-templates.
 
 The following commands can be executed to install the Tripal Bulk Loader using Drush:
@@ -20,7 +23,7 @@ To demonstrate use of the Bulk Loader, a brief example that imports a list of or
 
 .. code-block bash
 
-  cd /var/www/html/sites/default/files
+  cd $DRUPAL_HOME/sites/default/files
   wget http://tripal.info/sites/default/files/book_pages/Fragaria_0.txt
 
 
@@ -244,10 +247,14 @@ Provide the following values:
 
 * Job Name: Import of Fragaria species
 * Template: NCBI Taxonomy Importer (taxid, genus species).
-* Data File: /var/www/html/sites/default/files/Fragaria_0.txt
+* Data File: [DRUPAL_HOME]/sites/default/files/Fragaria_0.txt
 * Keep track of inserted IDs: No
 * File has a header: No
 
+.. note::
+
+  Be sure to change the [DRUPAL_HOME] token to where Drupal is installed.
+
 Click **Save**. The page then appears as follows:
 
 .. image:: ./bulk_loader.9.png
@@ -261,7 +268,7 @@ Now that we have created a job, we can submit it for execution by clicking the *
 .. code-block:: shell
 
   cd /var/www
-  drush trp-run-jobs --username=admin --root=/var/www/html
+  drush trp-run-jobs --username=admin --root=$DRUPAL_HOME
 
 After execution of the job you should see similar output to the terminal window:
 

docs/user_guide/content_types.rst

@@ -0,0 +1,15 @@
+Working with Content Types
+==========================
+
+New in Tripal v3 is the ability to create your own content types and manage their display!  In previous versions of Tripal a bit of PHP programming was necessary. This is no longer the case.  Tripal v3 comes pre-populated with a variety of content types and provides a web interface that allows you to create your own.  This section provides details for working with content types in Tripal.
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Table of Contents
+   :glob:
+
+   ./content_types/creating_content
+   ./content_types/setting_page_urls
+   ./content_types/configuring_page_display
+   ./content_types/field_loading
+   ./content_types/field_permissions

docs/user_guide/configuring_page_display.rst → docs/user_guide/content_types/configuring_page_display.rst

@@ -1,16 +1,12 @@
-
-Configuring Page Display
-=========================
-
-
-This is one of the many new exciting features of Tripal v3.x. In this version of Tripal we have taken integration with Drupal Fields to a whole new level representing each piece of content (in Chado or otherwise) as a Drupal Field. What this means for site builders is unprecendented control over content display and arrangement through the administrative user interface --No more editing PHP template files to change the order, grouping or wording of content!
+Configuring Page Layout
+=======================
+This is one of the many new exciting features of Tripal v3. Integration with Drupal Fields has gone to a whole new level. Site builders have unprecendented control over the display of each piece of data through the administrative user interface. Previously, site builders were required to edit PHP template files to change the order, grouping or wording of content.
 
 You can configure the display of a given Tripal Content Type by navigating to **Structure → Tripal Content Types** and then selecting the **Manage Display** link beside the content type you would like to configure.
 
 .. image:: ./configuring_page_display.1.png
 
 
-
 The Manage Display User Interface lists each Drupal Field in the order they will be displayed on the page. Fields are grouped into Tripal Panes by the Tripal DS module and the page is automatically divided into a right and left column. By default the left column contains the table of contents which lists the Tripal Panes available to the user in the order they are listed in this UI. The following screenshots are using the Analysis Content Type for demonstatration.
 
 .. image:: configuring_page_display.2.png
@@ -39,7 +35,7 @@ There may also be data you want to collect from your user but don't want to disp
 Changing Tripal Pane Names
 --------------------------
 
-The name of a Tripal Pane is displayed both in the header of the Pane itself and in the Table of Contents. To change this name, click the gear button to the far right of the Tripal Pane you would like to change. This will bring up a blue pane of settings. Changing the Field Group Label will change the display name of the pane. For example, the following screenshot shows how you would change the "Cross References" Tripal Pane to be labeled "External Resources" instead if that it what you prefer. Then just click the Update button to see your changes take effect.
+If you enabled the `tripal_ds` module during installation then you will have what is called **Panes** into which fields can be grouped. With the `tripal_ds` module all field come pre-organizd into panes.  The name of a pane is displayed both in the header of the pane itself and in the Table of Contents. To change this name, click the gear button to the far right of the Tripal Pane you would like to change. This will bring up a blue pane of settings. Changing the Field Group Label will change the display name of the pane. For example, the following screenshot shows how you would change the "Cross References" Tripal Pane to be labeled "External Resources" instead if that it what you prefer. Then just click the Update button to see your changes take effect.
 
 .. image:: ./configuring_page_display.4.png
 
@@ -49,9 +45,3 @@ Display/Hide Tripal Panes on Page Load
 
 You can also easily control which Tripal Panes you would like displayed to the user on initial page load. By default the Summary Pane is the only one configured to show by default. However, if you would prefer for all panes or even a specific subset of panes to show by default, you can simply click the gear button to the far right of each Tripal Pane you want displayed by default and uncheck the "Hide panel on page load" checkbox. This gives you complete control over which panes you want your user to see first. If more then one pane is displayed by default then they will be shown in the order they are listed on the Manage Display UI.
 
-Display/Hide Empty Fields
--------------------------
-
-By default Tripal v3 hides all empty fields from the user. However like most behaviour in Tripal, this can be configured. If you would prefer to show all fields to the user regardless of whether there is content for that particular page, then navigate to ``Structure → Tripal Content Types`` and then click on the edit link beside the Tripal Content Type you would like to show empty fields for. Near the bottom of this form is a **Field Display** drop-down. Just change this drop-down to "show empty fields" and then click **Save Content Type**. As an example, we have changed this setting for the organism content type and, as you can see below, now you can see all fields (including empty fields like cross references and relationships) available to the organism content type.
-
-.. image:: ./configuring_page_display.5.png

docs/user_guide/creating_content.rst → docs/user_guide/content_types/creating_content.rst

@@ -29,7 +29,9 @@ How to Add a CV Term
 --------------------
 Loading From an OBO File
 ^^^^^^^^^^^^^^^^^^^^^^^^
-Once you've choosen a term to describe your content type, you may need to add the term to Tripal if it is not already present.  Many CVs use the `OBO file format <https://owlcollab.github.io/oboformat/doc/GO.format.obo-1_4.html>`_ to define their terms. If the term belongs to a controlled vocabulary with a file in OBO format then you can load all the terms of the vocabulary using Tripal's OBO Loader at **Tripal → Data Loaders → Chado Vocabularies → Chado OBO Loader**.
+Once you've chosen a term to describe your content type, you may need to add the term to Tripal if it is not already present.  Many CVs use the `OBO file format <https://owlcollab.github.io/oboformat/doc/GO.format.obo-1_4.html>`_ to define their terms. If the term belongs to a controlled vocabulary with a file in OBO format then you can load all the terms of the vocabulary using Tripal's OBO Loader at **Tripal → Data Loaders → Chado Vocabularies → Chado OBO Loader**.
+
+.. _adding_a_cvterm:
 
 Manually Adding a Term
 ^^^^^^^^^^^^^^^^^^^^^^

docs/user_guide/content_types/field_loading.rst

@@ -0,0 +1,26 @@
+Hide Empty Fields and AJAX loading
+==================================
+
+Tripal provides two additional controls for display of fields on a page:
+
+* Hiding fields with no data.
+* Loading fields using AJAX.
+
+You will find two check boxes when editing any content page that gives you these controls.  Navigate to ``Structure → Tripal Content Types`` and then click on any Tripal Content Type.  You will see options similar to the following:
+
+.. image:: ./field_loading.empty_ajax.png
+
+
+Hiding Empty Fields
+-------------------
+The previous sections of this guide instructed how to rearrange fields on a page, hide their titles, and organize them into panes.  However, while there are many fields many of them may not have any data.  All of these fields are present because the data store (e.g. Chado) has the capacity to house the type of data the fields represent, but if you did not load data appropriate for those fields then they will have no data.  
+
+By default Tripal v3 hides all empty fields from the user. However if you would prefer to show all fields to the user regardless of whether there is content for that particular page edit the content type and click the box labeled `Hide Empty Fields` and click the `Save` button at the bottom.  The next time anyone loads any page for the given content type all fields will be shown regardless if they have data.
+
+Using AJAX to Load Fields
+-------------------------
+Depending on the number of fields for your content type and the amount of data that those fields contain you may notice that page loads can take a few seconds to load. AJAX is a method to help decrease load times by allowing the page to load quickly with minimal data and allowing fields with larger amounts of data to load after the initial page load.  Tripal has this setting enabled by default. but you can disable this feature.  Similar to the check box for hiding fields, there is a check box on the content type edit page labeled `Load field using AJAX`. Remove the check for box to disable all AJAX loading of fields and save the content type settings.
+
+.. note::
+ 
+  You can control AJAX loading and hiding of empty fields differently for each conent type.

docs/user_guide/content_types/field_permissions.rst

@@ -0,0 +1,56 @@
+Field Specific Permissions
+===========================
+
+
+.. _why_field_permissions:
+
+Why Field Permissions?
+----------------------
+
+Not all Tripal Fields are created equal.  You may have some fields that you don't want all users to be able to view, or even to be able to edit. This might be the case for a variety of reasons.  Some Chado base tables may have **type** fields that you don't utilize: for example, the contact table.  Some of your content types may be configured with a lot of property fields, with only a subset of them being relevant to an end user.  Some fields require prior insertion of data elsewhere: for example, the Cross-Reference field.  Perhaps you have some Chado property fields that are for internal use only.
+
+.. note::
+
+	If you're following this guide because you want users to submit data into Chado, consider using Tripal HeadQuarters (HQ).  Tripal HQ provides a user-contributed content control center and administrative toolbox for your Tripal site. This means that users are able to create whatever Chado content you’d like them, but withhold inserting it into the database until someone has approved it.  Find out more here: https://tripal-hq.readthedocs.io/en/latest/index.html
+  
+
+
+Simply disabling the display of the formatter won't prevent the widget from showing up on the submission page, and besides, you might want site admins to still have access to those fields!  Deleting the field will cause them to re-appear when you press the "Check for New Fields" button!  Field Permissions allows you to configure field-specific permissions so that users contributing content via Chado only see the fields they need to see.
+
+Installing the Drupal Field Permissions module
+-----------------------------------------------
+
+The module can be enabled directly from Drush with the below command.
+
+.. code-block:: bash
+
+  drush pm-enable -y field_permissions
+
+
+You can find the Field Permission module page here: https://www.drupal.org/project/field_permissions and a more in-depth user guide here: https://www.drupal.org/node/2802067
+
+
+
+Setting Field-specific Permissions
+--------------------------------------------
+
+
+
+Let's assume I want to hide the Cross-Reference field from my users submitting Genome Assembly data, but still want it available for my administrators.
+
+.. image:: ./field_permissions.1.cross_ref_GA.png
+
+First, navigate to the content type field configuration page via **Admin --> Structure --> Tripal Content --> Genome Assembly**.  For each field we want to hide, we must configure the field instance settings individually.  Click **Edit** for the Cross Reference field, and scroll down to **CROSS REFERENCE FIELD SETTINGS**.
+Select **Custom Permissions** and ensure that the user role you set up for submitters can view, but cannot edit, this field.
+
+.. image:: ./field_permissions.2.crossref_permissions.png
+
+Once permissions are configured to your liking, click **Save Settings**.
+
+
+.. warning::
+
+  Some fields are **Required**.  Do not disable required fields that can't be null.  If you do, users won't be able to submit content!
+
+
+Now, if you submit content as a user with that role, the field will not display on the widgets, but will still appear on normal content.

docs/user_guide/example_genomics.rst

@@ -14,3 +14,4 @@ The following tutorial will walk you through creating content and loading genomi
    ./example_genomics/controlled_vocabs
    ./example_genomics/genomes_genes
    ./example_genomics/pub_import
+   ./example_genomics/func_annots

docs/user_guide/example_genomics/func_annots.rst

@@ -0,0 +1,14 @@
+Functional Annotations
+======================
+
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Table of Contents
+   :glob:
+
+   func_annots/setup
+   func_annots/blast
+   func_annots/interpro
+   func_annots/kegg
+   func_annots/go

docs/user_guide/example_genomics/func_annots/blast.rst

@@ -0,0 +1,175 @@
+Adding BLAST Results
+====================
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../../install_tripal/drupal_home`
+
+
+Adding BLAST Databases
+----------------------
+
+Before we load our BLAST results we want to add some external databases.  For this tutorial we have protein BLAST results against NCBI nr and ExPASy SwissProt.  We would like the BLAST hits to be clickable such that they link back to their respective databases. To do this, we must add some additional databases.  Navigate to **Tripal → Data Loaders → Chado Databases** and click the link titled **Add a Database**. The resulting page provides fields for adding a new database.  Add two new databases, one for NCBI nr and the other for ExPASy SwissProt.
+
+Use these values for adding the NCBI nr database:
+
+.. csv-table::
+  :header: "Field Name", "Value"
+
+  "Name", "NCBI nr"
+  "Description", "NCBI's non-redundant protein database"
+  "URL", "http://www.ncbi.nlm.nih.gov/"
+  "URL Prefix", "http://www.ncbi.nlm.nih.gov/protein/"
+
+Use these values for adding the SwssProt database:
+
+.. csv-table::
+  :header: "Field Name", "Value"
+
+  "Name", "ExPASy Swiss-Prot"
+  "Description", "A curated protein sequence database which strives to provide a high level of annotation, a minimal level of redundancy and high level of integration with other databases"
+  "URL", "http://expasy.org/sprot/"
+  "URL prefix", "http://www.uniprot.org/uniprot/"
+
+
+Configure Parsing of BLAST Results
+----------------------------------
+First, we need to ensure that the BLAST module can properly parse the BLAST hits. To do this, navigate to **Tripal → Extensions → Tripal Blast Analyses**. On this page are configuration settings for the Tripal BLAST Analysis extension module.
+
+Within the section titled BLAST Parsing, you can specify a different, more meaningful name for the sequence library file (a.k.a. database) used for BLASTing. This name will be displayed with BLAST results. You can also provide regular expressions for parsing BLAST hits. For example, the following is a line for a match from SwissProt:
+
+  ::
+
+    sp|P43288|KSG1_ARATH Shaggy-related protein kinase alpha OS=Arabidopsis thaliana GN=ASK1 PE=2 SV=3
+
+
+Here the hit name is ``KSG1_ARATH``, the accession is ``P43288``, the hit description is ``Shaggy-related protein kinase alpha OS=Arabidopsis thaliana`` and the organism is ``Arabidopsis thaliana``. We need regular expressions to tell Tripal how to extract these unique parts from the match text. Because Tripal is a PHP application, the syntax for regular expressions follows the PHP method. Documentation for regular expressions used in PHP can be found here. The following regular expressions can be used to extract the hit name, the accession, hit description and organism for the example SwissProt line above:
+
+.. csv-table::
+  :header: "Element", "Regular Expression"
+
+  "Hit Name", ``^sp\|.*?\|(.*?)\s.*?$``
+  "Hit Description", ``^sp\|.*?\|.*?\s(.*)$``
+  "Hit Accession", ``^sp\|(.*?)\|.*?\s.*?$``
+  "Hit Organism", ``^.*?OS=(.*?)\s\w\w=.*$``
+
+In this tutorial, we will be adding BLAST results for the two databases we just created: ExPASy SwissProt and NCBI nr. First, select ExPASy SwissProt from the drop-down menu. A form will appear:
+
+.. image:: blast1.png
+
+In the form fields, add the following values:
+
+.. csv-table::
+  :header: "Field", "Value"
+
+  "Title for the BLAST analysis", "(leave blank)"
+  "Regular expression for Hit Name", ``^sp\|.*?\|(.*?)\s.*?$``
+  "Regular expression for Hit Description", ``^sp\|.*?\|.*?\s(.*)$``
+  "Regular expression for Hit Accession:", ``^sp\|(.*?)\|.*?\s.*?$``
+  "Regular expression for Organism", ``^.*?OS=(.*?)\s\w\w=.*$``
+  "Organism Name", "(leave blank)"
+
+Click **Save Settings**.
+
+The match accession will be used for building web links to the external database. The accession will be appended to the URL Prefix set earlier when the database record was first created.
+
+Now select the **NCBI nr** database from the drop-down. NCBI databases use a format that is compatible with BLAST. Therefore, the hit name, accession and description are handled differently in the BLAST XML results. To correctly parse results from an NCBI database click the **Use Genbank style parser** checkbox. This should disable all other fields and is all we need for this database.  Clikc the Save Settings button.
+
+Create the Analysis Page
+------------------------
+
+.. note::
+
+  It is always recommended to create an analysis page anytime you import data. The purpose of the analysis page is to describe how the data being added was derived or collected.
+
+Now we can create our analysis page. Navigate to **Content → Tripal Content** and click the **Add Tripal Content** link. This page contains a variety of content types that the site supports.  Scroll to the **Other** section and find the content type named **Blast Results**:
+
+.. image:: blast2.png
+
+Here we can save details about the analysis used to create the BLAST results.  Enter the following in the fields that appear on the page:
+
+.. csv-table::
+  :header: "Field", "Value"
+
+    "Name", "blastx Citrus sinensis v1.0 genes vs ExPASy SwissProt"
+    "Description", "Citrus sinensis mRNA sequences were BLAST'ed against the ExPASy SwissProt protein database using a local installation of BLAST on in-house linux server. Expectation value was set at 1e-6"
+    "BLAST Program", "blastx"
+    "BLAST Version", "2.2.25"
+    "Data Source Name ", "Citrus sinensis mRNA vs ExPASy SwissProt"
+    "Date Performed", "(today's date)"
+
+Click the **Save** button. You can now see our new BLAST analysis page.
+
+.. image:: blast3.png
+
+Create a second Analysis page for the results of the NCBI nr BLAST analysis. Use the following values:
+
+.. csv-table::
+  :header: "Field", "Value"
+
+    "Name", "blastx Citrus sinensis v1.0 genes vs NCBI nr"
+    "Description", "Citrus sinensis mRNA sequences were BLAST'ed against the NCBI non-redundant protein database using a local installation of BLAST on in-house linux server. Expectation value was set at 1e-6"
+    "BLAST Program", "blastx"
+    "BLAST Version", "2.2.25"
+    "Data Source Name ", "Citrus sinensis mRNA vs NCBI nr"
+    "Date Performed", "(today's date)"
+
+
+Import the BLAST XML results
+----------------------------
+First, we will load BLAST results for our citrus gene vs ExPASy SwissProt.  Now that we have our database records setup and configured and we have our analysis record created, we are ready to import the blast results.  To do this, navigate to **Tripal > Data Loaders > Chado BLAST XML results loader**.  The following page will be presented:
+
+.. image:: blast4.png
+
+The top section of this page provides multiple methods for providing results file: via an upload interface, specifying a remote URL or a file path that is local to the server.  Most likely, you will always upload or provide a remote URL.  However, we download the file earlier, and stored them here: ``$DRUPAL_HOME/sites/default/files``.  So, in this case we can use the path on the local server.  Provide the following value for this form:
+
+.. csv-table::
+  :header: "Field", "Value"
+
+  "Server path", "sites/default/files/Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_uniprot_sprot.fasta.out"
+  "Analysis", "blastx Citrus sinensis v1.0 genes vs ExPASy SwissProt (blastall 2.2.25, Citrus sinensis mRNA vs ExPASy SwissProt)"
+  "Database", "ExPASy SwissProt"
+  "BLAST XML File Extension", "out"
+  "Query Type", "mRNA"
+
+.. note::
+
+  For the **Server path** we need not give the full path.  Because we downloaded the files into the Drupal directory we can leave off any preceding path and Tripal will resolve the path.  Otherwise we could provide the full path.
+
+.. note::
+
+  Specifying **ExPASy SwissProt** as the database will allow the importer to use the database configuration settings we entered earlier.
+
+Clicking the **Import BLAST file** will add a job which we can manually execute with the following command:
+
+::
+
+  drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
+
+The results should now be loaded. Now we want to add the results for NCBI nr. Repeat the steps above to add a new analysis with the following details:
+
+.. csv-table::
+  :header: "Field", "Value"
+
+  "Server path", "sites/default/files/Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_nr.out"
+  "Analysis", "blastx Citrus sinensis v1.0 genes vs ExPASy SwissProt (blastall 2.2.25, Citrus sinensis mRNA vs NCBI nr)"
+  "Database", "ExPASy SwissProt"
+  "BLAST XML File Extension", "out"
+  "Query Type", "mRNA"
+
+Click the Save button and manually run the job:
+
+::
+
+  drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
+
+To view results we must find the mRNA that has BLAST hits.  For this example, click on the **mRNA Search** link in the **Data Search** block.  Search for the mRNA named `orange1.1g015615m`.  Viewing the page, we should now see BLAST results by clicking the 'BLAST results' link in the left table of contents.
+
+.. image:: blast5.png
+
+Notice, that when viewing the results, the SwissProt matches are links.  When clicked they redirect the user to the SwissProt website where users can find more information about that protein.
+
+.. image:: blast6.png
+
+.. note::
+
+  The match links are able to link out to SwissProt and NCBI because of the initial setup where we added the database settings and we set regular expressions for parsing the match accessions.

docs/user_guide/example_genomics/func_annots/go.rst

@@ -0,0 +1,2 @@
+Managing Gene Ontology Annotations
+==================================

docs/user_guide/example_genomics/func_annots/interpro.rst

@@ -0,0 +1,80 @@
+Adding InterProScan Results
+===========================
+
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../../install_tripal/drupal_home`
+
+For this tutorial, these results were obtained by using a local installation of InterProScan installed on a computational cluster. However, you may choose to use Blast2GO or the online InterProScan utility. Results should be saved in ``XML`` format.
+
+
+What is InterProScan?
+---------------------
+To learn more about InterProScan, please visit https://www.ebi.ac.uk/interpro/
+
+
+Create the Analysis Page
+-------------------------
+
+  .. note::
+
+    It is always recommended to create an analysis page anytime you import data. The purpose of the analysis page is to describe how the data being added was derived or collected.
+
+Tripal defines the **InterPro Results** Bundle, which is a specific type of Chado analysis.  Create a new record by going to ``Content -> Tripal Content -> Add Tripal Content --> InterPro Results``.
+
+Fill out the fields as described in the table below.
+
+
+.. csv-table::
+  :header: "Field", "Value"
+
+  "Name", "InterPro Annotations of C. sinensis v1.0"
+  "InterPro Program", "InterProScan"
+  "InterPro Version", "4.8"
+  "Date Performed", "Current Date"
+  "Data Source Name", "C. sinensis v1.0 mRNA"
+  "Data Source Version", "v1.0"
+  "Data Source URI", "n/a"
+  "Description", "Materials & Methods: C. sinensis mRNA sequences were mapped to IPR domains and GO terms using a local installation of InterProScan executed on a computational cluster. InterProScan date files used were MATCH_DATA_v32, DATA_v32.0 and PTHR_DATA v31.0."
+
+Press the **Save** button.
+
+Import the InterProScan XML results
+------------------------------------
+
+
+Next, we will load InterProScan results for our citrus gene.  To do this, navigate to **Tripal > Data Loaders > Chado InterProScan XML results loader**.  The following page will be presented:
+
+.. image:: interpro1.png
+
+The top section of this page provides multiple methods for providing results file: via an upload interface, specifying a remote URL or a file path that is local to the server.  Most likely, you will always upload or provide a remote URL.  However, we downloaded the files earlier, and stored them here: ``$DRUPAL_HOME/sites/default/files``.  So, in this case we can use the path on the local server.  Provide the following value for this form:
+
+.. csv-table::
+  :header: "Field", "Value"
+
+  "Server path", "sites/default/files/Citrus_sinensis-orange1.1g015632m.g.iprscan.xml"
+  "Analysis", "InterPro Annotations of C. sinensis v1.0"
+  'Load GO terms to the database', 'unchecked'
+  "Query Name RE", ""
+  "Use Unique Name", "unchecked"
+  "Query Type", "mRNA"
+
+In order for GO terms to be imported, the Gene Ontology must be loaded on your site: for this tutorial, we leave the box unchecked.
+
+
+.. note::
+
+  For the **Server path** we need not give the full path.  Because we downloaded the files into the Drupal directory we can leave off any preceding path and Tripal will resolve the path.  Otherwise we could provide the full path.
+
+
+
+Clicking the **Import InterProScan file** will add a job which we can manually execute with the following command:
+
+::
+
+    drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
+
+
+After the job is run, our InterPro field will be populated on the mRNA page with an annotation diagram:
+
+.. image:: interpro2.png

docs/user_guide/example_genomics/func_annots/kegg.rst

@@ -0,0 +1,2 @@
+Adding KEGG Results
+===================

docs/user_guide/example_genomics/func_annots/setup.rst

@@ -0,0 +1,73 @@
+Module Setup
+============
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../../install_tripal/drupal_home`
+  
+  
+For this example we will be load functional data for our gene. To do this we will use the Blast, KEGG, and InterPro extension modules. However, these extension modules are not part of the "core" Tripal package but are available as separate extensions.  Anyone may create extensions for Tripal.  These extensions are useful for genomic data and therefore are included in this tutorial. 
+
+To download these modules:
+
+  ::
+  
+    cd $DRUPAL_HOME    
+    drush pm-download tripal_analysis_blast
+    drush pm-download tripal_analysis_kegg
+    drush pm-download tripal_analysis_interpro
+
+Now, enable these extension modules:
+
+  ::
+  
+    drush pm-enable tripal_analysis_blast
+    drush pm-enable tripal_analysis_interpro
+    drush pm-enable tripal_analysis_kegg
+
+For this example, we will use the following files which are available for downloading:
+
+- `Citrus_sinensis-orange1.1g015632m.g.iprscan.xml <http://www.gmod.org/mediawiki/images/0/0c/Citrus_sinensis-orange1.1g015632m.g.iprscan.xml>`_
+- `Citrus_sinensis-orange1.1g015632m.g.KEGG.heir.tar.gz <http://www.gmod.org/mediawiki/images/1/13/Citrus_sinensis-orange1.1g015632m.g.KEGG.heir.tar.gz>`_
+- `Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_uniprot_sprot.fasta.out <http://www.gmod.org/mediawiki/images/e/e8/Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_uniprot_sprot.fasta.out>`_
+- `Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_nr.out <http://www.gmod.org/mediawiki/images/2/24/Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_nr.out>`_
+
+Download these files to the ```$DRUPAL_HOME/sites/default/files``` directory. To do so quickly run these commands:
+
+  ::
+  
+    cd $DRUPAL_HOME/sites/default/files
+    wget http://www.gmod.org/mediawiki/images/0/0c/Citrus_sinensis-orange1.1g015632m.g.iprscan.xml
+    wget http://www.gmod.org/mediawiki/images/1/13/Citrus_sinensis-orange1.1g015632m.g.KEGG.heir.tar.gz
+    wget http://www.gmod.org/mediawiki/images/e/e8/Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_uniprot_sprot.fasta.out
+    wget http://www.gmod.org/mediawiki/images/2/24/Blastx_citrus_sinensis-orange1.1g015632m.g.fasta.0_vs_nr.out
+
+Each of these modules provides new fields for both the **gene** and **mRNA** content types.  To add these new field to those content types, navigate to **Structure > Tripal Content Types** and click the **manage fields** link in the row for the **mRNA** content type.  Click the link titled **Check for new fields**.  After a few moments the page will refresh and you will be notified that new fields have been added.
+
+.. image:: setup1.png
+
+Next, we need to position the new field. Using the skills you learned in the :doc:`../../content_types/configuring_page_display` Create three new **Tripal Panes** named:
+
+- Blast Results
+- Protein Domains
+- KEGG Pathways
+
+Be sure to:
+
+- Place the three new fields into each pane respectively 
+- Move the Panes out of the **disabled** section. 
+- Set the label for each field to **Hidden**.
+
+The following shows an example of this layout:
+
+.. image:: setup2.png
+
+The fields are now ready for display once data is added!  
+
+.. note::
+
+   If you want both the **Gene** and **mRNA** content type to have BLAST, InterPro and KEGG result fields you must repeat the steps above for both.
+
+.. note::
+
+  Anytime you install a Tripal v3 extension module you should check for new fields, and then place those fields in the layout.  Extension modules often will not do this for you because they do not assume you want these new fields.
+  

docs/user_guide/example_genomics/organisms.rst

@@ -48,7 +48,7 @@ Click the checbox beside the 'Import taxonomy for existing species' and click Su
 
 ::
 
-  drush trp-run-jobs --username=administrator --root=/var/www/html
+  drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
 
 You will see the following output:
 

docs/user_guide/example_genomics/pub_import.rst

@@ -1,5 +1,9 @@
 Importing Publications
 ======================
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../install_tripal/drupal_home`
+  
 Tripal provides an interface for automatically and manually adding publications.
 
 Manually Adding a Publication
@@ -81,7 +85,7 @@ Next, there are two ways to import these publications. The first it to manually
 
 ::
 
-  cd /var/www/html
+  cd $DRUPAL_HOME
   drush trp-import-pubs --username=administrator
 
 You should see output to the terminal that begins like this:
@@ -105,7 +109,7 @@ Some things to know about the publication importer:
 
   ::
 
-    cd /var/www/html
+    cd $DRUPAL_HOME
     drush trp-run-jobs --user=administrator
 
 The second way to import publications is to add an entry to the UNIX cron. We did this previously for the Tripal Jobs management system when we first installed Tripal. We will add another entry for importing publications. But first, now that we have imported all of the relevant pubs, we need to return to the importers list at **Tripal → Data Loaders → Chado Publication Importers** and disable the first importer we created. We do not want to run that importer again, as we've already imported all historical publications on record at PubMed. Click the edit button next to the importer named Pubs for Citrus sinensis, click the disable checkbox and then save the template. The template should now be disabled.
@@ -120,11 +124,12 @@ Now add the following line to the bottom of the crontab:
 
 ::
 
-  30 8 1,15 * *  su - www-data -c '/usr/local/drush/drush -r /var/www/html -l http://[site url] trp-import-pubs --report=[your email] > /dev/null'
+  30 8 1,15 * *  su - www-data -c '/usr/local/drush/drush -r [DRUPAL_HOME] -l http://[site url] trp-import-pubs --report=[your email] > /dev/null'
 
 Where
 
 - [site url] is the full URL of your site
 - [your email] is the email address of the user that should receive an email containing a list of publications that were imported. You can separate multiple email addresses with a comma.
+- [DRUPAL_HOME] is the directory where Drupal is installed
 
 The cron entry above will launch the importer at 8:30am on the first and fifteenth days of the month. We will run this importer twice a month in the event it fails to run (e.g. server is down) at least one time during the month.

docs/user_guide/file_management.rst

@@ -0,0 +1,19 @@
+File Management
+===============
+
+User Quotas
+-----------
+Data importers that use the Tripal API and Tripal supported widgets automatically associate uploaded files with users. If you are allowing end-users to upload files you may want to consider adding quotas to prevent the server storage from filling.  To ensure that users do not exceed the limits of the server a quota system is available.  Navigate to **Administer > Tripal > User File Management** and click the **User Quotas** tab to reveal the following page:
+
+.. image:: ./file_management.user_quotas.1.png
+
+First, the total amount of space consumed by all uploaded files is shown at the top of the page.  Initially this will indicate 0 B (for zero bytes); as users upload files this value will change.  You may return to this page in the future to check how much space is currently used by user uploads. Here you can also specify the default system-wide quota that all users receive.  By default this is set to 64 Megabytes and an expiration of 60 days.  Once a file has existed on the site for 60 days the file is marked for deletion and will be removed when the Drupal cron is executed.  The default of 64MB per user is most likely too small for your site.  Adjust this setting and the days to expire as appropriate for your site's expected number of users and storage limitations and click the **Save** button to preserve any changes you have made.
+
+In addition to the default settings for all users, you may want to allow specific users to have a larger (or perhaps smaller) quota.  You can set user-specific quotas by clicking the **Add Custom User Quota** link near the bottom of the page.   The following page appears:
+
+.. image:: ./file_management.user_quotas.2.png
+
+
+Here you must specify the Drupal user name of the user who should be granted a custom quota.  This field will auto populate suggestions as you type to help you find the correct username.  Enter the desired quota size and expiration days and click the **Submit** button. you will then see the user-specific quota listed in the table at the bottom of the page:
+
+.. image:: ./file_management.user_quotas.3.png

docs/user_guide/install_tripal.rst

@@ -8,6 +8,7 @@ Install Tripal
    :glob:
 
    ./install_tripal/pre_planning
+   ./install_tripal/drupal_home
    ./install_tripal/server_setup
    ./install_tripal/drush_installation
    ./install_tripal/rapid_install

docs/user_guide/install_tripal/automating_job_execution.rst

@@ -1,6 +1,10 @@
 Automating Job Execution
 ========================================
 
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`./drupal_home`
+
 The Drupal cron is used to automatically execute necessary Drupal housekeeping tasks on a regular interval.  You should *always* setup the Drupal cron to ensure your site checks for updates and security issues.  To do this, we want to integrate Drupal cron with the UNIX cron facility.  The UNIX cron will automatically execute commands on set regular intervals.  First, we must get the appropriate URL for the cron by navigating to **Configuration → Cron**. On this page you will see a link that we will use for cron:
 
 .. image:: automating_job_execution.cron.png
@@ -36,9 +40,9 @@ Any job that is added to the Job's system can be run manually on the command lin
 
 .. code-block:: bash
 
-  drush trp-run-jobs --username=administrator --root=/var/www/html
+  drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
 
-Remember to change the username from **administrator** to the name of the administrator on your site and change **/var/www/html** to the location where your site installed on the server.
+Remember to change the username from **administrator** to the name of the administrator on your site.
 
 Option #2: Additional Cron Entry
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -53,7 +57,7 @@ Add this line to the crontab:
 
 .. code-block:: bash
 
-  0,5,10,15,20,25,30,35,40,45,50,55 * * * * drush trp-run-jobs --username=administrator --root=/var/www/html
+  0,5,10,15,20,25,30,35,40,45,50,55 * * * * drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
 
 Here, job execution will occur every 5 minutes.
 

docs/user_guide/install_tripal/drupal_home.rst

@@ -0,0 +1,13 @@
+DRUPAL_HOME Variable
+====================
+An important convention in this document is the use of the ``$DRUPAL_HOME`` environment variable.  If you are new to UNIX/Linux you can learn about environment variables `here <https://www.tutorialspoint.com/unix/unix-environment.htm>`_.  Drupal is a necessary depenency of Tripal.  The setup and installation sections describe how to install Drupal.  If you follow the instructions exactly as described in this User's Guide you will install Drupal into ``/var/www/html``. However, some may desire to install Drupal elsewhere.  To ensure that all command-line examples in this guide can be cut-and-pasted you **must** set the ``$DRUPAL_HOME`` variable.  You can set the variable in the following way:
+
+  .. code-block:: bash
+
+    DRUPAL_HOME=/var/www/html
+    
+Be sure to change the path ``/var/www/html`` to the location where you have installed Drupal.  If you have never installed Drupal and you intend on following this guide step-by-step then use the command-line above to get started.
+
+.. note::
+
+  You will have to set the ``$DRUPAL_HOME`` environment variable anytime you open a new terminal window.

docs/user_guide/install_tripal/manual_install/install_drupal.rst

@@ -33,29 +33,32 @@ We no longer need to be the postgres user so exit
 Software Installation
 ---------------------
 
-We want to install Drupal into our web document root (/var/www/html).   Before we can install Drupal we must ensure that that we are allowed to add files into the /var/www/html directory.  Select a user account that will be the owner of all web files and change the owner of the /var/www/html directory to that user:
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../drupal_home`
+
+
+Before we can install Drupal we must ensure that that we are allowed to add files into the root directory.  Select a user account that will be the owner of all web files and change the owner of the ``$DRUPAL_HOME`` directory to that user:
 
 .. code-block:: bash
 
-  sudo chown -R [user] /var/www/html
+
+  sudo chown -R [user] $DRUPAL_HOME
 
 Substitute [user] for the name of the user that will own the web files.
 
 
 .. note::
 
-  The apache web server runs as the user 'www-data'.  For security reasons you should chose a user other than 'www-data' to be the owner of the /var/www/html directory.
+  The apache web server runs as the user 'www-data'.  For security reasons you should chose a user other than 'www-data' to be the owner of the Drupal root directory.
 
-Tripal 3.x requires version 7.x of Drupal. Drupal can be freely downloaded from the http://www.drupal.org website. At the writing of this Tutorial the most recent version of Drupal 7 is version 7.59. The software can be downloaded manually from the Drupal website through a web browser or we can use the 'wget' command to retrieve it:
+Tripal 3.x requires version 7.x of Drupal. Drupal can be freely downloaded from the http://www.drupal.org website. At the writing of this Tutorial the most recent version of Drupal 7 is version 7.59. The software can be downloaded manually from the Drupal website through a web browser or we can use the ``wget`` command to retrieve it:
 
 .. code-block:: bash
 
-  cd /var/www/html
+  cd $DRUPAL_HOME
   wget http://ftp.drupal.org/files/projects/drupal-7.59.tar.gz
 
-.. note::
-
-  If you are using older version of Ubuntu the web root directory may be /var/www rather than /var/www/html and you may need to change the path accordingly.
 
 Next, we want to install Drupal. We will use the tar command to uncompress the software:
 
@@ -78,11 +81,11 @@ If an index.html file is present (as is the case with Ubuntu installations) you
 
 .. note::
 
-  It is extremely important the the hidden file .htaccess is also moved (note the second 'mv' command above. Check to make sure this file is there
+  It is extremely important the the hidden file ``.htaccess`` is also moved (note the second ``mv`` command above. Check to make sure this file is there:
 
-.. code-block:: bash
+  .. code-block:: bash
 
-  ls -l .htaccess
+    ls -l .htaccess
 
 Configuration File
 ------------------
@@ -93,15 +96,15 @@ First navigate to the location where the configuration file should go:
 
 .. code-block:: bash
 
-  cd /var/www/html/sites/default/
+  cd $DRUPAL_HOME/sites/default/
 
-Next, copy the example configuration that already exists in the directory to be our actual configuration file by renaming it to settings.php.
+Next, copy the example configuration that already exists in the directory to be our actual configuration file by renaming it to ``settings.php``.
 
 .. code-block:: bash
 
   cp default.settings.php settings.php
 
-Now, we need to edit the configuration file to tell Drupal how to connect to our database server. To do this we'll use an easy to use text editor gedit
+Now, we need to edit the configuration file to tell Drupal how to connect to our database server. To do this we'll use an easy to use text editor **gedit**.
 
 .. code-block:: bash
 
@@ -127,17 +130,19 @@ and then insert the following array just after the above line:
   );
 
 Replace the text '********' with your database password for the user 'drupal' created previously.  Save the configuration file and close the editor.
-Files directory creation
 
-Finally, we need to create the directory where Drupal will have write-access to add files.  By default, Drupal expects to have write permission in the /var/www/html/sites/default/files directory.  Therefore, we will set group ownership of the directory to the group used by the Apache web server.  This will be the user that Drupal uses to write files.
+Files Directory Creation
+--------------------------
+
+Finally, we need to create the directory where Drupal will have write-access to add files.  By default, Drupal expects to have write permission in the ``$DRUPAL_HOME/sites/default/files`` directory.  Therefore, we will set group ownership of the directory to the group used by the Apache web server.  This will be the user that Drupal uses to write files.
 
 .. code-block:: bash
 
-  mkdir -p /var/www/html/sites/default/files
-  sudo chgrp [group] /var/www/html/sites/default/files
-  sudo chmod g+rw /var/www/html/sites/default/files
+  mkdir -p $DRUPAL_HOME/sites/default/files
+  sudo chgrp [group] $DRUPAL_HOME/sites/default/files
+  sudo chmod g+rw $DRUPAL_HOME/sites/default/files
 
-Substitute [group] for the name of the web server's group.  In Ubuntu this is www-data in CentOS this is apache.The above commands creates the directory, sets the group ownership for group. and gives read/write permissions to the group on the directory.
+Substitute [group] for the name of the web server's group.  In Ubuntu this is www-data in CentOS this is apache. The above commands creates the directory, sets the group ownership for group, and gives read/write permissions to the group on the directory.
 
 Web-based Steps
 ---------------

docs/user_guide/install_tripal/manual_install/install_prereqs.rst

@@ -1,13 +1,18 @@
 Tripal Prerequisites
 ====================
 
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../drupal_home`
+
+
 Tripal v3.x requires several Drupal modules. These include  `Entity <https://www.drupal.org/project/entity>`_,  `Views <https://www.drupal.org/project/views>`_, `CTools <https://www.drupal.org/project/ctools>`_, `Display Suite <https://www.drupal.org/project/ds>`_, `Field Group <https://www.drupal.org/project/field_group>`_, `Field Group Table <https://www.drupal.org/project/field_group_table>`_, `Field Formatter Class <https://www.drupal.org/project/field_formatter_class>`_ and `Field Formatter Settings <https://www.drupal.org/project/field_formatter_settings>`_ modules.   Modules can be installed using the graphical Drupal website by clicking on the Modules link in the top adminstrative menu bar.  Instructions for instaling Modules via the web-interface can be found here:  https://www.drupal.org/documentation/install/modules-themes/modules-7. However, Drush can be quicker for module installation. The following instructions will show how to install a module using the Drush command-line tool.
 
 First, install the Entity module.  We will download the current version using the drush command. On the command-line, execute the following:
 
 .. code-block:: bash
 
-  cd /var/www/html/sites/all/modules
+  cd $DRUPAL_HOME/sites/all/modules
   drush pm-download entity
 
 Typically for all module installation we should check the README for additional installation instructions. Next, enable the module using a drush command:
@@ -23,16 +28,23 @@ For basic Tripal functionality you must also enable the Views and CTools modules
   drush pm-download views ctools
   drush pm-enable views views_ui ctools
 
-Finally, Tripal works best when it can provide default display layouts.   To support default layouts you must also enable the remainig dependencies:
+Finally, Tripal works best when it can provide default display layouts.   To support default layouts you must also enable the remaining dependencies:
 
 .. code-block:: bash
 
   drush pm-download ds field_group field_group_table field_formatter_class field_formatter_settings
   drush pm-enable ds field_group field_group_table field_formatter_class field_formatter_settings
 
-Optionally, you can install the ckeditor module.  This module provides a nice WYSIWYG editor that allows you to edit text on your site using a graphical editor. Otherwise, if you need images or formatting (e.g. underline, bold, headers) you would be required to write HTML.   It is recommended that this module be installed to improve the user experience:
+Optionally, you can install the ckeditor module.  This module provides a nice WYSIWYG editor that allows you to edit text on your site using a graphical editor. Otherwise, if you need images or formatting (e.g. underline, bold, headers) you would be required to write HTML.  It is recommended that this module be installed to improve the user experience:
 
 .. code-block:: bash
 
   drush pm-download ckeditor
   drush pm-enable ckeditor
+  
+Finally, we need an more recent version of JQuery that what comes with Drupal.  We can get this by installing the JQuery update module.
+
+.. code-block:: bash
+
+  drush pm-download jquery_update
+  drush pm-enable jquery_update

docs/user_guide/install_tripal/manual_install/install_tripal.rst

@@ -1,6 +1,11 @@
 Tripal Installation
 ===================
 
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`../drupal_home`
+
+
 Before installation of Tripal, you must first have a working Drupal installation.  Please see the previous section of this tutorial for step-by-step examples for server setup and Drupal installation instructions.  After installation of Tripal, you may install any Tripal extension modules you may want.
 
 Download Tripal
@@ -24,15 +29,15 @@ A bug exists in Drupal related to the bytea data type in PostgreSQL. At the writ
 
 .. code-block:: bash
 
-  cd /var/www/html
+  cd $DRUPAL_HOME
   wget --no-check-certificate https://drupal.org/files/drupal.pgsql-bytea.27.patch
   patch -p1 < drupal.pgsql-bytea.27.patch
 
-There is also a bug in the Drupal Views 3.0 code that prevents Tripal's administrative and search data views from functioning. The patch is provided within the tripal_veiws module. To apply the patch execute the following:
+There is also a bug in the Drupal Views 3.0 code that prevents Tripal's administrative and search data views from functioning. The patch is provided within the tripal_views module. To apply the patch execute the following:
 
 .. code-block:: bash
 
-  cd /var/www/html/sites/all/modules/views
+  cd $DRUPAL_HOME/sites/all/modules/views
   patch -p1 < ../tripal/tripal_chado_views/views-sql-compliant-three-tier-naming-1971160-30.patch
 
 Install Tripal
@@ -74,7 +79,7 @@ Jobs in the queue can be executed using drush to manually launch the job:
 
 .. code-block:: bash
 
-  drush trp-run-jobs --username=administrator --root=/var/www/html
+  drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
 
 As the installation of Chado proceeds, we should see output on the terminal console indicating the progress of the installation.  You should see output similar to the following:
 
@@ -108,7 +113,7 @@ To prepare the site click the button Prepare this site.   A new job is added to
 
 .. code-block:: bash
 
-  drush trp-run-jobs --username=administrator --root=/var/www/html
+  drush trp-run-jobs --username=administrator --root=$DRUPAL_HOME
 
 .. note::
 
@@ -125,4 +130,4 @@ Preparing Chado and Drupal in a previous step resulted in the automatic creation
 
 .. image:: install_tripal.install7.png
 
-Review these permissions and set them according to how you want content to be managed.   Typically, the administrator user receives all permissions, and anonymous and authenticated users receive 'View' permissions for all content types.  If you desire to create other types of users, Drupal allows you to do this by creating new types of roles.  For example, if you know that some users will be responsible for curating content, then you may add a curator role by clicking the Roles link in the top right corner of this permissions page.  After the new role is created you can return to the permission page to set the permissions accordingly.
+Review these permissions and set them according to how you want content to be managed.  Typically, the administrator user receives all permissions, and anonymous and authenticated users receive 'View' permissions for all content types.  If you desire to create other types of users, Drupal allows you to do this by creating new types of roles.  For example, if you know that some users will be responsible for curating content, then you may add a curator role by clicking the **Roles** link in the top right corner of this permissions page.  After the new role is created you can return to the permission page to set the permissions accordingly.

docs/user_guide/install_tripal/rapid_install.rst

@@ -1,8 +1,15 @@
 Installation Method #1: Rapid Installation
 ==========================================
 
-Before installing via the rapid installation process please ensure drush is installed, and the server is setup.    Rapid Installation works with Tripal v3.0-rc2 (release candidate 2) and later.   If you are using a previous version of Tripal, please proceed to the step-by-step instructions.
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`./drupal_home`
+
+
+Before installing via the rapid installation process please ensure drush is installed, and the server is setup.   Rapid Installation works with Tripal v3.0-rc2 (release candidate 2) and later.  If you are using a previous version of Tripal, please proceed to the step-by-step instructions.
+
 Database Setup
+---------------
 
 Before we can install Tripal we must have a database ready for it.  In the server setup instructions were provided to set up a PostgreSQL database server. Now, we need to create the Drupal database. To do so we must first become the PostgreSQL user.
 
@@ -10,7 +17,7 @@ Before we can install Tripal we must have a database ready for it.  In the serve
 
   sudo su - postgres
 
-Next, create the new 'drupal' user account. This account will not be a "superuser' nor allowed to create new roles, but should be allowed to create a database.
+Next, create the new 'drupal' user account. This account will not be a "superuser" nor allowed to create new roles, but should be allowed to create a database.
 
 .. code-block:: bash
 
@@ -31,17 +38,17 @@ We no longer need to be the postgres user so exit
 Tripal Installation
 -------------------
 
-Navigate to the directory you want to create the website. For this example it will be /var/www/html (the typical home location for Ubuntu and CentOS)
+Navigate to your Drupal install directory.
 
 .. code-block:: bash
 
-  cd /var/www/html
+  cd $DRUPAL_HOME
 
 .. note::
 
   Make sure you have write permissions within this directory.
 
-Clone the tripal_install project using the git command and move the contents up one level into the web document directory:
+Clone the tripal_install project using the ``git`` command and move the contents up one level into the web document directory:
 
 .. code-block:: bash
 
@@ -70,7 +77,7 @@ From this point onward, you will be asked a series of questions in the terminal
      Administrator password: P@55w0rd
   Is this information correct? (y/n): y
 
-Next, you will be asked for the database information: database name, database  username, database  user password, host, and port.  The database name and user should match what you created in the previous section (i.e. database name = 'drupal' and database user = 'drupal').  The 'host' is the name of the server or its IP address, and the port is a numerical value that PostgreSQL uses for communication.  By default PostgreSQL uses the port 5432.  If a mistake is made you can make corrections as shown in the following screenshot:
+Next, you will be asked for the database information: database name, database  username, database  user password, host, and port.  The database name and user should match what you created in the previous section (i.e. database name = 'drupal' and database user = 'drupal').  The 'host' is the name of the server or its IP address, and the port is a numerical value that PostgreSQL uses for communication.  By default PostgreSQL uses the port 5432.  If a mistake is made you can make corrections as shown below:
 
 ::
 

docs/user_guide/install_tripal/upgrade_from_tripal2.rst

@@ -44,7 +44,7 @@ Step 1: Upgrade Tripal
 
     drush pm-disable tripal_core
 
-4.  The Tripal modules must also be downloaded and updated. To do this, delete the old Tripal v2 modules directories, located in ``sites/all/modules`` from your Drupal root:  for example ``/var/www/html/sites/all/modules``(be sure you have a backup before removing). The following command will retrieve the Tripal 3 version:
+4.  The Tripal modules must also be downloaded and updated. To do this, delete the old Tripal v2 modules directories, located in ``sites/all/modules`` from your Drupal root:  for example ``/var/www/html/sites/all/modules`` (be sure you have a backup before removing). The following command will retrieve the Tripal 3 version:
 
   .. code-block:: bash
 
@@ -137,11 +137,11 @@ The process allows you to create Tripal 3 content types exposing the same data a
 
 4. Select the checkbox beside each Tripal v3 type you would like to create. The number of entities/pages that will be created for that content type is shown in brackets beside the name.
 
-5. Then click the "Migrate [Tripal v2 Type]" button. This will submit a Tripal job to create the requested content. Submit this job manually on the command-line as follows:
+5. Then click the "Migrate [Tripal v2 Type]" button. This will submit a Tripal job to create the requested content. Submit this job manually on the command-line as follows (note we ``cd`` to the project root at ``/var/www/html``: please navigate to wherever your site is installed):
 
   .. code-block:: bash
 
-    cd /var/www/html
+    cd $DRUPAL_HOME
     drush trp-run-jobs --user=administrator
 
 6. Now repeat 1-5 for each content type. Since this step simply creates new Tripal v3 content without touching the existing Tripal v2 content, there really is no reason not to migrate all your content types. Especially since the Tripal v3 content remains private and thus hidden from your users.

docs/user_guide/job_management.rst

@@ -1,6 +1,11 @@
 Job Management (Tripal Daemon)
 ==============================
 
+.. note::
+
+  Remember you must set the $DRUPAL_HOME environment variable to cut-and-paste the commands below. See see :doc:`./install_tripal/drupal_home`
+
+
 The Tripal Daemon module is meant to provide a simple means of creating a robust command-line-driven, fully bootstrapped PHP Daemon. It uses the PHP-Daemon (https://github.com/shaneharter/PHP-Daemon) Library to create the Daemon (via the Libraries API) in order to not re-invent the wheel. It allows you to execute Jobs submitted to Tripal without using cron.  It provides a faster user experience for running jobs.  Prior to Tripal v3, the Tripal Daemon module was an extension module. It was integrated into the core Tripal pacakge.
 
 Features
@@ -27,7 +32,7 @@ Next, we need the `PHP-Daemon Library version 2.0 <https://github.com/shaneharte
 
 .. code-block:: shell
 
-  cd /var/www/html/sites/all/libraries
+  cd $DRUPAL_HOME/sites/all/libraries
   wget https://github.com/shaneharter/PHP-Daemon/archive/v2.0.tar.gz
   tar -zxvf v2.0.tar.gz
   mv v2.0.tar.gz PHP-Daemon

docs/user_guide/mviews.rst

@@ -1,6 +1,10 @@
 Materialized Views
 ==================
 
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`./install_tripal/drupal_home`
+
 Chado is efficient as a data warehouse but queries can become slow depending on the type of query. To help simplify and speed up these queries, materialized views can be employed. For a materialized view, a new database table is created and then populated with the results of a pre-defined SQL query. This allows you to execute a much simpler and faster query on the materialized view when producing user pages. A side effect, however is redundant data, with the materialized view becoming stale if not updated regularly.
 
 Tripal provides a mechanism for populating and updating these materialized views. These can be found on the **Tripal → Data Storage → Chado -> Materialized Views** page.
@@ -13,7 +17,7 @@ This will submit jobs to populate the views with data. Now, run the jobs:
 
 .. code-block:: shell
 
-  cd /var/www/html
+  cd $DRUPAL_HOME
   drush trp-run-jobs --user=administrator
 
 You can now see that all views are up-to-date on the **Materialized Views Page**. The number of rows in the view table is shown.

docs/user_guide/searching/default_pages.rst

@@ -3,3 +3,12 @@ Tripal Content-Specific Search Tools
 
 
 By default, Tripal will provide a search tool for every Tripal content type.  When a new content type is created, a new search tool is automatically created for that tool.
+
+These search tools will be available at ``/data_search/[content label]``, such as ``/data_search/mrna``.
+
+If you have the ``view_ui`` module enabled, you can find a list of all search views under **Structure --> Views**.
+
+.. figure:: ./default_pages.1.png
+  :alt: An example mRNA search
+
+  An example search with the default mRNA content type.  Results are sortable by clicking the column name.

docs/user_guide/web_services.rst

@@ -1,6 +1,10 @@
 Web Services
 ============
 
+.. note::
+
+  Remember you must set the ``$DRUPAL_HOME`` environment variable if you want to cut-and-paste the commands below. See :doc:`./install_tripal/drupal_home`
+
 Overview
 --------
 
@@ -31,7 +35,7 @@ To enable web services, simply install the ``tripal_ws`` module, either using th
 
 .. code-block:: shell
 
-  cd /var/www/html
+  cd $DRUPAL_HOME
   drush pm-enable tripal_ws
 
 Exploring Web Services

legacy/tripal_analysis/tripal_analysis.info

@@ -3,7 +3,7 @@ description = Supports the companalyses tables of Chado by providing pages for v
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 configure = admin/tripal/legacy/tripal_analysis/configuration
 
 dependencies[] = tripal_core

legacy/tripal_contact/tripal_contact.info

@@ -3,7 +3,7 @@ description = Supports the contact tables of Chado by providing pages for viewin
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 dependencies[] = tripal_core
 dependencies[] = tripal_chado_views

legacy/tripal_core/tripal_core.info

@@ -3,7 +3,7 @@ description = Provides support for all Tripal modules and includes the Tripal AP
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 configure = admin/tripal
 
 stylesheets[all][] = theme/css/tripal_core.css

legacy/tripal_cv/tripal_cv.info

@@ -3,7 +3,7 @@ description = Supports the Controlled Vocabulary (CV) tables of Chado by providi
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 configure = admin/tripal/vocab
 
 dependencies[] = tripal_core

legacy/tripal_db/tripal_db.info

@@ -3,7 +3,7 @@ description = Supports the database cross-reference tables of Chado by providing
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 configure = admin/tripal/legacy/tripal_db
 
 dependencies[] = tripal_core

legacy/tripal_feature/tripal_feature.info

@@ -3,7 +3,7 @@ description = Supports the sequence (feature) tables of Chado by providing pages
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 stylesheets[all][] = theme/css/tripal_feature.css
 scripts[]          = theme/js/tripal_feature.js

legacy/tripal_featuremap/tripal_featuremap.info

@@ -3,7 +3,7 @@ description = Supports the map tables of Chado by providing pages for viewing an
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 dependencies[] = tripal_core
 dependencies[] = tripal_chado_views

legacy/tripal_genetic/tripal_genetic.info

@@ -3,7 +3,7 @@ description = Supports the genetic tables of Chado by providing pages for viewin
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 dependencies[] = tripal_core
 dependencies[] = tripal_chado_views

legacy/tripal_library/tripal_library.info

@@ -3,7 +3,7 @@ description = Supports the library tables of Chado by providing pages for viewin
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 dependencies[] = tripal_core
 dependencies[] = tripal_chado_views

legacy/tripal_natural_diversity/tripal_natural_diversity.info

@@ -3,7 +3,7 @@ description = Supports the natural diversity (ND) tables of Chado by providing p
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 dependencies[] = tripal_core
 dependencies[] = tripal_chado_views

legacy/tripal_organism/tripal_organism.info

@@ -3,7 +3,7 @@ description = Supports the organism tables of Chado by providing pages for viewi
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 configure = admin/tripal/legacy/tripal_organism
 
 stylesheets[all][] = theme/css/tripal_organism.css

legacy/tripal_phenotype/tripal_phenotype.info

@@ -3,7 +3,7 @@ description = Supports the phenotype tables of Chado by providing pages for view
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 dependencies[] = tripal_core
 dependencies[] = tripal_chado_views

legacy/tripal_phylogeny/tripal_phylogeny.info

@@ -3,7 +3,7 @@ description = Supports the phylogeny tables of Chado by providing pages for view
 core = 7.x
 project = tripal_phylogeny
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 dependencies[] = tripal_core
 dependencies[] = tripal_cv
 dependencies[] = tripal_db

legacy/tripal_project/tripal_project.info

@@ -3,7 +3,7 @@ description = Supports the project tables of Chado by providing pages for viewin
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 configure = admin/tripal/legacy/tripal_project
 
 dependencies[] = tripal_core

legacy/tripal_pub/tripal_pub.info

@@ -3,7 +3,7 @@ description = Supports the pub (publication) tables of Chado by providing pages
 core = 7.x
 project = tripal
 package = Tripal v2 Legacy
-version = 7.x-3.0-rc2
+version = 7.x-3.0
 
 stylesheets[all][] = theme/css/tripal_pub.css