Occurrence Editor Custom Template Development #68
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Some constants were defined with dollar signs, a syntax error. Fixed syntax in templates and code where they were used (using defined() instead of isset()) - Added all variables that are settable to the default, genObs, and collection-specific templates - Added and standardized comments in the templates - Standardized the default state across code when variables are not set - Standardized label names between the templates and the occurrence editor (some were missing or had the wrong name)
- Added custom processing status from the collections editor includes/config to the editor search query form, Batch Update, Import/Update Specimen Records, Skeletal Records and Create New Records Using Image - Standardized processing status dropdowns (displayed with words capitalized, similar defaults wording) - When getting a list of processing statuses from the database, use SQL query to sort rather than javascript (better sort) - Note: for occurrencetabledisplay.php, Katie added language tags to the processing statuses that were hard-coded before. I've set it up to prioritize collection templates first, then language tags. For this to work, the language tag has to be an all-caps version of the processing status, so I changed the names of these slightly in the language file.
Missing NO_SET_STATUS from imageoccursubmit.php
This includes: - Quick search from the collection profile page - Create new records using image - Skeletal data entry - Determination History tab of the occurrence editor - Add batch determinations - Specimen label printing - Annotation label printing - Outgoing loan specimens Previously, these field labels were only used in the occurrence editor, but if set, it would make sense to have them the same throughout at least the Data Editor tools for consistency. Where these fields are defined in language files, the collections template takes priority, falling back to the language file definition if the collection template is not set. One exception to this is the list of fields in the Custom Field dropdown in the occurrence editor search query form. Since this pulls field names from elsewhere, I've set it up to look for a field label named [FIELDNAME]LABEL. Since some of these fields are not present in the collection editor template, they aren't customizable in this way.
This allows portals or collections to customize a message displayed to the user when hovering over a data entry field in the occurrence editor or other data entry tools (skeletal data entry, batch determinations, create new records from image). These can provide helpful prompts on how to enter various data. The customizeable tooltips are stored in the template files in collections/editor/includes/config/ and are *off* by default. In some cases there were existing tooltips either hard-coded or from language files. I've preserved these, though customized tooltips from the collection templating system would take precedence and supercede them.
|
An example of the sort of collection-specific tooltips that we are using at OSC, where we house three separate herbaria, each with their own accession numbers: |
This re-orders the fields list alphabetically according to the field names set in the collection templating system
|
It looks like some of the subsequent language localization development has added some conflicts for this one. For cases where I implemented a custom field name or tooltip where there was already a language variable set, here is how I handled it: This would prefer the custom field name or tooltip if set, and if that was not set, fall back to the language variable. Welcome to do it some other way if you prefer if you merge this code, but this is what I went with because these variables are collection-specific (at least in some cases), rather than sitewide, and so they could be used by a particular collection while the language variables get used by everyone else. |
egbot
added a commit
that referenced
this pull request
Jun 27, 2024
Merge various Symbiota-light developments into Lichen code repositories
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bunch of standardization, bugfixes, and improvements of the occurrence editor templating system stored in collections/editor/includes/config/.
Notably, it adds the following features:
All of these features are off by default, as a portal manager would have to set up a template and uncomment features to enable them. But, they give a portal manager or collection admin a high degree of control over the data entry interface. The tooltips are particularly useful for helping to train new data enterers, or jog the memory of everyone, as they can provide a built-in cheatsheet with collection or institution-specific norms.
I've broken out the bugfixes/standardization, and each of these three features into separate commits.
Note: In some cases, language files were already setting field labels, tooltips, or both. In those cases, the customizations in the occurrence editor templating system will take precedence, but if the customizations are not set, then what is defined in the language files would be used.