-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: collaborators #485
feat: collaborators #485
Conversation
8b13405
to
a30c37d
Compare
i think tihs PR needs rebasing! feel free to ping me on slack/re-add me as a reviewer so i don't miss this when done! |
a30c37d
to
eec8788
Compare
9787348
to
bd377a0
Compare
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.
Some preliminary comments! Will continue looking through tomorrow.
src/services/middlewareServices/AuthorizationMiddlewareService.ts
Outdated
Show resolved
Hide resolved
return new BadRequestError( | ||
"That doesn't look like a valid email. Try a gov.sg or other whitelisted email." | ||
) |
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.
Should we throw the error directly here instead of letting it be handled at the router level?
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.
My thought here was that we should move towards a neverthrow-like pattern (but I didn't want to introduce neverthrow into this specific PR just yet - we should do it in a separate PR to prevent scope creep).
In this pattern, we want to ensure that library methods don't throw errors themselves as far as possible. Instead, we want to get them to return errors of specific types so that their callers can figure out what to do with them.
In this PR, because we're not introducing neverthrow yet:
- the business-logic/expected errors (e.g. site not found) will be returned as a specific error
- the unexpected errors (e.g. database-related errors) will be thrown
In a separate PR, when we introduce neverthrow, errors in both categories will be returned as specific errors.
tagging @seaerchin since he is familiar with neverthrow from his work in FormSG - thoughts?
authenticatedSubrouter.use( | ||
"/sites/:siteName/collaborators", | ||
collaboratorsRouter.getRouter() | ||
) |
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.
Should this router be part of authenticatedSites
instead?
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.
The way I saw it was that authenticatedSites
was responsible for site content, i.e. what the GitHub repo handles today, while authenticatedSites
was responsible for site-related meta features (e.g. collaborators, review requests, notifications).
But this is definitely up for discussion. Tagging @alexanderleegs and @seaerchin for their thoughts since they are working on RR+Notifications at the moment
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.
I think we haven't really made a decision on this - currently the authenticatedSubrouter
and authenticatedSitesSubrouter
are split as such because of the params they require. I think either way works, though I'm leaning towards reusing the authenticatedSites
router to make use of the related subrouters which go together with it, to prevent having to set up siteName retrieval and other site specific operations again.
c0d1d45
to
63bdf5d
Compare
Closing because it is now too painful to rebase. Redid the PR here #510 |
Problem
This PR adds the collaborators feature as described in https://www.notion.so/opengov/Collaborators-65bfdc2267e044bfb19996ce9e7174f9
Solution
Features:
Key changes:
role
enum values toADMIN
andCONTRIBUTOR
[link]Bug Fixes:
Tests
Unit tests
npm run test
Smoke tests
Prepare database
Whitelist
tableUsers
tableSites
tableSiteMembers
tableRun frontend
feat/collaborators
branch on the CMS frontendnpm run dev
[a-test-v4 dashboard](http://localhost:3000/sites/a-test-v4/dashboard)
Deploy Notes
Migrations
20220811070630-change-role-enum.js
New dev dependencies:
@types/lodash