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 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).
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.
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.
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).
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 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 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.
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.
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.
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.
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).
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.
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:
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.
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.
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.
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.
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
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.
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).
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).
Figure 13. Audit Trail Popup Window
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.
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)
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.
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.
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
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).
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
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.
If new labels are desired, check the “Print labels” box.
Click the “REPARENT SAMPLES” button.
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).
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.
Once “Save Reason and continue” is clicked, the operation is performed and the original search query is run again.
NOTE: the reparented sample(s) and their children may or may not appear in the query results depending on the query parameters.
Verify the reparenting action running a search on the new sample hierarchy.
Figure 16. new Parent TEXT_ID Entry Field
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:
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.
The edit entry screen displays the following noneditable (slightly shaded) fields, which are shown for identification and information purposes only:
The editable fields (white background) on the edit screen operate under the following rules:
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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.
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).
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).
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.
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”).
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.
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).
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
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:
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).
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).
Note that no separate popup window for the audit reason appears—this is different behavior than all of the other modules.
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:
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
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.
Figure 24. Side-by-side Image Comparison for Edit Display Flag
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
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.
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:
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
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.
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.