LIMS Editor (LIME) User Guide

Overview

The LIMS Editor (LIME) program is a Web-based application that allows users to perform sample and data editing tasks in the Laboratory Information Management System (LIMS) database. As the data in the International Ocean Discovery Program (IODP) LIMS are complex and have specific relationships, it is important to be familiar with the data structure before attempting to use this program. For that reason, the capabilities of LIME are configured so that each user can have no, little, or high access to the functions of the program. As a user becomes more familiar with the LIMS and with LIME, additional access can be granted. Access is controlled through an authorization tool.

LIMS Database Basics

LIMS is an Oracle database that stores science data gathered from the JOIDES Resolution as well as from the Gulf Coast Repository (GCR). A graphical representation of the basic table structure is shown below in Figure 1. It is built around a sample-based hierarchy, meaning that all data are referenced to specific samples. The production databases include SHIP and SHORE instances of LIMS. There is also a test database on ship (SHIPTEST) and shore (RTLIMS) used to ensure applications are ready for the production environment.

An ancillary Oracle database handles file assets, such as uploaded images or Excel spreadsheets. This additional database is known as the “Asset Manager,” or ASMAN database. The unique ASMAN ID number is used by the LIMS database to reference assets in this specialized database.

Figure 1. LIMS Database Structure

The LIME program can be used to edit data in the SAMPLE and TEST tables. In this document, references to the database tables are upper case (e.g., SAMPLE), whereas references to data in these tables are lowercase (e.g., sample).

LIMS Database Tables

SAMPLE Table and Parentage

Samples can be of many different types, such as a core, a liquid sample, or even the hole itself. All samples are related to other samples by parentage (e.g., cores are children of holes, sections are children of cores, section halves are children of sections, etc.). Many layers of parentage can exist down to the bottom of a given hierarchy tree. Holes are at the top of each parentage tree, so in the database they have a default “parent” sample_number = 0. (LIME cannot assign samples to this default parent.) Site and expedition information are metadata about the hole; these two parameters are not part of the parentage.

In LIME, operations on samples must take the parentage hierarchy into account, and in many cases must follow the parentage tree to the bottom of each and every branch. This can be true if a sample is canceled, edited, or moved from one part of a parentage tree to another (reparenting).

For example, if a section is canceled using LIME, the program cancels the section, any tests and results run on the section, the section halves, any tests and results run on the section halves, and so on, down to the last toothpick sample taken from that section, and its tests and results. Likewise, if a thin section billet is reparented (i.e., moved) to another section because it was created in error, then the billet’s label information changes as well as does the label information on the thin sections made from that billet.

LIME is designed to take parentage into account, but the user must be aware of the consequences of changing parentage in order to utilize LIME properly. Reparenting the billet in the above example automatically moves the thin section parentage as well.

TEST Table and Parentage

A collection of results is organized under a descriptive wrapper called a test. Test records are defined by the ANALYSIS table and populated once assigned to a sample. Each test in the TEST table is associated with one and only one sample, and each test has one or more associated results. Therefore, each test has a “parent” (its sample) and one or more “children” (its result or results). Working with tests is in general much simpler than working with samples because this parentage structure is always the same and does not descend any further than the RESULT table.

Another way of explaining this is such: a result is the smallest unit in the parentage structure. A result is produced by performing a test. There can be multiple results for a given test if the test was repeated. A test is always associated with an analysis. An analysis can be run on different samples. An example of a test is CHNS run on a powder sample, or a set of MS data run at different offsets on a section.

Canceling a test record using LIME also cancels its result records—because the results are children of the test.

RESULT Table

Individual results are stored in the RESULT table. These results are grouped under their parent tests and tied to samples through the TEST table, as explained above (i.e., results are not directly associated with samples in LIMS). Each result is associated with only one test; however, many results and replicate results may be associated with that same test. Results have a “parent” (the test record); they never have “children.”

Some results are collected in replicate sets, such as the results from most of the core loggers. For an MS test, the results might include magnetic susceptibility, instrument serial number, and offset on the section. The first measurement on a section is by definition replicate /0; the second is replicate /1; the third /2; etc. For measurements using replicates, some of the results are not repeated except on replicate /0 if they apply to all measurements. In the example in Figure 2, below, the first six lines are the common results and are stored along with the 0.25 cm offset results.

Figure 2. Example Replicate Results

Individual results cannot be canceled using LIME. To cancel a result the user must cancel the parent test and all results associated with that test. LIME does not allow editing of individual results (with the single exception of a container number for the MAD analysis).

User Account Privileges

A full description of roles and privileges can be found in the authorization tool user guide. The majority of users only need a basic understanding of roles and privileges.

Roles

Roles define a collection of privileges, typically created to match a set of duties on the research vessel. An example role is “scientist,” with the user having access to LIME features that are most useful at the sampling table. Another example role is “physical properties scientist,” possibly with additional privileges specific to tasks performed in the Physical Properties laboratory.

Privileges

Privileges allow the user to access specific functions in the LIME program. Each LIME module has a set of privileges based on how the module is used. In general, Cancel Sample, Reparent Sample, and Edit Sample privileges are based on sample type (e.g., CUBE, SHLF, TS); Cancel Test, Reassign Test, and Edit Test privileges are based on analysis type; and Uncancel Sample and Uncancel Test privileges are based on user account (e.g., users might only be able to uncancel only those samples or tests they canceled, or have broader privileges to uncancel anything).

Privileges are managed on board the JOIDES Resolution by the Curatorial Specialist (SAMPLE privileges) and the Laboratory Officer (TEST privileges) in consultation with the Staff Scientist. On shore, privileges are managed by the Superintendent of the Gulf Coast Repository (SAMPLE privileges) and the Supervisor of Analytical Systems (TEST privileges). Users should contact these individuals if they have a privilege or role question.

What the User Sees

Privileges not only control what screens and functions can be accessed, but also what query results are returned by the program. If a user does not have the privilege to act on samples of type SECT, searching for SECT samples using the parameter search in LIME will return no results on those samples and/or an error message created by the program. However, depending on the type of search performed (i.e., hierarchy search), samples related to the SECT samples may appear.

Login and Authorization

Authentication to the LIME program is done through the user’s LIMS credentials. The screen shown in Figure 3, below, opens at the LIME URL, accessed from the applications webpage. On the ship, LIME is accessed from the science applications page (http://web.ship.iodp.tamu.edu/apps/) or at its direct URL: http://web.ship.iodp.tamu.edu/LIME/.

On shore, it can be found only through its direct URL: https://web.iodp.tamu.edu/LIME/.

Figure 3. LIME Login Screen

Just below the word "Login" is the name of the database that LIME will access; in Figure 3, above, LIME is "pointed" at the ship production database "SHIP." Once the user has successfully logged in, the LIME home screen appears, as shown below in Figure 4.

Figure 4. LIME Home Screen

Click on the plus sign next to a given option in the left panel (e.g., Sample, Test) to expand the modules available under that group. In Figure 5, below, the user on the left has access to Cancel Tests, Uncancel Tests, Reassign Tests, and Edit Tests modules under the Test category. The user on the right does not have the Edit Tests privilege. Modules will only be visible if the user’s account has been authorized to use them. Click on the desired function to go to the associated subpage.

Figure 5. LIME Home Screen showing different privilege levels

Within a module (e.g., Cancel Samples), the user account privileges define the exact behavior of the program for that user. For example, most users may only be able to cancel samples of certain types. Any query that user performs will typically display only samples of allowed types, or only allow actions to be taken on those types, depending on which function is being used.

Moratorium Control

There are no database moratorium limitations on the ship.

On shore, the SAMPLE table is not protected by moratorium, so LIME users do not need moratorium access to query for samples or to perform the functions of the four sample modules. The TEST table is protected by moratorium, so a LIME user must both have the appropriate LIME privileges and moratorium access to the tests in question. If the user doesn't have moratorium access, the queries will not return any results.

SAMPLE Table Modules

The sample modules act on the SAMPLE table, allowing the user to correct errors in the database. Users can cancel unwanted samples (Cancel Samples), restore mistakenly canceled samples to active status (Uncancel Samples), change the parentage of a sample to another parent sample (Reparent Samples), and edit certain fields for samples (Edit Samples).

Module Navigation

Each LIME module screen is color-coded to help differentiate one page from another as shown in Figure 6, below. Clicking between functions (e.g., Cancel Samples to Edit Samples) clears the search and results from the previous screen. Each module defaults to the hierarchy search screen (“Select by Hierarchy” tab). To search by TEXT_ID, click on the “Select by TEXT_ID” tab.

IMPORTANT: Switching between the “Select by Hierarchy” and “Select by TEXT_ID” tabs does not clear the search parameters and query results unless a selection is made or values are entered into a field. If this is done, all parameters and query results will be cleared from the program.

Figure 6. LIME Sample Module Navigation

The basic layout of each of the four sample modules is the same because the search functionality and workflow is very similar between the four sample modules.

Search Functions

The basic behavior of the search controls for all of the sample modules is the same. A user selects samples using one of the following methods:

• Hierarchy search: “Select by Hierarchy tab”—follow the sample hierarchy (expedition, site, hole, core, section, etc.) to select samples for operation.
• Parameter search: “Select by Hierarchy tab”—narrow search results by sample type, test list, depth, etc.
• Combined hierarchy/parameter search: “Select by Hierarchy” tab.
• TEXT_ID search: “Select by TEXT_ID” tab—enter one or more unique and valid sample TEXT_ID(s) to select samples for operation.

Search Type and Sample Selection Status

After applying one of the search methods, query results are returned in a results table in the bottom of the search screen. Samples on this result table have checkboxes to indicate which samples are selected for Cancel, Uncancel, Reparent, or Editing Samples. Hierarchy, parameter, and combined hierarchy/parameter searches return results with no checkboxes selected; the user must select the samples they wish to operate upon manually by checking the box next to the label_ID shown on the results table.

TEXT_ID searches, on the other hand, return results with all of the samples specifically searched for selected, provided the check boxes don’t violate other rules (e.g., a parent and child cannot both be selected for reparenting at the same time). See additional information in “TEXT_ID Searches,” below.

Hierarchy Search

To use the hierarchy search, click the “Select by Hierarchy” tab on any sample module. The hierarchy search allows the user to progress through the sample hierarchy tree (expedition, site, hole, core, section, section half, etc.) to focus the search to the desired level. Note, to run the hierarchy search, at least the hole level must be selected. For example, to find all samples taken from a given section, click on an expedition number to display all of that expedition’s sites; click on a site number to show all of that site’s holes; click a hole letter to show all of that hole’s cores; and so on, down to the section, as shown in Figure 7, below (large circled region).

Figure 7. Hierarchy Search Selection

In this example, Section 393-U1560B-4H-2-W is selected. The box after Section lists samples descended directly from the whole-round section, which in this case is the working and archive section halves, an IW sample, and several piece samples. The scroll bar on the right side of the box indicates that at least one additional sample exists above or below those shown. Clicking the “SEARCH” button executes a database search for all samples at the selected level and includes all of that sample’s child samples, all of the children’s child samples (i.e., “grandchild samples”), and so on, down to the lowest level sample in the tree.

When the search query is complete, the samples are returned on a results table in default collapsed view (that the number of “Samples Found” shown on the left panel includes those that are collapsed) as shown in Figure 8, below. The sample tree is revealed by clicking “Expand All;” the tree can be hidden by clicking “Collapse All.” Figure 9, below, shows the expanded view. The selection boxes next to each sample are by default unchecked for hierarchy searches (see "Search Type and Sample Selection Status," above).

Figure 8. Collapsed Hierarchy Search Results

Figure 9. Expanded Hierarchy Search Results

Each sample module’s behavior from this point on is different and is covered in detail in the appropriate sections below. In general, however, once the search results are returned, the user selects one or more samples by checking the selection boxes and then performs the function (Cancel, Uncancel, Reparent, or Edit) on the selected samples by clicking the function button in the lower left panel.

Important notes about hierarchy search

• The hierarchy search will not function unless at least the Hole level has been selected.
• No samples may be returned if the search is too narrow (e.g., past section half).
• Too many samples may be returned if the search is too broad (e.g., searching an entire hole). Furthermore, the program response may be very slow as a response to an extended search.
• Search results are limited by the privileges of the user’s account role for each sample module.

Parameter Search

Search parameters are used to narrow the search results to a more manageable set (see “Specific Search Parameters,” below). The general workflow is to select a parameter, enter or select one or more values, click the “ADD Parameter” button, and click “SEARCH.” Clicking “ADD Parameter” displays the parameter in the selection criteria box to the right of the button as shown in Figure 10, below.

Figure 10. List of Parameters

Multiple parameters can be added to the search criteria window. Figure 11, below, shows a depth range search from 15 to 25 meters that is limited to a specific sample type (CAKE). Only samples that meet both criteria are returned in the search.

Figure 11. Example of Multiple Parameter Selection

Some parameters offer predefined values in a drop-down multiselect list; <Control><Click> and <Shift><Click> Windows and Mac conventions are honored for selecting multiple values.

Parameters that require text entry are case insensitive. Note that all searches are exact string searches; partial strings and wildcards are not permitted.

Adding a parameter of a given type overwrites any previously selected values. For example, having added the parameter LOCATION = GCR, changing the location to JR and clicking “ADD Parameter” replaces the GCR value with JR in the selection criteria. To select both the JR and GCR, use the multiselect technique (<Control><Click>).

Clear parameter search values from the selection criteria box by highlighting the parameter and clicking “REMOVE Parameter.” All parameters of a given type are cleared simultaneously; each parameter type must be cleared individually.

Clicking on the “SEARCH” button returns only samples that match the search parameters in a results table. The sample parentage tree may not be complete if parents and children do not match the criteria. For example, using a parameter search for samples of type SHLF (section half) will return ONLY the section halves, not the child samples.

Specific Search Parameters

• CHANGEDBY: Text entry—type the entire user name whose account last changed the sample. For most samples, this is the same as the user whose account created the sample.
• CHANGEDON: Selection—click in the “Start Date” field to open a calendar tool to select the starting date, then click in the “End Date” field to open a calendar tool to select the ending date. Alternatively, type the date fields manually in MM/DD/YYYY format.
• DEPTH: Text entry—type the top and bottom depths in meters. Decimals are permitted.
• LOCATION: Drop-down list—select or multiselect locations from the predefined list:
  • BREMEN: Bremen Core Repository
  • ECR: East Coast Repository
  • GCR: Gulf Coast Repository
  • GLOMCHAL: Glomar Challenger (DSDP)
  • JR: JOIDES Resolution (ODP, IODP)
  • WCR: West Coast Repository
• NAME: Text entry—type the entire sample name. Sample names are generally user-defined at creation and can be found in the LORE reports. Some examples include S (single line), D (double line), Tauxe (scientist name), MADC (analysis name), XRD_SED (user-defined).
• OFFSET: Text entry—type the top and bottom offsets (measurement from the top of the section) in centimeters. Decimals are permitted.
• RQSTCODE: Text entry—type the entire request code (typically a three- or four-letter abbreviation that can be found in the LORE reports). (Note: not every sample has an assigned request code.)
• RQSTNUMBER: Text entry—type the entire request number.
• SAMPLETYPE: Drop-down list—select or multiselect sample types from the list. Some examples include BEAD, CAKE, CUBE, CYL, TSB, WDGE. Note that search results by sample type for Cancel Samples, Reparent Samples, and Edit Samples are filtered according to user account privileges.
• TESTLIST: Drop-down list—select or multiselect tests from the list. Some examples include CARB, ICP, MAD, PMAG, PAL, TSB, XRD. Note that search results by test for Cancel Tests, Reassign Tests, and Edit Tests are filtered according to user account privileges.

Important Notes about Parameter Search

• No samples may be returned if the search is too narrow (e.g., past section half).
• Too many samples may be returned if the search is too broad (e.g., searching an entire hole). Furthermore, the program response may be very slow as a response to an extended search.
• Displayed search results are limited by the privileges of the user’s account role for each sample module.

Combined Hierarchy and Parameter Search

A hierarchy search can be combined with a parameter search to narrow results by browsing down the hierarchy (at least to the Hole level) and then adding specific search parameters. This can be done in any order. Combining searches may result in a too-narrow query that may return no samples.

TEXT_ID Search

Each sample has a unique TEXT_ID that can be found on the sample label in both barcode and human-readable format. The TEXT_ID for each sample can also be found in most LORE Reports. Specific samples (and their children) can be found using a TEXT_ID search.

To search for samples by TEXT_ID, click the “Select by TEXT_ID” tab on any sample module. Enter one or more TEXT_ID(s) manually, by barcode scan, or paste from a list into the entry field. Once at least one TEXT_ID is entered, click “SEARCH.”

The search returns all valid samples that match the TEXT_ID(s), along with their children. The selection boxes are checked by default, provided they don’t violate other rules; selection boxes for children (that do not match one of the searched TEXT_IDs) are not checked in the results table (see “Search Type and Sample Selection Status,” below). In addition, in some modules, when parents and children both match the search parameters the children are checked and the parent is not. In most cases, it is not desirable to operate on samples at different levels of hierarchy at the same time.

In Figure 12, below, note that although WRND4717901 was entered in the TEXT_ID entry field, it is not checked in the results table. This is because LIQ4718021 and LIQ4718031 (also on the TEXT_ID search list) are children of WRND4717901, and operation on multiple levels of hierarchy are not allowed in the displayed module. Edit Samples is the only module that ignores this restriction.

Figure 12. TEXT_ID Search Results

Important Notes about TEXT_ID Search

• Special characters that are invalid in a TEXT_ID are removed by the program as they are typed or pasted into the search field.
• In a pasted set of TEXT_IDs, both space delimiters and comma delimiters are recognized; the pasted contents are adjusted to space-delimited entries.
• TEXT_ID search cannot be combined with a parameter search. Selecting parameters clears the “Select by TEXT_ID” tab.
• Displayed search results are limited by the privileges of the user’s account role for each sample module.
• Note that searching for a canceled TEXT_ID returns an error in all modules except Uncancel Samples. 

Window Reset

In order to assist the user in following the proper workflow when performing the various functions in LIME, different actions clear the search results and reset the hierarchy, parameter, and TEXT_ID search selections. This was intentionally put into place to ensure that the user is clear on what operation is being performed, and that “stale” data do not confuse the user.

Cancel Samples Module

The Cancel Samples module allows a user to cancel a sample and all of its children/grandchildren samples. Furthermore, all test and result records associated with the selected sample and all of its children are canceled as well, down to the bottom of that specific parentage tree.

For example, if a user cancels an interstitial water (IW) whole-round sample, LIME cancels that sample, the liquid sample squeezed out of the sample, the squeeze cake, all of the IW splits taken from the first liquid sample, and all of the measurements performed on any of those samples, along with the associated results.

The Cancel Samples process is reversible for the most part through the Uncancel Samples module.

Data insight: The Cancel Samples function operates by copying the current status of a sample to the previous_status field and then changing the status of the sample to the canceled state. Thus, restoring the sample is a simple matter of switching the previous_status (active, in this case) with the status (canceled, in this case).

User Account Privileges

The user account privileges for the Cancel Samples module are based on sample type. A user may be given sample type = ALL, in which case their account can operate on all sample types (typically restricted to curatorial staff and laboratory officers). In most cases, users are granted privileges for specific sample types depending on their laboratory functions (e.g., samples taken at the sampling table).

Procedure

1. Determine what samples need to be canceled and why.
2. Perform a search as described in “Search Functions.” The query returns only active samples.
3. The results table displays with the sample tree collapsed by default. Click “Expand All” to view the sample hierarchy. (Use the arrows at each level of the tree to collapse or expand specific levels.)
4. Select checkboxes for one or more samples to be canceled. Note that checking some samples automatically unchecks other samples to ensure a valid operation occurs. Once at least one sample is selected, the “CANCEL SAMPLES” button on the left panel activates.
5. Click the “CANCEL SAMPLES” button.
6. An audit trail pop-up window (as shown in Figure 13, below) appears, prompting for a reason for taking this action. Enter a reason (5–150 characters).
7. Click “Save Reason and continue” to start the cancel function. The “NO CHANGE and return” button returns the user to the previous state and no database action occurs.
8. Once “Save Reason and continue” button is clicked, the selected samples are canceled (a counter appears on the screen to indicate progress), after which the original SEARCH is run again; the canceled samples and their children no longer appear in the query results table.

Figure 13. Audit Trail Popup Window

Important Notes about Cancel Samples

• If a TEXT_ID search was used, note that after the samples are canceled and the search runs again, those TEXT_IDs will not be found, returning a “TEXT_ID not found” error. This is the correct behavior for this module and confirms that the samples have been canceled.
• If a Parameter search was used, only samples matching the parameter appear in the results table (without children). For example, if samples are searched by sample type, the children of a sample will not be found, as they are not of the specified sample type.
• If a sample with many children, grandchildren, and tests and results is canceled (e.g., a core or section), the cancelation process may take some time. The user should be careful not to cancel high-ranked samples without good reason.
• Selecting a child sample unchecks its parent sample, as that is an invalid action.
• Selecting a grandchild sample unchecks the child and parent samples above it.
• Selecting a parent sample unchecks any children or grandchildren samples below it.
• Samples shown on the results table are limited by user account privilege and therefore may not show the complete hierarchy tree.

Uncancel Samples Module

The Uncancel Samples module allows the user to restore canceled samples to an active state. Assuming the samples were canceled using the Cancel Samples module, the operation should restore the sample, its children, and any tests and results associated with the sample and its children that had been previously canceled.

Database insight: The Uncancel Samples module operates by switching the status and previous_status fields of canceled samples. In most cases, this means that the canceled flag is switched with an active flag.

Downloading Canceled Samples

The Uncancel Samples module allows the user to download a list of canceled samples, primarily for curatorial purposes. Clicking the “DOWNLOAD Canceled Samples” button (circled in Figure 14, below) converts the search results table into a CSV file that can be viewed in Excel or downloaded. Note that the “Download” button functions whether samples in the results tables are checked/selected or not.

Figure 14. Download Canceled Samples Button (circled in red)

“Double Canceled” Samples

If a sample has been canceled and then the Cancel Samples module is used to cancel its parent sample, that sample is considered to be “double canceled” and will not be restored to active status even if the parent is uncanceled. The only way to uncancel such a “double-canceled” sample is to select it specifically in the Uncancel Samples module and uncancel it. This overrides the usual switch-status process and instead sets the status to active. This is desirable behavior—one presumably canceled the first sample deliberately and would not want it uncanceled along with the parent and other subsamples.

User Account Privileges

The privileges for the Uncancel Samples module are defined in the user account assigned roles. A user may be given the ability to uncancel samples that were canceled by any account (“ALL”), or may be restricted to only uncanceling samples that their own account canceled (“OWNER”). No sample type restrictions apply to the Uncancel Samples function.

Procedure

1. Determine what samples need to be uncanceled and why.
2. Perform a search as described in “Search Functions.” This query returns only canceled samples; this is the only sample search function that does so.
3. Select one or more samples to be uncanceled. Note that samples at different levels of the hierarchy uncheck other samples to ensure a valid operation occurs. Additionally, not all samples shown on the results table may have a checkbox, depending on how they were canceled. Once at least one sample is selected, the “UNCANCEL SAMPLES” button becomes active.
4. Click the “UNCANCEL SAMPLES” button.
5. An audit trail pop-up window (see Figure 13, above) appears, prompting the user for a reason taking this action. Enter a reason (5–150 characters).
6. Click “Save Reason and continue.” Note that the “NO CHANGE and return” button returns the user to the previous state and no database action will occur.
7. Once “Save Reason and continue” is clicked, the operation will be performed and the original search query will run again; the uncanceled samples and their children will no longer show in the query results, as they are no longer canceled.

Important notes about Uncancel Samples

• The “DOWNLOAD Canceled Samples” button functions whether samples on the results table are checked or not.
• Remember that the search results are populated only by Canceled samples; therefore, the sample tree may not be complete if not all children were previously canceled.
• If a highly ranked sample with many children, grandchildren, and tests and results is uncanceled (e.g., a core or section), the uncancelation process may take some time. The user should be careful not to uncancel such samples without good reason.

Reparent Samples Module

IMPORTANT: This module carries out operations that change the sample parentage and Label_ID contents of affected samples (and their children). Changes can be difficult to undo, so the user should take additional care when using this module.

The Reparent Samples module allows the user to move a sample from one parent sample to another. This changes the sample hierarchy of the new parent sample, so it also affects the children, grandchildren, etc., of the target sample, making them part of the new hierarchy.

In the sample hierarchy shown below, the Label_IDs of the working half (SHLF 2 W) and its four child samples (CUBE, CUBE, CYL, CYL) are based on the label of SECT 1. Reparenting the working section half to SECT 2 changes the Label_IDs of the section half and all four child samples. It does not affect the Label_IDs of SECT 1, SECT 2, or the archive half and its U-channel child sample.

Parentage hierarchy before reparenting section half:

SECT 1

SHLF 2 W

CUBE

CUBE

CYL

CYL

SHLF2 A

UCHAN

SECT 2

Parentage hierarchy after Reparenting section half:

SECT 1

SHLF 2 A

UCHAN

SECT 2

SHLF 2 W

CUBE

CUBE

CYL

CYL

User Account Privileges

The privileges for the Reparent Samples module are defined by sample type. A user may be given sample type = ALL, in which case their account can operate on all sample types (typically restricted to curatorial staff and laboratory officers). In most cases, users are granted privileges for specific sample types depending on their laboratory functions (e.g., samples taken at the sampling table).

Valid Sample Types

Note that even with sample type = ALL, Reparent Samples cannot operate on samples of type HOLE. As shown below in Figure 15, a user can search on a hole, but when the results table returns, no selection box appears next to the HOLE entry (circled).

Figure 15. Search results for sample type HOLE

Printing New Labels

The user can print labels (showing the new Label_IDs) for the reparented samples by clicking the “Print labels” checkbox in the lower left panel; if this box is checked, the labels for the reparented sample and all of its children, grandchildren, etc., down to the bottom of the hierarchy tree, print. By default, the checkbox is inactive. All labels print on the same label printer and the same label format, so some labels may have to be reprinted using the Sample Master application.

Procedure

1. Determine which samples need to be reparented and why.
2. Perform a search as described in “Search Functions” to obtain samples to be reparented. This query returns only active samples.
3. Click “Expand All” and select the checkboxes of one or more samples to be reparented to a single target sample. Note that samples at different levels of the hierarchy may uncheck other samples to ensure a valid operation occurs.
4. Enter, scan, or paste a valid TEXT_ID into the “TEXT_ID of New Parent” field.
5. Click the “Validate New Parent” button. This returns the Label_ID of the new parent if the TEXT_ID is valid or an error if the TEXT_ID is invalid.
   1. IMPORTANT: check that the Label_ID of the new parent is correct before continuing!
   2. A new parent can be invalid if the TEXT_ID was improperly entered or if the new parent is canceled. The new parent must be an active sample.

6. If new labels are desired, check the “Print labels” box.

7. Click the “REPARENT SAMPLES” button.

8. An audit trail pop-up window (see Figure 13, above) appears, prompting the user for a reason taking this action. Enter a reason (5–150 characters).

9. Click “Save Reason and continue.” Note that the “NO CHANGE and return” button will return the user to the previous state and no database action will occur.

10. Once “Save Reason and continue” is clicked, the operation is performed and the original search query is run again.

    1. NOTE: the reparented sample(s) and their children may or may not appear in the query results depending on the query parameters.

11. Verify the reparenting action running a search on the new sample hierarchy.

Important Notes about Reparent Samples

• Sample type HOLE cannot be reparented regardless of user account privileges.
• Samples cannot be reparented to their own children/descendants. Attempting to do so will return an error message.
• Specify the “TEXT_ID of New Parent” field as shown in Figure 16, below, only after performing the search query; clicking in the search parameter area clears the new parent automatically.

Figure 16. new Parent TEXT_ID Entry Field

Edit Samples Module

The Edit Samples module allows the user to edit certain defined fields in the SAMPLE table on specific sample types. Edit Samples behaves differently from the other three sample modules in that the database changes cannot be performed from the main window. Instead, clicking on the “GO TO EDIT” button opens a new window where changes are made and then approved and processed to the database, as shown in Figure 17, below. Unlike the other sample modules, samples at different levels of hierarchy can be operated upon in the same action.

Figure 17. Edit Sample Entry Screen

In the edit entry screen, actions performed on fields are represented by color-coded cells as follows:

• Shaded: read-only cells
• White: editable cells
• Light blue: changed cells
• Yellow: cells with errors

User Account Privileges

The privileges for the Edit Sample modules are defined by sample type. A user may be given sample type = ALL, in which case their account can operate on all sample types (typically restricted to the curatorial staff). Alternatively, the user may be given privilege for specific sample types only (e.g., sample types needed at the sample table).

Even with the privilege to operate on “ALL” sample types, some sample types are not valid for editing. This includes hole, core, section (SECT), section half (SHLF), and piece (PC) samples. Samples of these types may appear in the search results table, but they are not selectable.

Edit Screen

The edit entry screen displays the following noneditable (slightly shaded) fields, which are shown for identification and information purposes only:

• LABEL_ID
• TEXT_ID
• Sample Type
• Change By
• Changed On
• Parent Curated Length

The editable fields (white background) on the edit screen operate under the following rules:

• Tool: Double-click in the field to open a drop-down value list. Select a tool or select blank to remove the tool and leave the field blank.
• Top Offset (cm): Must be a number that is nonnegative, not equal to or less than the length of the Parent Curated Length, and equal to or less than Bottom Offset.
• Bottom Offset (cm): Must be a number that is nonnegative, equal to or less than the length of the Parent Curated Length, and equal to or greater than Top Offset.
• Length (cm): Autocalculated from the top and bottom offsets. Does not allow manual entry. Note that if these linked fields have an error, it may be necessary to reenter either field to fully clear the error.
• Volume (cc): Optional field (may be blank). Must be a number that is nonnegative.
• Test List: Double-click in the field to open a drop-down value list. Select a test or the blank row to leave the field blank.
  • NOTE: selecting the moisture and density (MAD) test requires entry of a container number.
• Container: Optional field (may be blank). Must be a number that is nonnegative. This field is editable only if no MAD analysis results have been uploaded to LIMS. Once MAD data have been uploaded to LIMS, the user may not change this field.
• Request Number: Alphanumeric. Double-click in the field to open a drop-down value list of request numbers, or type a value (maximum = 20 characters).
• Request Code: Alphanumeric. Double-click in the field to open a drop-down value list of request codes, or type a value (maximum = 10 characters).
• Name: Alphanumeric. Type a value (maximum = 30 characters).
• Comment: Alphanumeric. Type text (maximum = 250 characters).

Field entries must obey the rules for that field or an error will be generated (yellow highlight in the cell). All errors must be resolved before any of the changes can be updated in LIMS.

Printing New Labels

The user can print new labels for the edited sample(s) by selecting the “Print Labels on Update” checkbox; if this is checked, labels for the edited samples and all of their children, grandchildren, etc., down to the bottom of the hierarchy tree, will print. All of the labels print on the same label printer and the same label format, so some sample labels may have to be reprinted using the Sample Master application.

Procedure

1. Perform a search as described in “Search Functions.” This search query returns only active samples and their children.
2. Click “Expand All” and select one or more samples to be edited. The “GO TO EDIT” button will become active.
3. Click the “GO TO EDIT” button.
4. Edit the desired fields following the validation rules given above (edited fields show blue highlight).
5. If desired, check “Print Labels on Update.”
6. Click the “UPDATE ALL SAMPLES IN THIS TABLE” button.
7. An audit trail pop-up window (see Figure 13, above) appears, prompting the user for a reason for taking this action. Enter a reason (5–150 characters).
8. Click “Save Reason and continue.” Note that the “NO CHANGE and return” button returns the user to the previous state and no database action will occur. Similarly, the edit entry popup screen has a “NO CHANGE” button that returns the user to the search results.
9. Once “Save Reason and continue” is clicked, the operation is performed and the original search query runs again; edited samples and their children may or may not show in the results depending on the query parameters.

Important notes about Edit Samples

• Length is a calculated field derived from the Top Offset and Bottom Offset. If these linked fields have an error, it may be necessary to enter and leave the other field to fully clear the error.
• Edited fields are highlighted blue. These fields will be changed in LIMS on “UPDATE ALL SAMPLES IN THIS TABLE.”
• Fields containing an error are highlighted yellow, and a count of total errors in the edit table is shown at the top of the screen.
• All errors on the edit table must be resolved before the data can be updated. Attempting to update without resolving errors will cause an error message.
• Samples shown on the results table are limited by user account privilege and therefore may not show the complete hierarchy tree.

Display Samples Module

The display samples module is a tool that allows the user to employ the powerful search functions of the LIME program and then to export a CSV file of the samples returned. Although each sample has a check box in the search results, they serve no function. Note that the Display Samples query only returns active samples and not canceled samples.

TEST Table Modules

The test modules act on the TEST table, allowing the user to correct errors in the database. In similar fashion to the sample modules, users can cancel unwanted tests, restore mistakenly canceled tests to active status, change the assignment of a test from one sample to another, and edit certain fields in the test record.

Identifying the Proper Test

For some analyses, such as superconducting rock magnetometer (SRM), many instances of a test may be performed on the same samples and intervals. In the case of the SRM, the various demagnetization levels are each represented by an individual test.

It may be challenging to identify which test is the proper one for a LIME operation. The date/time stamp in the LORE Report may help identify the correct test, as well as the appropriate unique test numbers.

Module Navigation

Each LIME module is color-coded to help the user differentiate one page from another, as shown in Figure 18, below. Clicking between modules (e.g., Cancel Test to Reassign Test) clears the selections and data from the previous screens.

Figure 18. LIME Test Module Navigation

Note that the basic layout of each of these four modules is the same because the search functionality and workflow is the same in each test module.

Search Functions

The basic behavior of the search controls for all of the test modules is the same; the user selects tests using one of the following methods:

• Hierarchy search: follow the sample hierarchy (expedition, site, hole, core, section, etc.).
• TEXT_ID search: enter one unique sample TEXT_ID.
• Test Number search: enter one unique test number.
• Optional filters: narrow search results by analysis and/or instrument; these can be used with any of the previous three search methods.

Search results in the test modules are sortable by any column header in the results table. Click on the column header label to change the sort order of the results.

Search Type and Sample Selection Status

Samples in the results tables have checkboxes to indicate which samples are selected for operation. In all test modules, the selection boxes on the search results table are unchecked by default, regardless of which type of search is performed. This differs from the sample module behavior.

Hierarchy Search

The hierarchy search allows the user to progress through the sample parentage tree (expedition, site, hole, core, section, section half, etc.) to focus the search to the desired level. Note, to run the hierarchy search, at least the hole level must be selected. For example, to find all samples taken from a given section, click on the desired expedition to display all of that expedition’s sites; click a site to show all of that site’s holes; click a hole to show all of that hole’s cores; and so on, down to the section, as shown in Figure 19, below in the large circled region.

Figure 19. Hierarchy Search Selection (Test Modules)

In this example, Section 339-U1387B-2H-3 has been selected. The next box after Section lists samples descended directly from the whole-round section, which in this case is the working and archive section halves. The scroll bar on the right side of the box indicates that at least one additional sample exists above or below those shown. Clicking the “SEARCH” button executes a database search for all tests on samples at the selected level and includes all of that sample’s child samples, all of the children’s child samples (i.e., “grandchild samples”), and so on, down to the lowest level sample in the tree.

When the search query is complete, the samples are returned on a results table with their check boxes unchecked. There is no expand or collapse option or tree view.

Each test module’s behavior from this point on is different and is covered in detail in the appropriate sections below. In general, however, once the search results are returned, the user selects one or more samples by checking the selection boxes and then performs the function (Cancel, Uncancel, Reassign, or Edit) by clicking the function button in the lower left panel.

Important Notes about Hierarchy Search

• The hierarchy search will not function unless at least the Hole level has been selected.
• Too narrow a search (e.g., past section half) may return no samples.
• Too wide a set of search parameters can return too many samples and create very slow program response! In addition, function behavior may be unstable if more than 2000 rows are returned.
• Displayed search results are limited by the privileges of the user’s account role for each test module.
• Hierarchy searches are not compatible with TEXT_ID and TEST_NUMBER searches.
• Selecting any part of a hierarchy clears the TEXT_ID and TEST_NUMBER fields.
• Entering anything in the TEXT_ID field clears the hierarchy and the TEST_NUMBER fields.
• Entering anything in the TEST_NUMBER field clears the hierarchy and the TEXT_ID fields.
• Optional filters are compatible with all three types of searches, and selections in the Analysis and Instrument fields are not cleared.

Parameter Search

Two search parameters (optional filters) are defined to assist the user in narrowing the search results to a manageable set. These are shown in Figure 20, below. The Analysis and Instrument parameters can be used independently or in tandem, and are compatible with hierarchy, TEXT_ID, and TEST_NUMBER searches.

The Analysis selector is a drop-down value list showing the LIMS database code for each analysis (e.g., ALKALINITY) and a text description of each analysis (e.g., Alkalinity by autotitration).

The Instrument selector is a drop-down value list showing the name of the instrument used to acquire the data. Note that this is the name of the system (e.g., Whole-Round MultiSensor Logger [WRMSL]), not the sensor (e.g., Magnetic Susceptibility meter [MS]).

Each selector is a single-select pick list; only one of each type may be selected.

Figure 20. Analysis and Instrument Parameter Search Selectors

Important Notes about Parameter Search

• In Test module searches, the user cannot use parameters searches independent from the hierarchy, TEXT_ID, or TEST_NUMBER searches. Parameter search must be combined with one of these types of searches.
• Too narrow a set of search parameters can return no samples!
• Too wide a set of search parameters can return too many samples and create very slow program response! In addition, the behavior of each function may be unstable if more than 2000 rows are returned.
• Hierarchy searches are not compatible with TEXT_ID and TEST_NUMBER searches.
• Selecting any part of a hierarchy clears the TEXT_ID and TEST_NUMBER fields.
• Entering anything in the TEXT_ID field clears the hierarchy and the TEST_NUMBER fields.
• Entering anything in the TEST_NUMBER field clears the hierarchy and the TEXT_ID fields.
• Parameters are compatible with all three types of searches, and selections in the Analysis and Instrument fields are not cleared.

TEXT_ID and TEST_NUMBER Searches

The user can type, scan a barcode, or paste a single TEXT_ID or TEST_NUMBER into the appropriate entry field. Once a TEXT_ID or TEST_NUMBER is entered, click “SEARCH.”

Clicking the “SEARCH” button returns a list of tests performed on the chosen sample and its children and grandchildren. There is no hierarchy tree in the results table, and no Expand all/Collapse all options. None of the selection boxes return checked; the user must choose which sample(s) is(are) to be operated upon.

Important Notes about TEXT_ID and Test Number Search

• Hierarchy searches are not compatible with TEXT_ID and TEST_NUMBER searches.
• Selecting any part of a hierarchy clears the TEXT_ID and TEST_NUMBER fields.
• Entering anything in the TEXT_ID field clears the hierarchy and the TEST_NUMBER fields.
• Entering anything in the TEST_NUMBER field clears the hierarchy and the TEXT_ID fields.
• Parameters are compatible with all three types of searches, and selections in the Analysis and Instrument fields are not cleared.
• Special characters that are invalid are removed by the program as they are typed or pasted into the search field.
• Displayed search results are limited by the privileges of the user’s account role for each test module.

Window Reset

In order to assist the user in following the proper workflow when performing the various functions in LIME, different actions clear the search results and reset the hierarchy, parameter, and TEXT_ID search selections. This was intentionally put into place to ensure that the user is clear on what operation is being performed, and that “stale” data do not confuse the user.

Cancel Tests Module

The Cancel Tests module allows the user to cancel one or more tests in a query result table. All result records associated with that test are canceled in the same action. This is a reversible process for the most part through the Uncancel Tests module.

The Cancel Tests module copies the current status of a test to the previous_status field and then changes the status of the test to the canceled state. Thus, restoring the test is a simple matter of switching the previous_status (active, in this case) with the status (canceled, in this case).

User Account Privileges

The privileges for Cancel Tests are defined by analysis code. A user may be given analysis = ALL, in which case their account can operate on all analysis codes (typically restricted to the technical staff). Alternatively, the user may be given privilege for specific analysis codes only (e.g., GRA, MS, and PWAVE_L for a phys props scientist working with the WRMSL).

Procedure

1. Perform a search as described in “Search Functions.” This query returns only active tests.
2. Select one or more tests to be canceled. Once at least one test is selected, the “CANCEL TESTS” button becomes active.
3. Click the “CANCEL TESTS” button.
4. A pop-up audit trail window (see Figure 13, above) appears, prompting the user for a reason taking this action. Enter a reason (5– 150 characters).
5. Click “Save Reason and continue.” Note that the “NO CHANGE and return” button returns the user to the previous state and no database action occurs.
6. Once “Save Reason and continue” is clicked, the operation is performed and the search query runs again after each test is canceled if multiple tests were selected to cancel. The selected tests no longer show in the query results.

Important notes about Cancel Tests

• If a hierarchy search was used, all samples and their children and grandchildren, along with all analyses and tests run on them are returned.
• If a TEXT_ID search was used, note that several rows may have the same TEXT_ID, each listing a unique Test Number.
• If a Test Number search was used, the search should return only a single row in the results table.
• If a Parameter search was used, only samples matching the parameter appear in the results table (without children).
• If a sample with many children, grandchildren, and tests and results is canceled (e.g., a core or section), the cancelation process may take some time. The user should be careful not to cancel high-ranked samples without good reason.
• Selecting a child sample does not affect the selection of its parent sample.
• Samples shown on the results table are limited by user account privilege.

Uncancel Tests Module

The Uncancel Tests module allows the user to restore canceled tests to an active state. Assuming the tests were canceled by the Cancel Tests module, the operation should restore the selected tests and their results.

The Uncancel Tests module switches the status and previous_status fields of canceled tests. In most cases, this means that the canceled flag is switched with an active flag.

User Account Privileges

The privileges for the Uncancel Tests function are defined by user account. A user may have the ability to uncancel tests that were canceled by any account (“ALL”), or may be restricted to only tests canceled by their own account (“OWNER”).

Procedure

1. Perform a search as described in “Search Functions.” This query returns only canceled tests; this is the only test search function that does so.
2. Select one or more tests to be uncanceled. Once at least one test is selected, the “UNCANCEL TESTS” button will become active.
3. Click the “UNCANCEL TESTS” button.
4. A pop-up audit trail window (see Figure 13, above) appears, prompting the user for a reason taking this action. Enter a reason (5–150 characters).
5. Click “Save Reason and continue.” Note that the “NO CHANGE and return” button returns the user to the previous state and no database action occurs.
6. Once “Save Reason and continue” is clicked, the operation is performed and the query is run again; the selected tests no longer show in the query results.

Reassign Tests Module

The Reassign Tests module allows the user to move a test (and its result) from one sample to another sample. This has no effect on the sample hierarchy, unlike Reparent Samples, nor does it affect the sample Label_ID.

User Account Privileges

The privileges for the Reassign Tests function are defined by analysis code. A user may be given analysis code = ALL, in which case their account can operate on all analyses (typically restricted to the technical staff). Alternatively, the user may be given privilege for specific analysis codes only (e.g., GRA, MS, and PWAVE_L for someone working with the WRMSL).

Procedure

1. Perform a search as described in “Search Functions.” This query returns only active tests.
2. Select one or more tests to be reassigned.
3. Enter, scan, or paste a valid TEXT_ID into the “TEXT_ID of New Parent” field.
4. Click “Validate New Parent.” This returns an error if the TEXT_ID is invalid. It returns the LABEL_ID (the human-readable label) of the new parent if is it valid.
   1. IMPORTANT: Check that the LABEL_ID of the new parent is correct before continuing!
   2. A new parent can be invalid if the TEXT_ID was improperly entered or if the new parent is canceled. It must be an active sample.
5. Click the “REASSIGN Selected Tests” button.
6. A pop-up audit trail window (see Figure 13, above) appears, prompting the user for a reason taking this action. Enter a reason (5–150 characters).
7. Click “Save Reason and continue.” Note that the “NO CHANGE and return” button returns the user to the previous state and no database action occurs.
8. Once “Save Reason and continue” is clicked, the operation is performed and the query is run again; the selected tests may or may not show in the query results depending on the query.

Important Notes about Reassign Tests

Specify the “TEXT_ID of New Parent” field as shown in Figure 21 (circled) only after performing the search query; clicking in the search parameter area clears the new parent automatically.

Figure 21. New Parent TEXT_ID Entry Field

Edit Tests Module

The Edit Tests module allows the user to edit two specific fields in the TEST table. Edit Tests behaves slightly differently from the other three test modules. First, only one test can be operated upon at a time. Second, database changes cannot be uploaded from the main test selection and search window. Instead, clicking on the “EDIT TEST” button opens a new window where changes are made and then saved to the database as shown in Figure 22, below.

Figure 22. Edit Test Entry Screen

In the Edit Tests entry screen, only two parameters may be changed, Instrument and Test Comment:

• Instrument is selected from a pull-down menu (and should never be set to null).
• Test comment is a text entry field up to 150 characters.
• Add comments to any existing comments; do not remove old comments.
• Do not use single or double quotes or special characters in the comments.

An audit trail reason (5–150 characters) must be entered before the “UPDATE of a selected test” button becomes active. Clicking the “NO CHANGE” button returns the user to the search screen and to the previous state (no change occurs).

User Account Privileges

The privileges for the Edit Tests function are defined by analysis code. A user may be given analysis code = ALL, in which case their account can operate on all analyses (typically restricted to the technical staff). Alternatively, the user may be given privilege for specific analysis codes only (e.g., GRA, MS, and PWAVE_L for someone working with the WRMSL).

Procedure

1. Perform a search as described in “Search Functions.” This query returns only active tests.
2. Select one test (and only one test) to be edited. The “EDIT TEST” button becomes active.
3. Click the “EDIT TEST” button.
4. Edit the desired fields.
5. Enter an audit reason in the audit field.
6. Click the “UPDATE of a selected test” button, or the “NO CHANGE” button to abort.

Note that no separate popup window for the audit reason appears—this is different behavior than all of the other modules.

Edit Display Image Module

This module was created to allow a user to select from a set of images to indicate which one has the display flag set to "TRUE." When taking multiple images of a sample, the newest sample is automatically flagged "DISPLAY=TRUE," and older samples are switched to "DISPLAY=FALSE," meaning that they will not show up in the virtual core photo table image, the LIVE tool, or to be downloaded for the Publications Specialist to use in the barrel sheets.

For example, a user images a hard rock section first "dry," and then "wet." The uploader automatically makes the last image the "DISPLAY=TRUE" and sets all previous images to "DISPLAY=FALSE." The user subsequently decides to use the "dry" image because it shows more detail. The Edit Display Image module can be used to switch "dry" to "DISPLAY=TRUE," which will automatically make any other images present "DISPLAY=FALSE."

In the Edit Display Image Module, only certain parameters can be changed:

• The Hierarchy Search functions as normal.
• The TEXT_ID Search functions as normal.
• The Test Number search is disabled.
• An analysis filter can be used; this defaults to "LSIMG - Line scan imaging," but can be set to "WRLS - Quadrant Images" or "TSIMAGE - Thin Section Images" only.
• An instrument filter can be used: this may be set to null, to "SHIL," or to "PICAT."

Once a query is run, the user will get a list of images found. This list includes a column "NUMBER OF IMAGES," as shown in Figure 23, below. This will tell the user if there are replicates for that image.

Figure 23. Edit Display Image Query Results

User Account Privileges

The privileges for the Edit Display Image function are all or nothing. A given account can either perform this function or not. There are no restrictions as to sample type, analysis type, or instrument.

Procedure

1. Perform a search as described in “Search Functions.” This query returns only active tests.
2. Select one test (and only one test) to be edited. The “DISPLAY Images” button becomes active.
3. Click the “DISPLAY Images” button.
4. A popup window will appear displaying the LABEL_ID, the TEXT_ID, and the individual images and their test numbers as shown in Figure 24, below.
5. If the user wishes to change the display image, click on the radio button for the desired image.
6. Click "UPDATE Display Flags" or "CANCEL Changes;" cancel will return the user to the previous screen with no changes performed.
   1. Note that there is also a "Deselect all images" button; this will set "DISPLAY=FALSE" for all images and no images will appear in any report, virtual core photo table image, or be available for the barrel sheet/VCD. Use this only when certain!
7. Enter an audit reason when the audit popup appears.

Figure 24. Side-by-side Image Comparison for Edit Display Flag

Audit Trail

Every database action a user takes in LIME is recorded in the audit trail. The audit trail can be viewed by selecting “View Audit Trail” under “Audit Trail” from the main navigation bar as shown in Figure 25, below.

Figure 25. View Audit Trail page

Search Selection Criteria

The user can select the type of change to be shown; a selection of “ALL changes” returns all types of change. Selecting “SAMPLE changes” limits the search to only sample module changes, and selecting “TEST changes” limits the search to only test module changes. The user can select specific types of change (e.g., Cancel Sample or Reassign Test) as well.

The user can also limit the query to user names (“Choose author of change”), analysis type (test modules only), or a date range.

Note that the date range search is on ship or shore server time (UTC), and is from midnight on the first date to 23:59:59 on the second date. Consequently, the amount of time covered is variable; users are encouraged to broaden the date range to ensure the items they are interested in are included in the range.

Once criteria have been selected, click the “SEARCH” button for results.

Audit Trail Search Results

Once the search is run, all records matching the query are as shown in Figure 26, below. Note that the “Collapse All,” “Expand All,” and “Samples Checked” features of other search windows are present but are not relevant to this type of search.

Figure 26. Example of Audit Trail Query Results

The user has two options:

View Details

Check one (and only one) box next to an audit trail query results and then click "VIEW DETAIL of selected actions." This presents details of the LIME change as shown in Figure 27, below.

Figure 27. Audit Trail Detail

Download Audit Trail Results as a CSV File

Click the “DOWNLOAD audit trail details” button to download a CSV file of all of the items returned by the original search. This download ignores the check box selections. All of the information in the query result and the detail view is included in the CSV file.

IMPORTANT! What the Audit Trail Does Not Show

The audit trail lists only actions specifically ordered by the user. It does not contain a record of ancillary changes caused by the initial action. For example, a sample that was taken for MAD analysis is canceled, the MAD test and its results are also canceled. The audit trail contains only a single entry for this action, however, the record that the user canceled the sample.

Likewise, if an entire hole is canceled (which can be done only by the curatorial staff), all of the cores, sections, section halves, etc., and all tests and results performed on those samples, are canceled. Although the action affected possibly many thousands of database records, the audit trail shows only the action taken on the hole.