Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
-- m4_changequote(`[[', `]]')
2023-07-27 16:52:01 +00:00
begin ;
set search_path to camper , auth , public ;
alter sequence user_user_id_seq restart with 42 ;
Move the user role down to company_user relation
I was starting to add the public page for campsite types, creating more
granular row-level security policies for select, insert, update, and
delete, because now the guest users needed to SELECT them and they have
no related company to filter the rows with. Suddenly, i realized that
the role was wrong in the user relation: a user can be an admin to one
company, and employee to another, and guess to yet another company;
the role should be in the company_user relation instead.
That means that to know the role to set to, the user alone is not enough
and have to know the company as well. Had to change all the
cookie-related function to accept also the company’s host name, as this
is the information that the Go application has.
2023-08-08 00:22:16 +00:00
insert into auth . " user " ( email , name , password )
values ( ' demo@camper ' , ' Demo User ' , ' demo ' )
, ( ' admin@camper ' , ' Demo Admin ' , ' admin ' )
2023-07-27 16:52:01 +00:00
;
2023-07-29 02:25:56 +00:00
alter sequence company_company_id_seq restart with 52 ;
2023-07-31 16:21:29 +00:00
insert into company ( slug , business_name , vatin , trade_name , phone , email , web , address , city , province , postal_code , country_code , currency_code , default_lang_tag , legal_disclaimer )
values ( ' 09184122-b276-4be2-9553-e4bbcbafe40d ' , ' Càmping les mines, S.L.U. ' , ' ESB17616756 ' , ' Pescamines ' , parse_packed_phone_number ( ' 972 50 60 70 ' , ' ES ' ) , ' info@lesmines.cat ' , ' https://lesmines.cat/ ' , ' C/ de l’ ' , ' Castelló d’ ' , ' Girona ' , ' 17486 ' , ' ES ' , ' EUR ' , ' ca ' , ' Càmping les mines, S.L.U. és responsable del tractament de les seves dades d’ ’ ’ ’ ' ) ;
2023-07-29 02:25:56 +00:00
Use HTTP Host to establish the request’s company
We made the decision that this application will also serve the public
pages to guests and customers, to avoid the overhead of having to
synchronize all data between this application and a bespoke WordPress
plugin.
That means that i no longer can have a /company/slug in the URL to know
which company the request is for, not only because it looks ugly but
because guest users do not have a “main company”—or any company
whatsoever.
Since the public-facing web is going to be served through a valid DNS
domain, and all companies are going to have a different domain, i
realized this is enough: i only had to add a relation of company and
their hosts. The same company can have many hosts for staging servers
or to separate the administration and public parts, for instance.
With change, the company is already known from the first handler, and
can pass it down to all the others, not only the handlers under
/company/slug/whatever. And i no longer need the companyURL function,
as there is no more explicit company in the URL.
Even though template technically does not need the template, as it only
contains the ID —the rest of the data is in a relation inaccessible to
guests for now—, but i left the parameter just in case later on i need
the decimal digits or currency symbol for whatever reason.
2023-08-03 18:21:21 +00:00
insert into company_host ( company_id , host )
values ( 52 , ' localhost:8080 ' )
, ( 52 , ' camper.tandem.ws ' )
;
Move the user role down to company_user relation
I was starting to add the public page for campsite types, creating more
granular row-level security policies for select, insert, update, and
delete, because now the guest users needed to SELECT them and they have
no related company to filter the rows with. Suddenly, i realized that
the role was wrong in the user relation: a user can be an admin to one
company, and employee to another, and guess to yet another company;
the role should be in the company_user relation instead.
That means that to know the role to set to, the user alone is not enough
and have to know the company as well. Had to change all the
cookie-related function to accept also the company’s host name, as this
is the information that the Go application has.
2023-08-08 00:22:16 +00:00
insert into company_user ( company_id , user_id , role )
values ( 52 , 42 , ' employee ' )
, ( 52 , 43 , ' admin ' )
2023-07-29 02:25:56 +00:00
;
Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
alter sequence media_media_id_seq restart with 62 ;
insert into media ( company_id , original_filename , media_type , content )
values ( 52 , ' plots.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/plots.avif]]) ' , ' base64 ' ) )
, ( 52 , ' safari_tents.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/safari_tents.avif]]) ' , ' base64 ' ) )
, ( 52 , ' bungalows.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/bungalows.avif]]) ' , ' base64 ' ) )
, ( 52 , ' wooden_lodges.avif ' , ' image/avif ' , decode ( ' m4_esyscmd([[base64 -w0 demo/wooden_lodges.avif]]) ' , ' base64 ' ) )
;
alter sequence campsite_type_campsite_type_id_seq restart with 72 ;
insert into campsite_type ( company_id , name , media_id , description )
values ( 52 , ' Parceŀles ' , 62 , ' ' )
, ( 52 , ' Safari Tents ' , 63 , ' ' )
2023-09-12 18:20:23 +00:00
, ( 52 , ' Bungalous ' , 64 , ' ' )
Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
, ( 52 , ' Cabanes de fusta ' , 65 , ' ' )
;
2023-09-12 18:20:23 +00:00
insert into campsite_type_i18n ( campsite_type_id , lang_tag , name , description )
values ( 72 , ' en ' , ' Plots ' , ' ' )
, ( 72 , ' es ' , ' Parcelas ' , ' ' )
, ( 73 , ' en ' , ' Safari Tents ' , ' ' )
, ( 73 , ' es ' , ' Tiendas Safari ' , ' ' )
, ( 74 , ' en ' , ' Bungalows ' , ' ' )
, ( 74 , ' es ' , ' Bungalós ' , ' ' )
, ( 75 , ' en ' , ' Wooden Lodges ' , ' ' )
, ( 75 , ' es ' , ' Cabañas de madera ' , ' ' )
;
Add the sample campsite types to the demo file
Since campsite types need a media, i have to insert also images to the
media relation. The best would be to use PostgreSQL’s
pg_read_binary_file to read the media content from actual files when
inserting the new rows, but the files need to be within the database
cluster directory, or have to use an absolute path when running as a
superuser to read from files outside the cluster directory, which means
that it would depend on the path where i leave the files, that is
different in development that in staging.
To avoid that problem i can simply insert the rows using their base64
strings, with PostgreSQL’s decode. The images are kind of small, but
i was worried that each change in demo.sql would duplicate that data in
git, even if the change is not related to the images, because git stores
the whole file; even if small, soon everything adds up.
I do not care if the _final_ demo.sql is big, as this file is packaged
in a different deb and is only installed in staging, so i’ve chosen to
use m4 to build a single “amalgamated” SQL file from the base .sql
file and the individual image files converted to base64 strings. That
way, each image is individually managed by git and the base .sql file
does not balloon up for each little change.
Changed m4’s quotes to [[ ]] because the default ` ' was interfering
with Intellij’s syntax highlighting.
2023-09-10 01:57:46 +00:00
2023-07-27 16:52:01 +00:00
commit ;
