Batch edit for relationships

[sharadsw]

Fixes #6126, #6248

Warning

Use a db used for testing other batch edit PRs or create a new one

Adding docs from #4929:

Batch-editing

Implementation and design

1. The current implementation uses workbench, and query builder.
2. The workbench and batch-edit dataset are differntiated at the user level using a new "isupdate" field in spdataset table. DEV note: There is no difference at the code level -- everything is as general as possible. In fact, the isupdate field is only used at the code level to follow a special rollback procedure
3. The batch-edit datasets can seen using the batch-edit overlay accessible via the batch-edit menu item. Currently, the only way to create a new dataset is via the query builder interface.
4. To make a batch-edit dataset, go to the query builder, and add the relevant fields to the query. Some fields and relationships are not supported. Nested-to-many, for instance, are supported in workbench, but aren't in the batch-edit. Special fields like nodenumber and highestchildnodenumber, fullname field in tree are also not supported.
5. Other than relationships mentioned above, every field is supported. If an unsupported field like nodenumber is added, it is rendered as readonly. However, you cannot make nested-to-manys visible (this is different than being able to map it) --- you can map nested-to-manys, and even filter on them. As long as they are hidden, it'll not block. You can also arbitrarily add formatted and aggregated fields (they are unmapped, and are ignored)

Batch edit behaviors

• Make a query with columns in the base table, and select relationships to edit. There are 4 different types of relationships, in general. Some example relationships for Collection Object as base table:

  • To-one dependent (for ex. collectionobjectattribute),
  • To-one independent (for ex. Cataloger, CollectingEvent [when not embedded])
  • To-many dependent (for ex. determinations, preparations),
  • To-many independent (for ex. None for CO as the base table)

• Fields

  The following fields are readonly. All other simple fields when changed will be updated

[
    "timestampcreated",
    "timestampmodified",
    "version",
    "nodenumber",
    "highestchildnodenumber",
    "rankid",
    "fullname",
    "age",
]

NOTE: Columns that map to (formatted) or (aggregated) values will also be readonly

• To-one dependent (for ex. collectionobjectattribute)

  These relationships get directly updated. If the to-one is not in the db, it'll create one.
  This also includes collectingevent when embedded.
  
  Test cases to consider:

  • When mapped, the record is directly updated.
  • When mapped, if the record is not present, it'll be created, if non-empty values are present.
  • If the record previously had values, and the values are removed (making the cells completely empty), the to-one dependent record will be deleted. Since it is possible that there may be other fields in the database (but not in the query), we may accidentally delete the record.
  • Example: user selected collectionobject -> collectionObjectAttribute -> remarks. And say they set remarks to empty in the spreadsheet, it is is possible that integer1 field in collectionObjectAttribute may have some value. To prevent accidental deletion, by default, we look at all the fields in the database for that record (other than system fields), to determine whether we can delete the record or not. This behavior is controlled by a preference. (described in a later section):

• To-many dependent (for ex. determinations)

  Same as to-one dependent. These relationships get directly updated. If the corresponding record is not present, a new one gets created. Does not consider matching records.

  Test cases to consider:

  • When mapped, the record is directly updated.
  • When mapped, if the record is not present, it'll be created, if non-empty values are present.
  • If the cell data is removed, and if every other field is empty in the database (can be disabled via a preference), the record will be deleted.

• To-one independent (for ex. cataloger)

  These relationships get matched, and uploaded (if a match is not found). During upload, it performs a clone of the record (cloning all the non-unique fields, and dependents). The clone takes into account relationships also mapped. That is, if agent needs to be cloned, and you have mapped agentspecialty, it'll use the mapped agentspecialty (rather than cloning previous's agentspecialty).

  Test cases to consider:

  • Start from a collectionobject with a cataloger, and map some fields. Change some of the values (like, say, lastname and firstname) to of agents that are present in the db. verify that agent gets matched. Note that the match can be performed with just the visible fields, or can also include fields in the database, not included in the query. This is controlled via a preference. By default, to be cautious in matching, it uses just the fields visible in the query.
  • If it is unable to match, it'll clone the existing agent, with data from the sheet. Make an agent with addresses/specialties/variants. Make sure the workbench is able to clone the agent correctly, and if you've provided some dependents in the mapping, it takes it.
  • Similar to workbench, you could customize the match behaviour by changing the matching options (like "never ignore", "ignore when blank", and "always ignore")

• To-many independent

  Same as to-many dependent. The only difference is that we always perform an update (we don't delete these). If a mapped record is not present, it'll create one, without any matching.

  Test cases to consider:

  • Make collection objects, and assign them collectingevent. Do a query using collectingevent as the base table, and add fields of the CO table. Verify that resetting all fields does not delete the collection object (you'll also need to disable the preference that says to look at all fields for null checks)
  • If a record is not present, it'll create one, if there is a non-empty field.

• Trees

  There are two different routes to perform tree updates.

  • Workbench method:
    
    If you want to modify a specific rank, or say reassign species for determination, you'd want to add a specific rank in the query. In this case, it always matches and uploads (and possibly clone), so we don't have updates.
    In the query builder, it'll enforce that you select complete branch of the tree. That is, if your query contains rank "species", and "genus", it'll demand you to add ranks all the way down from "genus" to "species". If used part of a relationship, it'll demand going the way down from "genus" to the lowest rank in the tree.

  • Update method:
    
    If in the query builder, there is no visible tree rank field, it allows direct modifications (and, thus, updates) to the tree table. This will be useful if you want to, say, update remarks for ones that match name "ploia"

  In both of the above methods, fullname, nodenumber, highestchildnodenumber is completely readonly.

Additionally, tree relationship columns that use (any rank) are disabled in Batch Edit. Since (any rank) is only meant to be used for editing exist tree nodes, it is only editable when the base table of your query is a Tree and not when it is part of a relationship.

Example:
Collection Object -> Determination -> Taxon -> (any rank) -> name : READONLY
Taxon -> (any rank) -> name : EDITABLE

Results

There are 4 new different type of results;

• NoChange

Reported when the record was meant to updated, but no change occurred. That is, all the values from the db were the same. This is not visible to the user.

• Updated

Reported when the record's simple fields were changed. This does not consider relationships (they are reported with different result).
NOTE: Sometimes an update could just come from an internal change. For example: For Locality records, the Workbench updates lat1text and long1text internally which Batch edit will record as an update to a simple field.

• Deleted

Reported when a record is deleted. Happens when a dependent relationship's cells are all empty (depending on the Batch Edit preference chosen for that dataset).

• MatchedAndChanged

Reported when a to-one independent was matched to an existing record, different than the current one.

• The side panel also shows the results per table, for different categories.

Preferences

There are four different preference options.

• Batch Edit Preferences (2)

• Defer For Match
  This preference controls whether database fields are included for matching or not. Defaults to true.

• Defer For Null
  This preference controls whether database fields are included for determining if the record is null or not. For dependents, null records are deleted, so this preference is used to control the caution batch-edit follows. Defaults to false.

The preferences can be accessed from going to Data Mapper > Batch Edit Preferences

• User Preferences (1)

• Number of query rows

Determines how many number of query results are used for batch-edit. Defaults to 5000.

• Show rollback button
  Can enable/disable rollback

Rollbacks

Rollbacks are complicated to perform. In the current design, whenever user creates a batch-edit dataset, it makes two datasets internally. User can only see one of them. The second is a "backer" of the first, and contains a FK to the first (so we can find backer of a dataset later). When rollback is requested, for every row in the main one, we find the original row in the backer, and perform the regular batch-edit update on it. Essentially, it applies original snapshot.

This is highly experimental, so it is recommended to always take a backup of the db, but this should work in a good amount of cases.

Known Limitations for Rollback

• Since rollback is a batch edit upload of the original dataset, rollback can only re-add data for the columns that were mapped in the original dataset

Record Set

• Queries from record set are supported for batch editing

Disallowed Tables

The batch edit button will be disabled for the following tables

System tables

spuserexternalid
spattachmentdataset
uniquenessrule
uniquenessrulefield
message
spmerging
userpolicy
userrole
role
rolepolicy
libraryrole
libraryrolepolicy
spdataset

Hierarchy tables

collection
discipline
division
institution

Misc tables

spauditlog

Misc Behaviors

Scope Change Error

If a change in scoping attribute (collection, division, discipline etc.) is detected when validating/committing, a validation error will be raised for that row. Users must delete that row from the dataset before continuing. This can happen if the query that was used contained records from tables that are scoped at different levels and the workbench internally tries to change scope of a record.

For example:

• If you make a Collecting Event query with a mapping to Collecting Event -> CollectionObjects, you could run into this error
• This is because Collecting Event is scoped higher than collection level and so the query results contain COs that do not belong in the current collection
• When validating/committing the dataset, the workbench internally tries to scope records by the current collection leading to a scope change error

Exception

Scope change is allowed only for Loan records. This is because Loan records created from Interactions are scoped only at discipline level while Loan records created from the Workbench are scoped at discipline as well as division level. If you happen to batch edit Loan records that were created from Interactions, batch edit will internally add a division level scoping to such Loan records (since BE uses the Workbench internally). This exception allows Loan records to actually be batch edited without running into a scope change error

Behavior with multiple trees

• The name field is required when querying on a tree rank
• When choosing a specific rank (and not any rank), Batch Edit expects to have all ranks lower than the chosen rank in the query
  • If the user does not add the "missing" fields, they will be prompted to pick the trees they wish to batch edit
    
    • Users can pick which trees they want in case of conflicting ranks
    • Batch edit will only add ranks from selected trees
    • If no trees are selected, batch edit will use ALL trees
  • When selected ranks do not exist in multiple trees but there are missing ranks:
    
  • Example: Say you have the following ranks for trees Tree 1 and Tree 2:
    • Tree 1 -> Species and Tree 1 -> Subspecies
    • Tree 2 -> Species (lowest rank)
  • And you make a query with:
    • Tree 1 -> Species -> name
  • Batch edit will implicitly add missing ranks (based on which trees were selected) and augment them to the dataset. The dataset will then look like
    • Tree 1 -> Species -> name
    • Tree 1 -> Subspecies -> name
    • Tree 2 -> Species -> name

Batch editing a Tree path

• When editing a tree 'path' using a Tree as a base table with Batch Edit, the records are not edited directly. Rather the record is cloned and uploaded to the tree, which means functionally it will work the same as the workbench.
• 
• When editing a path as a relationship (for eg: CO -> Determination -> Taxon -> (multiple ranks)), the complete edited path will either be matched and changed or there will be a new upload if there isn't a match

Editing a single node

• A single node's simple fields can be edited using a query containing a (any rank) query field
  
• This can only be done when the base table itself is a tree. When the base table is not a tree and (any rank) query is part of a relationship, that column will be readonly.
  

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add automated tests
• Add relevant issue to release milestone
• Add relevant documentation (Tester - Dev)
• Add a reverse migration if a migration is present in the PR

Testing instructions

NOTE: Refer to the docs above for more info on tests

I would suggest testing on very small datasets so that it is easy to track what changes were made. For the general test section in the instructions below, feel free to use a larger dataset

Permissions

• Verify user with batch edit permissions can batch edit
• Create a user with no batch edit permissions
• Verify there is no batch edit button in Query results for that user

Readonly fields

[
    "timestampcreated",
    "timestampmodified",
    "version",
    "nodenumber",
    "highestchildnodenumber",
    "rankid",
    "fullname",
    "age",
]

• Create a batch edit dataset with any/all of the above fields
• Verify the fields are readonly

To-one dependent fields

• Map a column to a to-one dependent field (eg: CO -> CollectionObjectAttribute)
• Enter/edit data
• Validate/Commit
• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)
  • You may need to choose the Batch Edit preference for Use only visible fields for empty record check

To-many dependent fields

• Map a column to a to-many dependent (eg: CO -> Determinations)
• Enter/edit data
• Validate/Commit
• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)
• You may need to choose the Batch Edit preference for Use only visible fields for empty record check. Refer the video below:
  https://github.com/user-attachments/assets/313c1bc7-9213-479e-978f-820d2b99358e

To-one independent fields

• Map a column to a to-one independent (eg: CO -> Cataloger)
• Enter/edit data
• Validate/Commit
• Verify a new record (New Cell) is created if entered data does not match
• If entered data matches an existing record, verify cell is Matched And Changed
• Change some fields of the relationship in a row that already had a related record (eg: change last name of a cataloger of a CO)
  • Verify a new record was created and other fields of the new record are cloned from the original
  • Example: If you change the last name of a cataloger, a new Cataloger will be created with all fields of the previous one but with the new last name
• Clear all values of the relationship when it already exists and verify No Change is highlighted but the relationship is updated (you may have to change the null check preference)
  • NOTE: For independent relationships, the related record will not be deleted but the base table field will not longer be associated related record
  • Example:
    • Map a column to CO -> Cataloger -> First Name and CO -> Cataloger -> Last Name
    • Batch edit
    • For rows where a Cataloger already exists, clear First Name and Last Name cells
      • NOTE: In this example, you will need to enable the Batch Edit preference for empty record check.
    • Validate/Commit
    • After commit, the CO will no longer have a cataloger
    • The cell will not be highlighted with any kind of change
    • The original cataloger record will not be deleted from the db

To-many independent

• Map a column to a to-one independent (eg: Collecting Event -> Collection Objects)
• Enter/edit data
• Validate/Commit
• Verify a new record is created for all entered data
  • Example: If you enter catalog number for CE -> collectionObjects, they will all be highlighted as new cell
• Verify clearing values does not delete the record
• Verify matching does not occur

Tree queries

• Map a tree relationship (eg: CO -> Determination -> Taxon)

• Map a column to (any rank) and to a simple field of the tree

• Batch Edit

• Verify columns that used (any rank) are readonly

• Create a new dataset with columns that rank to specific ranks

• Test matching an entire Tree path

• If values are new a new node is created

• NOTE: Same behaviors as Batch edit for multiple trees #6196 apply: If some values are new, nodes are cloned and updated instead of being updated directly

• Test missing ranks dialog with one tree relationship in the query

• Test missing ranks dialog with different trees in the relationships (eg: CO -> Determination -> Taxon and CO -> CollectingEvent -> Locality -> Geography in the same dataset)

• General test Batch Edit with different trees in the dataset

Cell Types

• Verify Updated Cell is highlighted only for simple fields of a record
• Verify Matched And Changed is highlighted when a data for a relationship matches an existing record (will depend on Batch Edit preferences)
• Verify Deleted Cell is highlighted when data is cleared for a relationship (will depend on Batch Edit preferences)
• Verify New Cell is highlighted when new data is entered for a relationship (like in the Workbench)

Preferences

• Go to Data Mapper > Batch Edit Preferences

• Use only visible fields for match:

  • When selected, verify a match happens with visible fields
  • When not selected, verify a match no longer happens with visible fields
  • (optional) When not selected, verify a match happens only if you match data for ALL fields (including hidden fields that contain data) of a relationship

• Use only visible fields for empty record check

  • When selected, verify cleared cells are deleted with visible fields
  • When not selected, verify cleared cells are no longer deleted with visible fields
  • (optional) When not selected, cleared cells are only deleted if you clear data for ALL fields (including hidden fields that contain data) of a relationship

User Preferences

• Change number of rows to use
• Verify the preference works
• Uncheck show rollback button
• Verify rollback is not visible in batch edit

General test

• General test batch edit with a combination of different field types in the dataset together

Rollback

• Test rollback with different base tables and types of relationships in the dataset
  • NOTE: If you run into rollback errors, make sure to note exactly what changes were made in the dataset before commit to make it easier to debug

BE from a Record Set query

• Query from a Record Set
• Test Batch Edit from the query

Disallowed tables

• Verify batch edit button is disabled for disallowed tables
• Verify there is a tooltip when you hover on the button

Test #6248

• Create a BE dataset with CO -> Catalog Number and CO -> CoType
• Change catalog number / cotypes
• Verify catalog numbers that do not follow the COType's formatter are marked as invalid

[sharadsw]

TODO: Change upload plan construction for remote to ones

[emenslin]

Permissions

• Verify user with batch edit permissions can batch edit
• Verify there is no batch edit button in Query results for that user

Readonly fields

• Verify the fields are readonly

To-one dependent fields

• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)

To-many dependent fields

• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)

To-one independent fields

• Verify a new record (New Cell) is created if entered data does not match
• If entered data matches an existing record, verify cell is Matched And Changed
• Change some fields of the relationship in a row that already had a related record (eg: change last name of a cataloger of a CO)
  • Verify a new record was created and other fields of the new record are cloned from the original
• Clear all values of the relationship when it already exists and verify No Change is highlighted but the relationship is updated (you may have to change the null check preference)

To-many independent

• Verify a new record is created for all entered data
• Verify clearing values does not delete the record
• Verify matching does not occur

Tree queries

• Verify columns that used (any rank) are readonly

• Test matching an entire Tree path

• If values are new a new node is created

• Test missing ranks dialog with one tree relationship in the query

• Test missing ranks dialog with different trees in the relationships (eg: CO -> Determination -> Taxon and CO -> CollectingEvent -> Locality -> Geography in the same dataset)

• General test Batch Edit with different trees in the dataset

Cell Types

• Verify Updated Cell is highlighted only for simple fields of a record
• Verify Matched And Changed is highlighted when a data for a relationship matches an existing record (will depend on Batch Edit preferences)
• Verify Deleted Cell is highlighted when data is cleared for a relationship (will depend on Batch Edit preferences)
• Verify New Cell is highlighted when new data is entered for a relationship (like in the Workbench)

Preferences

Use only visible fields for match:

• When selected, verify a match happens with visible fields

• When not selected, verify a match no longer happens with visible fields

• (optional) When not selected, verify a match happens only if you match data for ALL fields (including hidden fields that contain data) of a relationship

• Use only visible fields for empty record check

  • When selected, verify cleared cells are deleted with visible fields
  • When not selected, verify cleared cells are no longer deleted with visible fields
  • (optional) When not selected, cleared cells are only deleted if you clear data for ALL fields (including hidden fields that contain data) of a relationship

User Preferences

• Verify the preference works
• Verify rollback is not visible in batch edit

General test

• General test batch edit with a combination of different field types in the dataset together

Rollback

• Test rollback with different base tables and types of relationships in the dataset

BE from a Record Set query

• Test Batch Edit from the query

Disallowed tables

• Verify batch edit button is disabled for disallowed tables
• Verify there is a tooltip when you hover on the button

Test #6248

• Verify catalog numbers that do not follow the COType's formatter are marked as invalid

---

Rollback doesn't delete new taxon that were created when batch editing. I didn't get a chance to fully test it but it at least happens through CO -> determinations -> taxon, I'm not sure if it happens through other routes though. Other than that it looks good!

04-28_14.24.mp4

[sharadsw]

@emenslin Thanks for the review! The current implementation of rollback cannot delete a newly created independent relationship (Determination -> Taxon in this case). Rollback is a batch edit upload of the original dataset. Batch edit can only delete dependent relationships, which means rollback can also only delete dependent relationships. I think we need to document this as a limitation rather than a bug.

With that being said, there is a bug right now with rolling back a dependent to-many but that issue is already written up here: #6416

UPDATE: Investigated this a bit more and it turns out the root cause here is the same as #6416. I was able to delete new independent records on rollback when it's not a part of a to-many relationship.

[sharadsw]

Created #6451 and added it to the list of rollback limitations/bugs: #6128

[emenslin]

Permissions

• Verify user with batch edit permissions can batch edit
• Verify there is no batch edit button in Query results for that user

Readonly fields

• Verify the fields are readonly

To-one dependent fields

• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)

To-many dependent fields

• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)

To-one independent fields

• Verify a new record (New Cell) is created if entered data does not match
• If entered data matches an existing record, verify cell is Matched And Changed
  • Verify a new record was created and other fields of the new record are cloned from the original
• Clear all values of the relationship when it already exists and verify No Change is highlighted but the relationship is updated (you may have to change the null check preference)

To-many independent

• Verify a new record is created for all entered data
• Verify clearing values does not delete the record
• Verify matching does not occur

Tree queries

• Map a tree relationship (eg: CO -> Determination -> Taxon)

• Verify columns that used (any rank) are readonly

• Create a new dataset with columns that rank to specific ranks

• Test matching an entire Tree path

• If values are new a new node is created

• Test missing ranks dialog with one tree relationship in the query

• Test missing ranks dialog with different trees in the relationships (eg: CO -> Determination -> Taxon and CO -> CollectingEvent -> Locality -> Geography in the same dataset)

• General test Batch Edit with different trees in the dataset

Cell Types

• Verify Updated Cell is highlighted only for simple fields of a record
• Verify Matched And Changed is highlighted when a data for a relationship matches an existing record (will depend on Batch Edit preferences)
• Verify Deleted Cell is highlighted when data is cleared for a relationship (will depend on Batch Edit preferences)
• Verify New Cell is highlighted when new data is entered for a relationship (like in the Workbench)

Preferences

• When selected, verify a match happens with visible fields

• When not selected, verify a match no longer happens with visible fields

• (optional) When not selected, verify a match happens only if you match data for ALL fields (including hidden fields that contain data) of a relationship

• Use only visible fields for empty record check

  • When selected, verify cleared cells are deleted with visible fields
  • When not selected, verify cleared cells are no longer deleted with visible fields
  • (optional) When not selected, cleared cells are only deleted if you clear data for ALL fields (including hidden fields that contain data) of a relationship

User Preferences

• Verify the preference works
• Verify rollback is not visible in batch edit

General test

• General test batch edit with a combination of different field types in the dataset together

Rollback

• Test rollback with different base tables and types of relationships in the dataset

BE from a Record Set query

• Test Batch Edit from the query

Disallowed tables

• Verify batch edit button is disabled for disallowed tables
• Verify there is a tooltip when you hover on the button

Test #6248

• Verify catalog numbers that do not follow the COType's formatter are marked as invalid

---

I couldn't find an issue for it so I don't think this has been reported but, changing locality name in a CO batch edit prevents roll back.

05-01_10.12.mp4

Error:

{
  "uploaderstatus": {
    "operation": "unuploading",
    "taskid": "df0e1c89-6bca-4e84-9dc1-a08350a5b60b"
  },
  "taskstatus": "FAILURE",
  "taskinfo": "RollbackFailure('Unable to roll back Collectingevent object (36060) because it is now referenced by another record.')"

[sharadsw]

@emenslin Created a new issue for it: #6468

[emenslin]

I found another issue where sometimes you cannot select which taxon trees you want to add but it adds multiple trees anyway. I'm not sure why you can in some cases and why it isn't working here, my thought is maybe it happens when you have another trees in the query (i.e. in this example there's taxon and geography) but I'm not entirely sure.

05-02_11.26.mp4

Link to the data set: https://ojsmnh20250404batcheditlatest-issue-6126.test.specifysystems.org/specify/workbench/513. Once again I don't think this issue has been reported before but let me know if it has.

[sharadsw]

@emenslin I created an issue for it: #6470
It needs more investigation but looks like it happens when multiple ranks overlap between two trees. The frontend calculation of missing ranks is wrong in such cases.

[emenslin]

Permissions

• Verify user with batch edit permissions can batch edit
• Verify there is no batch edit button in Query results for that user

Readonly fields

• Verify the fields are readonly

To-one dependent fields

• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)

To-many dependent fields

• Verify a new record (New Cell) is created for rows that had a empty record before edit
• Clear all values of the relationship and verify the record was deleted (highlighted as Deleted Cell)

To-one independent fields

• Verify a new record (New Cell) is created if entered data does not match
• If entered data matches an existing record, verify cell is Matched And Changed
  • Verify a new record was created and other fields of the new record are cloned from the original
• Clear all values of the relationship when it already exists and verify No Change is highlighted but the relationship is updated (you may have to change the null check preference)

To-many independent

• Verify a new record is created for all entered data
• Verify clearing values does not delete the record
• Verify matching does not occur

Tree queries

• Map a tree relationship (eg: CO -> Determination -> Taxon)

• Verify columns that used (any rank) are readonly

• Create a new dataset with columns that rank to specific ranks

• Test matching an entire Tree path

• If values are new a new node is created

• Test missing ranks dialog with one tree relationship in the query

• Test missing ranks dialog with different trees in the relationships (eg: CO -> Determination -> Taxon and CO -> CollectingEvent -> Locality -> Geography in the same dataset)

• General test Batch Edit with different trees in the dataset

Cell Types

• Verify Updated Cell is highlighted only for simple fields of a record
• Verify Matched And Changed is highlighted when a data for a relationship matches an existing record (will depend on Batch Edit preferences)
• Verify Deleted Cell is highlighted when data is cleared for a relationship (will depend on Batch Edit preferences)
• Verify New Cell is highlighted when new data is entered for a relationship (like in the Workbench)

Preferences

• When selected, verify a match happens with visible fields

• When not selected, verify a match no longer happens with visible fields

• (optional) When not selected, verify a match happens only if you match data for ALL fields (including hidden fields that contain data) of a relationship

• Use only visible fields for empty record check

  • When selected, verify cleared cells are deleted with visible fields
  • When not selected, verify cleared cells are no longer deleted with visible fields
  • (optional) When not selected, cleared cells are only deleted if you clear data for ALL fields (including hidden fields that contain data) of a relationship

User Preferences

• Verify the preference works
• Verify rollback is not visible in batch edit

General test

• General test batch edit with a combination of different field types in the dataset together

Rollback

• Test rollback with different base tables and types of relationships in the dataset

BE from a Record Set query

• Test Batch Edit from the query

Disallowed tables

• Verify batch edit button is disabled for disallowed tables
• Verify there is a tooltip when you hover on the button

Test #6248

• Verify catalog numbers that do not follow the COType's formatter are marked as invalid

---

Looks good, I did run into a bit of weird behavior when testing a large data set but it did end up working so I am not too worried about it. When trying to roll back a large data set it gets stuck for a longer period of time on the first status dialog but it did end up successfully rolling back after awhile.