2023-07-31 12:18:17 +00:00
|
|
|
-- Test campsite_type
|
|
|
|
set client_min_messages to warning;
|
|
|
|
create extension if not exists pgtap;
|
|
|
|
reset client_min_messages;
|
|
|
|
|
|
|
|
begin;
|
|
|
|
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
select plan(108);
|
2023-07-31 12:18:17 +00:00
|
|
|
|
|
|
|
set search_path to camper, public;
|
|
|
|
|
|
|
|
select has_table('campsite_type');
|
|
|
|
select has_pk('campsite_type' );
|
2023-08-08 17:52:27 +00:00
|
|
|
select table_privs_are('campsite_type', 'guest', array['SELECT']);
|
2023-07-31 12:18:17 +00:00
|
|
|
select table_privs_are('campsite_type', 'employee', array['SELECT']);
|
|
|
|
select table_privs_are('campsite_type', 'admin', array['SELECT', 'INSERT', 'UPDATE', 'DELETE']);
|
|
|
|
select table_privs_are('campsite_type', 'authenticator', array[]::text[]);
|
|
|
|
|
|
|
|
select has_column('campsite_type', 'campsite_type_id');
|
|
|
|
select col_is_pk('campsite_type', 'campsite_type_id');
|
|
|
|
select col_type_is('campsite_type', 'campsite_type_id', 'integer');
|
|
|
|
select col_not_null('campsite_type', 'campsite_type_id');
|
Replace serial columns with ‘generated by default as identity’
I just found out that this is a feature introduced in PostgreSQL 10,
back in 2017.
Besides this being the standard way to define an “auto incremental
column” introduced in SQL:2003[0], called “identity columns”, in
PostgreSQL the new syntax has the following pros, according to [1]:
* No need to explicitly grant usage on the generated sequence.
* Can restart the sequence with only the name of the table and column;
no need to know the sequence’s name.
* An identity column has no default, and the sequence is better
“linked” to the table, therefore you can not drop the default value
but leave the sequence around, and, conversely, can not drop the
sequence if the column is still defined.
Due to this, PostgreSQL’s authors recommendation is to use identity
columns instead of serial, unless there is the need for compatibility
with PostgreSQL older than 10[2], which is not our case.
According to PostgreSQL’s documentation[3], the identity column can be
‘GENERATED BY DEFAULT’ or ‘GENERATED ALWAYS’. In the latter case, it is
not possible to give a user-specified value when inserting unless
specifying ‘OVERRIDING SYSTEM VALUE’. I think this would make harder to
write pgTAP tests, and the old behaviour of serial, which is equivalent
to ‘GENERATED BY DEFAULT’, did not bring me any trouble so far.
[0]: https://sigmodrecord.org/publications/sigmodRecord/0403/E.JimAndrew-standard.pdf
[1]: https://www.2ndquadrant.com/en/blog/postgresql-10-identity-columns/
[2]: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial
[3]: https://www.postgresql.org/docs/15/sql-createtable.html
2023-09-26 17:35:16 +00:00
|
|
|
select col_hasnt_default('campsite_type', 'campsite_type_id');
|
2023-07-31 12:18:17 +00:00
|
|
|
|
|
|
|
select has_column('campsite_type', 'company_id');
|
|
|
|
select col_is_fk('campsite_type', 'company_id');
|
|
|
|
select fk_ok('campsite_type', 'company_id', 'company', 'company_id');
|
|
|
|
select col_type_is('campsite_type', 'company_id', 'integer');
|
|
|
|
select col_not_null('campsite_type', 'company_id');
|
|
|
|
select col_hasnt_default('campsite_type', 'company_id');
|
|
|
|
|
|
|
|
select has_column('campsite_type', 'slug');
|
|
|
|
select col_is_unique('campsite_type', 'slug');
|
|
|
|
select col_type_is('campsite_type', 'slug', 'uuid');
|
|
|
|
select col_not_null('campsite_type', 'slug');
|
|
|
|
select col_has_default('campsite_type', 'slug');
|
|
|
|
select col_default_is('campsite_type', 'slug', 'gen_random_uuid()');
|
|
|
|
|
|
|
|
select has_column('campsite_type', 'name');
|
|
|
|
select col_type_is('campsite_type', 'name', 'text');
|
|
|
|
select col_not_null('campsite_type', 'name');
|
|
|
|
select col_hasnt_default('campsite_type', 'name');
|
|
|
|
|
Add cover media to campsite types
This is the image that is shown at the home page, and maybe other pages
in the future. We can not use a static file because this image can be
changed by the customer, not us; just like name and description.
I decided to keep the actual media content in the database, but to copy
this file out to the file system the first time it is accessed. This is
because we are going to replicate the database to a public instance that
must show exactly the same image, but the customer will update the image
from the private instance, behind a firewall. We could also synchronize
the folder where they upload the images, the same way we will replicate,
but i thought that i would make the whole thing a little more brittle:
this way if it can replicate the update of the media, it is impossible
to not have its contents; dumping it to a file is to improve subsequent
requests to the same media.
I use the hex representation of the media’s hash as the URL to the
resource, because PostgreSQL’s base64 is not URL save (i.e., it uses
RFC2045’s charset that includes the forward slash[0]), and i did not
feel necessary write a new function just to slightly reduce the URLs’
length.
Before checking if the file exists, i make sure that the given hash is
an hex string, like i do for UUID, otherwise any other check is going
to fail for sure. I moved out hex.Valid function from UUID to check for
valid hex values, but the actual hash check is inside app/media because
i doubt it will be used outside that module.
[0]: https://datatracker.ietf.org/doc/html/rfc2045#section-6.8
2023-09-10 01:04:18 +00:00
|
|
|
select has_column('campsite_type', 'media_id');
|
|
|
|
select col_is_fk('campsite_type', 'media_id');
|
|
|
|
select fk_ok('campsite_type', 'media_id', 'media', 'media_id');
|
|
|
|
select col_type_is('campsite_type', 'media_id', 'integer');
|
|
|
|
select col_not_null('campsite_type', 'media_id');
|
|
|
|
select col_hasnt_default('campsite_type', 'media_id');
|
|
|
|
|
2023-10-12 16:47:08 +00:00
|
|
|
select has_column('campsite_type', 'spiel');
|
|
|
|
select col_type_is('campsite_type', 'spiel', 'xml');
|
|
|
|
select col_not_null('campsite_type', 'spiel');
|
|
|
|
select col_has_default('campsite_type', 'spiel');
|
|
|
|
--select col_default_is('campsite_type', 'spiel', '');
|
|
|
|
|
2023-10-13 11:40:48 +00:00
|
|
|
select has_column('campsite_type', 'info');
|
|
|
|
select col_type_is('campsite_type', 'info', 'xml');
|
|
|
|
select col_not_null('campsite_type', 'info');
|
|
|
|
select col_has_default('campsite_type', 'info');
|
|
|
|
--select col_default_is('campsite_type', 'info', '');
|
|
|
|
|
|
|
|
select has_column('campsite_type', 'facilities');
|
|
|
|
select col_type_is('campsite_type', 'facilities', 'xml');
|
|
|
|
select col_not_null('campsite_type', 'facilities');
|
|
|
|
select col_has_default('campsite_type', 'facilities');
|
|
|
|
--select col_default_is('campsite_type', 'facilities', '');
|
|
|
|
|
2023-07-31 12:18:17 +00:00
|
|
|
select has_column('campsite_type', 'description');
|
|
|
|
select col_type_is('campsite_type', 'description', 'xml');
|
|
|
|
select col_not_null('campsite_type', 'description');
|
|
|
|
select col_has_default('campsite_type', 'description');
|
|
|
|
--select col_default_is('campsite_type', 'description', '');
|
|
|
|
|
2024-01-14 23:28:34 +00:00
|
|
|
select has_column('campsite_type', 'additional_info');
|
|
|
|
select col_type_is('campsite_type', 'additional_info', 'xml');
|
|
|
|
select col_not_null('campsite_type', 'additional_info');
|
|
|
|
select col_has_default('campsite_type', 'additional_info');
|
|
|
|
--select col_default_is('campsite_type', 'additional_info', '');
|
|
|
|
|
2023-09-29 18:17:39 +00:00
|
|
|
select has_column('campsite_type', 'max_campers');
|
|
|
|
select col_type_is('campsite_type', 'max_campers', 'integer');
|
|
|
|
select col_not_null('campsite_type', 'max_campers');
|
|
|
|
select col_hasnt_default('campsite_type', 'max_campers');
|
|
|
|
|
2024-01-29 02:38:11 +00:00
|
|
|
select has_column('campsite_type', 'overflow_allowed');
|
|
|
|
select col_type_is('campsite_type', 'overflow_allowed', 'boolean');
|
|
|
|
select col_not_null('campsite_type', 'overflow_allowed');
|
|
|
|
select col_has_default('campsite_type', 'overflow_allowed');
|
|
|
|
select col_default_is('campsite_type', 'overflow_allowed', false);
|
|
|
|
|
|
|
|
select has_column('campsite_type', 'ask_zone_preferences');
|
|
|
|
select col_type_is('campsite_type', 'ask_zone_preferences', 'boolean');
|
|
|
|
select col_not_null('campsite_type', 'ask_zone_preferences');
|
|
|
|
select col_has_default('campsite_type', 'ask_zone_preferences');
|
|
|
|
select col_default_is('campsite_type', 'ask_zone_preferences', false);
|
|
|
|
|
2024-01-22 19:19:19 +00:00
|
|
|
select has_column('campsite_type', 'check_in');
|
|
|
|
select col_type_is('campsite_type', 'check_in', 'text');
|
|
|
|
select col_not_null('campsite_type', 'check_in');
|
|
|
|
select col_has_default('campsite_type', 'check_in');
|
|
|
|
select col_default_is('campsite_type', 'check_in', '');
|
|
|
|
|
|
|
|
select has_column('campsite_type', 'check_out');
|
|
|
|
select col_type_is('campsite_type', 'check_out', 'text');
|
|
|
|
select col_not_null('campsite_type', 'check_out');
|
|
|
|
select col_has_default('campsite_type', 'check_out');
|
|
|
|
select col_default_is('campsite_type', 'check_out', '');
|
|
|
|
|
2024-01-31 22:06:45 +00:00
|
|
|
select has_column('campsite_type', 'bookable_nights');
|
|
|
|
select col_type_is('campsite_type', 'bookable_nights', 'int4range');
|
|
|
|
select col_not_null('campsite_type', 'bookable_nights');
|
|
|
|
select col_hasnt_default('campsite_type', 'bookable_nights');
|
|
|
|
|
2023-07-31 12:18:17 +00:00
|
|
|
select has_column('campsite_type', 'active');
|
|
|
|
select col_type_is('campsite_type', 'active', 'boolean');
|
|
|
|
select col_not_null('campsite_type', 'active');
|
|
|
|
select col_has_default('campsite_type', 'active');
|
|
|
|
select col_default_is('campsite_type', 'active', 'true');
|
|
|
|
|
2023-12-20 18:52:14 +00:00
|
|
|
select has_column('campsite_type', 'position');
|
|
|
|
select col_type_is('campsite_type', 'position', 'integer');
|
|
|
|
select col_not_null('campsite_type', 'position');
|
|
|
|
select col_has_default('campsite_type', 'position');
|
|
|
|
select col_default_is('campsite_type', 'position', '2147483647');
|
|
|
|
|
2023-07-31 12:18:17 +00:00
|
|
|
|
|
|
|
set client_min_messages to warning;
|
|
|
|
truncate campsite_type cascade;
|
Add cover media to campsite types
This is the image that is shown at the home page, and maybe other pages
in the future. We can not use a static file because this image can be
changed by the customer, not us; just like name and description.
I decided to keep the actual media content in the database, but to copy
this file out to the file system the first time it is accessed. This is
because we are going to replicate the database to a public instance that
must show exactly the same image, but the customer will update the image
from the private instance, behind a firewall. We could also synchronize
the folder where they upload the images, the same way we will replicate,
but i thought that i would make the whole thing a little more brittle:
this way if it can replicate the update of the media, it is impossible
to not have its contents; dumping it to a file is to improve subsequent
requests to the same media.
I use the hex representation of the media’s hash as the URL to the
resource, because PostgreSQL’s base64 is not URL save (i.e., it uses
RFC2045’s charset that includes the forward slash[0]), and i did not
feel necessary write a new function just to slightly reduce the URLs’
length.
Before checking if the file exists, i make sure that the given hash is
an hex string, like i do for UUID, otherwise any other check is going
to fail for sure. I moved out hex.Valid function from UUID to check for
valid hex values, but the actual hash check is inside app/media because
i doubt it will be used outside that module.
[0]: https://datatracker.ietf.org/doc/html/rfc2045#section-6.8
2023-09-10 01:04:18 +00:00
|
|
|
truncate media cascade;
|
Manage all media uploads in a single place
It made no sense to have a file upload in each form that needs a media,
because to reuse an existing media users would need to upload the exact
same file again; this is very unusual and unfriendly.
A better option is to have a “centralized” media section, where people
can upload files there, and then have a picker to select from there.
Ideally, there would be an upload option in the picker, but i did not
add it yet.
I’ve split the content from the media because i want users to have the
option to update a media, for instance when they need to upload a
reduced or cropped version of the same photo, without an edit they would
need to upload the file as a new media and then update all places where
the old version was used. And i did not want to trouble people that
uploads the same photo twice: without the separate relation, doing so
would throw a constraint error.
I do not believe there is any security problem to have all companies
link their media to the same file, as they were already readable by
everyone and could upload the data from a different company to their
own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
|
|
|
truncate media_content cascade;
|
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
|
|
|
truncate company_host cascade;
|
2023-07-31 12:18:17 +00:00
|
|
|
truncate company_user cascade;
|
|
|
|
truncate company cascade;
|
|
|
|
truncate auth."user" cascade;
|
|
|
|
reset client_min_messages;
|
|
|
|
|
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" (user_id, email, name, password, cookie, cookie_expires_at)
|
|
|
|
values (1, 'demo@tandem.blog', 'Demo', 'test', '44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e', current_timestamp + interval '1 month')
|
|
|
|
, (5, 'admin@tandem.blog', 'Demo', 'test', '12af4c88b528c2ad4222e3740496ecbc58e76e26f087657524', current_timestamp + interval '1 month')
|
2023-07-31 12:18:17 +00:00
|
|
|
;
|
|
|
|
|
2024-02-27 18:45:47 +00:00
|
|
|
insert into company (company_id, business_name, vatin, trade_name, phone, email, web, address, city, province, postal_code, rtc_number, tourist_tax, tourist_tax_max_days, country_code, currency_code, default_lang_tag)
|
|
|
|
values (2, 'Company 2', 'XX123', '', '555-555-555', 'a@a', '', '', '', '', '', '', 60, 7, 'ES', 'EUR', 'ca')
|
|
|
|
, (4, 'Company 4', 'XX234', '', '666-666-666', 'b@b', '', '', '', '', '', '', 60, 7, 'FR', 'USD', 'ca')
|
2023-07-31 12:18:17 +00:00
|
|
|
;
|
|
|
|
|
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 (2, 1, 'admin')
|
|
|
|
, (4, 5, 'admin')
|
|
|
|
;
|
|
|
|
|
|
|
|
insert into company_host (company_id, host)
|
|
|
|
values (2, 'co2')
|
|
|
|
, (4, 'co4')
|
2023-07-31 12:18:17 +00:00
|
|
|
;
|
|
|
|
|
Manage all media uploads in a single place
It made no sense to have a file upload in each form that needs a media,
because to reuse an existing media users would need to upload the exact
same file again; this is very unusual and unfriendly.
A better option is to have a “centralized” media section, where people
can upload files there, and then have a picker to select from there.
Ideally, there would be an upload option in the picker, but i did not
add it yet.
I’ve split the content from the media because i want users to have the
option to update a media, for instance when they need to upload a
reduced or cropped version of the same photo, without an edit they would
need to upload the file as a new media and then update all places where
the old version was used. And i did not want to trouble people that
uploads the same photo twice: without the separate relation, doing so
would throw a constraint error.
I do not believe there is any security problem to have all companies
link their media to the same file, as they were already readable by
everyone and could upload the data from a different company to their
own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
|
|
|
insert into media_content (media_type, bytes)
|
|
|
|
values ('image/x-xpixmap', 'static char *s[]={"1 1 1 1","a c #ffffff","a"};')
|
|
|
|
;
|
|
|
|
|
|
|
|
insert into media (media_id, company_id, original_filename, content_hash)
|
|
|
|
values (6, 2, 'cover2.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
|
|
|
|
, (8, 4, 'cover4.xpm', sha256('static char *s[]={"1 1 1 1","a c #ffffff","a"};'))
|
Add cover media to campsite types
This is the image that is shown at the home page, and maybe other pages
in the future. We can not use a static file because this image can be
changed by the customer, not us; just like name and description.
I decided to keep the actual media content in the database, but to copy
this file out to the file system the first time it is accessed. This is
because we are going to replicate the database to a public instance that
must show exactly the same image, but the customer will update the image
from the private instance, behind a firewall. We could also synchronize
the folder where they upload the images, the same way we will replicate,
but i thought that i would make the whole thing a little more brittle:
this way if it can replicate the update of the media, it is impossible
to not have its contents; dumping it to a file is to improve subsequent
requests to the same media.
I use the hex representation of the media’s hash as the URL to the
resource, because PostgreSQL’s base64 is not URL save (i.e., it uses
RFC2045’s charset that includes the forward slash[0]), and i did not
feel necessary write a new function just to slightly reduce the URLs’
length.
Before checking if the file exists, i make sure that the given hash is
an hex string, like i do for UUID, otherwise any other check is going
to fail for sure. I moved out hex.Valid function from UUID to check for
valid hex values, but the actual hash check is inside app/media because
i doubt it will be used outside that module.
[0]: https://datatracker.ietf.org/doc/html/rfc2045#section-6.8
2023-09-10 01:04:18 +00:00
|
|
|
;
|
|
|
|
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
insert into campsite_type (company_id, name, media_id, max_campers, bookable_nights)
|
|
|
|
values (2, 'Wooden lodge', 6, 7, '[1, 7]')
|
|
|
|
, (4, 'Bungalow', 8, 6, '[2, 6]')
|
2023-07-31 12:18:17 +00:00
|
|
|
;
|
|
|
|
|
|
|
|
prepare campsite_type_data as
|
|
|
|
select company_id, name
|
|
|
|
from campsite_type
|
|
|
|
order by company_id, name;
|
|
|
|
|
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
|
|
|
set role guest;
|
|
|
|
select bag_eq(
|
|
|
|
'campsite_type_data',
|
|
|
|
$$ values (2, 'Wooden lodge')
|
|
|
|
, (4, 'Bungalow')
|
|
|
|
$$,
|
|
|
|
'Everyone should be able to list all campsite types across all companies'
|
|
|
|
);
|
2023-07-31 12:18:17 +00:00
|
|
|
reset role;
|
|
|
|
|
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
|
|
|
select set_cookie('44facbb30d8a419dfd4bfbc44a4b5539d4970148dfc84bed0e/demo@tandem.blog', 'co2');
|
|
|
|
|
|
|
|
select lives_ok(
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
$$ insert into campsite_type(company_id, name, media_id, max_campers, bookable_nights) values (2, 'Another type', 6, 7, '[1, 7]') $$,
|
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
|
|
|
'Admin from company 2 should be able to insert a new campsite type to that company.'
|
|
|
|
);
|
|
|
|
|
2023-07-31 12:18:17 +00:00
|
|
|
select bag_eq(
|
|
|
|
'campsite_type_data',
|
|
|
|
$$ values (2, 'Wooden lodge')
|
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
|
|
|
, (2, 'Another type')
|
|
|
|
, (4, 'Bungalow')
|
2023-07-31 12:18:17 +00:00
|
|
|
$$,
|
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
|
|
|
'The new row should have been added'
|
|
|
|
);
|
|
|
|
|
|
|
|
select lives_ok(
|
|
|
|
$$ update campsite_type set name = 'Another' where company_id = 2 and name = 'Another type' $$,
|
|
|
|
'Admin from company 2 should be able to update campsite type of that company.'
|
2023-07-31 12:18:17 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
'campsite_type_data',
|
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
|
|
|
$$ values (2, 'Wooden lodge')
|
|
|
|
, (2, 'Another')
|
|
|
|
, (4, 'Bungalow')
|
2023-07-31 12:18:17 +00:00
|
|
|
$$,
|
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
|
|
|
'The row should have been updated.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select lives_ok(
|
|
|
|
$$ delete from campsite_type where company_id = 2 and name = 'Another' $$,
|
|
|
|
'Admin from company 2 should be able to delete campsite type from that company.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
'campsite_type_data',
|
|
|
|
$$ values (2, 'Wooden lodge')
|
|
|
|
, (4, 'Bungalow')
|
|
|
|
$$,
|
|
|
|
'The row should have been deleted.'
|
2023-07-31 12:18:17 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
select throws_ok(
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
$$ insert into campsite_type (company_id, name, media_id, max_campers, bookable_nights) values (4, 'Another type', 6, 6, '[1, 7]') $$,
|
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
|
|
|
'42501', 'new row violates row-level security policy for table "campsite_type"',
|
|
|
|
'Admin from company 2 should NOT be able to insert new campsite types to company 4.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select lives_ok(
|
|
|
|
$$ update campsite_type set name = 'Nope' where company_id = 4 $$,
|
|
|
|
'Admin from company 2 should not be able to update new campsite types of company 4, but no error if company_id is not changed.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select bag_eq(
|
2023-07-31 12:18:17 +00:00
|
|
|
'campsite_type_data',
|
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
|
|
|
$$ values (2, 'Wooden lodge')
|
|
|
|
, (4, 'Bungalow')
|
|
|
|
$$,
|
|
|
|
'No row should have been changed.'
|
2023-07-31 12:18:17 +00:00
|
|
|
);
|
|
|
|
|
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
|
|
|
select throws_ok(
|
|
|
|
$$ update campsite_type set company_id = 4 where company_id = 2 $$,
|
|
|
|
'42501', 'new row violates row-level security policy for table "campsite_type"',
|
|
|
|
'Admin from company 2 should NOT be able to move campsite types to company 4'
|
|
|
|
);
|
|
|
|
|
|
|
|
select lives_ok(
|
|
|
|
$$ delete from campsite_type where company_id = 4 $$,
|
|
|
|
'Admin from company 2 should NOT be able to delete campsite types from company 4, but not error is thrown'
|
|
|
|
);
|
|
|
|
|
|
|
|
select bag_eq(
|
|
|
|
'campsite_type_data',
|
|
|
|
$$ values (2, 'Wooden lodge')
|
|
|
|
, (4, 'Bungalow')
|
2023-07-31 12:18:17 +00:00
|
|
|
$$,
|
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
|
|
|
'No row should have been changed'
|
2023-07-31 12:18:17 +00:00
|
|
|
);
|
|
|
|
|
2023-08-08 17:52:27 +00:00
|
|
|
select throws_ok(
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
$$ insert into campsite_type (company_id, name, media_id, max_campers, bookable_nights) values (2, ' ', 6, 5, '[1, 7]') $$,
|
2023-08-08 17:52:27 +00:00
|
|
|
'23514', 'new row for relation "campsite_type" violates check constraint "name_not_empty"',
|
|
|
|
'Should not be able to insert campsite types with a blank name.'
|
|
|
|
);
|
|
|
|
|
2023-09-29 18:17:39 +00:00
|
|
|
select throws_ok(
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
$$ insert into campsite_type (company_id, name, media_id, max_campers, bookable_nights) values (2, 'Name', 6, 0, '[1, 7]') $$,
|
2023-09-29 18:17:39 +00:00
|
|
|
'23514', 'new row for relation "campsite_type" violates check constraint "at_least_one_camper"',
|
|
|
|
'Should not be able to insert campsite types with no campers allowed.'
|
|
|
|
);
|
|
|
|
|
2024-01-31 22:06:45 +00:00
|
|
|
select throws_ok(
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
$$ insert into campsite_type (company_id, name, media_id, max_campers, bookable_nights) values (2, 'Name', 6, 1, '[0, 7]') $$,
|
2024-01-31 22:06:45 +00:00
|
|
|
'23514', 'new row for relation "campsite_type" violates check constraint "at_least_one_night"',
|
|
|
|
'Should not be able to insert campsite types that allows to book zero nights.'
|
|
|
|
);
|
|
|
|
|
|
|
|
select throws_ok(
|
Add campsite_type_pet_cost relation to hold price of dogs in campsites
It is a separate relation, instead of having a field in campsite_type,
because not all campsite types allow dogs. I could have added a new
field to campsite_type, but then its values it would be meaningless for
campsites that do not allow dogs, and a nullable field is not a valid
solution because NULL means “unknown”, but we **do** know the price —
none.
A separate relation encodes the same information without ambiguities nor
null values, and, in fact, removed the dogs_allowed field from
campsite_type to prevent erroneous status, such as a campsite type that
allows dogs without having a cost — even if the cost is zero, it has to
be added to the new relation.
2024-02-10 05:18:30 +00:00
|
|
|
$$ insert into campsite_type (company_id, name, media_id, max_campers, bookable_nights) values (2, 'Name', 6, 1, '[1, 1)') $$,
|
2024-01-31 22:06:45 +00:00
|
|
|
'23514', 'new row for relation "campsite_type" violates check constraint "at_least_one_night"',
|
|
|
|
'Should not be able to insert campsite types with no bookable nights.'
|
|
|
|
);
|
|
|
|
|
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
|
|
|
reset role;
|
|
|
|
|
2023-07-31 12:18:17 +00:00
|
|
|
|
|
|
|
select *
|
|
|
|
from finish();
|
|
|
|
|
|
|
|
rollback;
|
|
|
|
|