This was an epically long change, and a terrible idea, but it compiles.
This was essentially a cascade that came about because I can't blend jet
and bob in the same transaction. In for a penny, I guess...
It allows us to track when communication tasks are complete, and
information about how they were completed, separate from the entries
that created the tasks in the first place (reports, emails, texts)
This adds a bunch of stuff, including setting the organization's Lob
sender address ID, inserting mailer/compliance_report relationships,
adding external id from Lob (or maybe some other provider) and
attempting to load up the pool feature for a site.
This is a huge change. I was getting really sick of the split between
nuisance/water tables when more than half of the data they store is
common. I finally bit off the big work of switching it all.
This creates a single unified table, publicreport.report and copies the
existing report data into it. It also ports existing data from the
original tables into the new table.
Along with all of this I also overhauled the system for handling
asynchronous work to use a LISTEN/NOTIFY connection from the database
and a single cache table to avoid ever losing work.
This refactor was born out of the inter-dependency cycles developing
between the "background" module and just about every other module which
was caused by the background module becoming a dependency of every
module that needed to background work and the fact that the background
module was also supposedly responsible for the logic for processing
those tasks.
Instead the "background" module is now very, very shallow and relies
entirely on the Postgres NOTIFY logic for triggering jobs. There's a new
table, `job` which holds just a type and single row ID.
All told, this means that jobs can be added to the queue as part of the
API-level or platform-level transaction, ensuring atomicity, and
processing coordination is handled by the platform module, which can
depend on anything.
This adds the ability to link a proper address in the database to the
report and harmonizes the field names with the address table. It also
migrates away from mapbox entirely.
And I fixed the "pool" naming for the publicreports, which are supposed
to be the more generic 'water'.
This is extremely useful for testing.
In order to do this I needed to actually deploy the migration to a bob
fork so I could start to add support for behaviors I really want.
Specifically the ability to search for ids in a slice.
This is a sort of random checkpoint of work
* add schema for tracking messages sent to DB
* add terms of service and privacy policy for RCS compliance
* standardize some things about background workers
* update some missing stuff from generated DB code
This required a schema change and actually dumps all existing photo data
from the public reports page. That's probably fine since it's not
deployed to any customers so all data is currently test data.
