A user should not be able to delete their account if they are the last
admin of a workspace.
It means that if a user wants to sign out of twenty, they should delete
their workspace, not their account
In this PR
- updateWorkspaceMemberRole api was changed to stop allowing null as a
valid value for roleId. it is not possible anymore to just unassign a
role from a user. instead it is only possible to assign a different role
to a user, which will unassign them from their previous role. For this
reason in the FE the bins icons next to the workspaceMember on a role
page were removed
- updateWorkspaceMemberRole will throw if a user attempts to update
their own role
- tests tests tests!
Workspace Member will get their own record page in the future.
This PR lays backend changes to prepare for this:
- Settings most fields on WorkspaceMember as system fields
- Renaming workspaceMember/workspaceMemberId to
forWorkspaceMember/forWorkspaceMemberId as it conflicts with the morph
relationship, if we want to be able to add a workspace member as
favorite
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
- Adding permission gates on workspaceMember to only allow user with
admin permissions OR users attempting to update or delete themself to
perform write operations on workspaceMember object
- Reverting some changes to treat workflow objects as regular metadata
objects (any user can interact with them)
- (fix) Block updates on soft deleted records
Adding permission gates on all workspace-invitations endpoints:
sendInvitation, resendInvitation, deleteWorkspaceInvitation,
findWorkspaceInvitations (the latter being from my understanding only
used to list the invitations to then re-send them or detee them).
+ tests on Api & webhooks permission gates
Following a conversation with @etiennejouan and @martmull, we are adding
a permission gate on billing resolver's checkoutSession, which should
only be accessible to entitled users or at workspace creation (when
there are no roles yet), when the subscription is incomplete
Closes https://github.com/twentyhq/core-team-issues/issues/393
- enforcing object-records permission checks in resolvers for now. we
will move the logic to a lower level asap
- add integration tests that will still be useful when we have moved the
logic
- introduce guest seeded role to test limited permissions on
object-records
In this PR
- closing https://github.com/twentyhq/core-team-issues/issues/313
- adding permission gates on workspace settings and security settings
- adding integration tests for each of the protected setting and
security
# This PR
- Addressing #3644
- Migrates the `DELETE /rest/*` endpoint to use TwentyORM
- Factorizes common middleware logic into a common module
---------
Co-authored-by: martmull <martmull@hotmail.fr>
Run the CI integrationin sync mode
and add the option to run it without db reset
cleaning all the useless integration test
---------
Co-authored-by: guillim <guillaume@twenty.com>
This PR was created by [GitStart](https://gitstart.com/) to address the
requirements from this ticket:
[TWNTY-7526](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7526).
---
### Description
For workspace members, the deletion of multiple members is a special
case that is not permitted by the method for regular users. As a result,
we ensure that multiple deletions are not processed.
For certain tests, both an account ID and a user ID are required. We are
utilizing Tim's account for all testing purposes, as specified by the
token in `jest-integration.config.ts`. To streamline this process, we
have defined a constant to store and reference the account ID and user
ID during testing.Refs
#7526
### Dem
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
This PR was created by [GitStart](https://gitstart.com/) to address the
requirements from this ticket:
[TWNTY-7526](https://clients.gitstart.com/twenty/5449/tickets/TWNTY-7526).
---
### Description
NoteTargets and MessageThreads are special cases because they do not
have a notable property that we could use in "update" the test cases,\
for NoteTargets we are using the personId, testing the relation, but for
MessageThreads we are using updatedAt. To test the relations for
MessageThreads\
we would need to update another object (Message) because the relation is
ONE_TO_MANY, updating another object in a test that would update the
current tested object sounds incorrect.\
In the NoteTargets, we can update the NoteTarget object because the
relation is MANY_TO_ONE\
for some tests we need an account ID, we are using Tim's account for all
the tests (the token in jest-integration.config.ts), so we are using a
constant to use the account ID
### Refs
#7526
### Demo
---------
Co-authored-by: gitstart-twenty <gitstart-twenty@users.noreply.github.com>
Co-authored-by: gitstart-twenty <140154534+gitstart-twenty@users.noreply.github.com>
