jkbits1
commented
5 years ago @dmilet just checking whether you have any concerns with this PR that can't be refactored later on. If not, merging it will means I can deploy the latest version of the front-end operator page and get some deeper discussion started about that.
Just to recap the above, this PR doesn't change any existing db tables but to some extent ties us in to the design decisions behind those, although not so much that we can't refactor later.
I can deploy the revised functions, table inserts and permissions using the command-line psql and a cut-down script.
dmilet
@dmilet this PR is the backend part of a change to store a choice of organization for new riders and drivers. The front-end will have a drop-down on the driver offer/drive request pages.
No tables are changed. The submit_new_rider and submit_new_driver functions are changed and some organization table defaults are inserted at the end of the carpool schema file (these can be moved elsewhere if you want). That table is given the standard set of permissions so that it can be read by the rider/driver functions.
I've adjusted the submit_new_rider to have the same pattern as the driver function (although no new fields not stored) i.e. there are a_RidingOnBehalfOfOrganization and a_RidingOBOOrganizationName parameters. From these parameters an organization uuid is resolved and that is stored in the table. Where both fields are null or a_RidingOnBehalfOfOrganization is false, then null is stored as the org uuid. If a_RidingOnBehalfOfOrganization is true and a_RidingOBOOrganizationName exists in the org table, that is stored, otherwise an error is raised. There are two errors handlers as null causes the error to show no info (it seems that error handlers do this, too).
The submit_new_driver function is extended to have the same behaviour as the rider function.