-
-
Notifications
You must be signed in to change notification settings - Fork 4
feat(notification)!: inherit invitations #176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
A table `vibetype.invitation` was added that inherits from table `notification`which was moved from schema `maevsi_private` to schema `maevsi`. In orrder to make functions that were originally created in `test_account_blocking.sql` generally available for all tests (including tests for invitations), these functions were moved to `function_test_utilities.sql`.
In `function_test_utilities.sql' many functions set the role back to the session user at their end. We use `SET LOCAL ROLE NONE`to be independent of any real user name.
Switching back to the login role can be done with ` SET LOCAL ROLE NONE`.
Table `invitation` has been renamed to `notification_invitation`.
The functions `vibetype_test.account_create` and `vibetype_test.contact_create` must run in mode SECURITY DEFINER in order to work when not logged in as the owner of the database objects.
Column `created_by` was moved from table `notification_invitation` to table `notification`. Row level security was added to table `notification`. Some modifications were made to functions in `function_test_utilities.sql`.
The policies for tables `notification` and `notification_invitation` were updated to make use of `FOR ALL` policies.
04185ea to
4096079
Compare
For tables `vibetype.notification` and `vibetype.notification_invitation` the policies were moved to the table files, making the policy files obsolete.
4096079 to
9bdd042
Compare
c988911 to
9949a49
Compare
| CREATE POLICY notification_invitation_all ON vibetype.notification_invitation FOR ALL | ||
| USING ( | ||
| created_by = vibetype.invoker_account_id() | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this covered by the parent table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, see Postgreqsl documentation, section 5.11: "In a similar way, the parent table's row security policies (see Section 5.9) are applied to rows coming from child tables during an inherited query. A child table's policies, if any, are applied only when it is the table explicitly named in the query; and in that case, any policies attached to its parent(s) are ignored."
The function `invite` has been changed to only store the event id in the payload of the notification record.
The policy for table `notification_invitation` has been removed because it is already present for the parent table `notification`.
Function `invite`has been restored to its previous implementation regarding JSON payload.
e341cdc to
4981600
Compare
6a33bb5 to
60d363d
Compare
A table
vibetype.invitationwas added that inherits from tablenotificationwhich was moved from schemamaevsi_privateto schemamaevsi. In orrder to make functions that were originally created intest_account_blocking.sqlgenerally available for all tests (including tests for invitations), these functions were moved tofunction_test_utilities.sql.