2023-07-31 12:18:17 +00:00
|
|
|
-- Deploy camper:campsite_type to pg
|
|
|
|
-- requires: roles
|
|
|
|
-- requires: schema_camper
|
|
|
|
-- requires: company
|
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
|
|
|
-- requires: user_profile
|
2023-07-31 12:18:17 +00:00
|
|
|
|
|
|
|
begin;
|
|
|
|
|
|
|
|
set search_path to camper, public;
|
|
|
|
|
|
|
|
create table campsite_type (
|
|
|
|
campsite_type_id serial primary key,
|
|
|
|
company_id integer not null references company,
|
|
|
|
slug uuid not null unique default gen_random_uuid(),
|
|
|
|
name text not null constraint name_not_empty check(length(trim(name)) > 0),
|
|
|
|
description xml not null default ''::xml,
|
|
|
|
active boolean not null default true
|
|
|
|
);
|
|
|
|
|
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
|
|
|
grant select on table campsite_type to guest;
|
2023-07-31 12:18:17 +00:00
|
|
|
grant select on table campsite_type to employee;
|
|
|
|
grant select, insert, update, delete on table campsite_type to admin;
|
|
|
|
|
|
|
|
grant usage on sequence campsite_type_campsite_type_id_seq to admin;
|
|
|
|
|
|
|
|
alter table campsite_type enable row level security;
|
|
|
|
|
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
|
|
|
create policy guest_ok
|
2023-07-31 12:18:17 +00:00
|
|
|
on campsite_type
|
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
|
|
|
for select
|
|
|
|
using (true)
|
|
|
|
;
|
|
|
|
|
|
|
|
create policy insert_to_company
|
|
|
|
on campsite_type
|
|
|
|
for insert
|
|
|
|
with check (
|
|
|
|
company_id in (select company_id from user_profile)
|
|
|
|
)
|
|
|
|
;
|
|
|
|
|
|
|
|
create policy update_company
|
|
|
|
on campsite_type
|
|
|
|
for update
|
2023-07-31 12:18:17 +00:00
|
|
|
using (
|
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
|
|
|
company_id in (select company_id from user_profile)
|
|
|
|
)
|
|
|
|
;
|
|
|
|
|
|
|
|
create policy delete_from_company
|
|
|
|
on campsite_type
|
|
|
|
for delete
|
|
|
|
using (
|
|
|
|
company_id in (select company_id from user_profile)
|
|
|
|
)
|
|
|
|
;
|
2023-07-31 12:18:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
commit;
|