NO TICKET: further contact updates

[jacob-a-brown]

Why

This PR addresses the following problem / context:

• The Contact model should have a contact_type field that is separate from the role field to indicate priority for contacting (e.g. who to call first when planning a visit).
  • In the rendezvous today we talked about how role indicates how the contact relates to the thing (e.g. Owner, Manager, Ranch hand) whereas contact_type indicates priority.
  • We discussed using integers, but that would require people keeping track of the number of contacts per thing. By usingonly Primary and Secondary AMP folks will know who to contact first. This doesn't restrict the model because a thing can have multiple Primary contacts if there are multiple people that can be contacted initially.
• Contact models should correspond with the latest type-hinting/mapping styles for SQL Alchemy
• Validating incoming data should be done in a standardized and repeatable manner

How

Implementation summary - the following was changed / added / removed:

• Made Primary and Secondary contact_type terms in the lexicon term table
• Added contact_type to the Contact model, schemas, tests, and transfer scripts
• Updated the Contact, Phone, Email, Address, and ThingContactAssociation models to use the latest type-hinting/mapping styles for SQL Alchemy
• Used Pydantic to validate data for the transfer script

Notes

Any special considerations, workarounds, or follow-up work to note?

• I saw that the well screen transfer script validates incoming data using Pydantic, which I thought was a good way to proceed. This way the data validation(s) only need to be written in one location (schemas/). There are some fields that may need to be removed because they aren't part of the model (e.g. thing_id for contact), but those can be handled individually.
  • Some custom validations against tables already in the DB (e.g. no overlapping well screens) may need to be manually programmed, but we'll cross those bridges when we get there.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 98.78834% with 32 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
api/sensor.py	58.82%	7 Missing ⚠️
core/initializers.py	72.00%	7 Missing ⚠️
services/gcs_helper.py	61.53%	5 Missing ⚠️
db/lexicon.py	83.33%	3 Missing ⚠️
core/app.py	71.42%	2 Missing ⚠️
db/location.py	77.77%	2 Missing ⚠️
services/thing_helper.py	97.80%	2 Missing ⚠️
api/asset.py	97.91%	1 Missing ⚠️
services/crud_helper.py	91.66%	1 Missing ⚠️
services/observation_helper.py	98.38%	1 Missing ⚠️
... and 1 more

Files with missing lines	Coverage Δ
api/contact.py	96.26% <100.00%> (-2.91%)	⬇️
api/geochronology.py	86.66% <100.00%> (ø)
api/group.py	100.00% <100.00%> (+4.34%)	⬆️
api/lexicon.py	98.82% <100.00%> (+7.39%)	⬆️
api/location.py	92.30% <100.00%> (-0.55%)	⬇️
api/observation.py	100.00% <100.00%> (+2.63%)	⬆️
api/sample.py	100.00% <100.00%> (ø)
api/search.py	97.77% <100.00%> (+2.22%)	⬆️
api/thing.py	98.43% <100.00%> (+11.77%)	⬆️
db/__init__.py	97.14% <ø> (+1.39%)	⬆️
... and 43 more

... and 4 files with indirect coverage changes

[ksmuczynski]

What is this reference to Author?

[jirhiker]

The data system needs to store bibliographic data, the author of a paper, map, report, etc.

Since we already had a contact table it made sense to use it for contact info for authors of bureau publication.

A super brittle aspect of the bureau's current data system is its handling of publications. There are multiple systems that need access to this data, e.g., website, bookstore, GIS, publications group, etc Currently, the connections are tenuous at best. Ocotillo should serve as the central authority to manage and share this data.

Ocotillo's current implementation is only an idea of how this could work. there are other better approaches im sure