Legislator Profile Type#2166
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
ACoullard
force-pushed
the
AC/legislator-accounts
branch
from
03a2c84 to
f35f619
Compare
ACoullard
requested review from
Mephistic,
alexjball,
kiminkim724,
mertbagt,
mvictor55,
nesanders,
sashamaryl and
timblais
as code owners
Mephistic
left a comment
Mephistic
left a comment
There was a problem hiding this comment.
Great start here - I love how neatly the member search. box slots into the signup form.
I think now that we've got a working prototype, we have seen some grey areas in the Ticket that we should clear up at hack night before moving forward.
| case "pendingLegislator": | ||
| case "admin": | ||
| return false | ||
| case "legislator": |
There was a problem hiding this comment.
nit: We probably want "legislator" accounts to be public by default - the main reason legislators would make accounts is to communicate their stances to constituents.
| <Modal.Body> | ||
| <Col md={12} className="mx-auto"> | ||
| <Stack gap={2} direction="vertical"> | ||
| <Stack gap={4} direction="vertical"> |
There was a problem hiding this comment.
I think we may need to play with the bootstrap columns a bit more - this seems to work fine for small and large screens, but there is a middle breakpoint that causes the Legislator button to spill over the modal:
There was a problem hiding this comment.
Might be worth looping in Grace if this ends up being a design question about how to make this look good at that breakpoint instead of a css bug.
| useCreateLegislatorWithEmailAndPassword() | ||
|
|
||
| const { index } = useMemberSearch() | ||
| const { claimedCodes } = useClaimedMemberCodes() |
There was a problem hiding this comment.
Love the thought you put into the user experience here, but I think we can get away without excluding already claimed member codes. Any legitimate legislator will only try to claim themselves (and we have a search input to help them find themselves) and any illegitimate user doesn't deserve a good user experience.
There was a problem hiding this comment.
Actually, I think it may be more helpful in the admin view than the user-facing view.
It's possible more than one person will submit a request for a given legislator (possibly, but not necessarily maliciously - it could be the legislator and a staffer requesting from different email addresses). In that case, I think it's fine to let the users submit what they want and let the admins sort out the real deal.
(It's also possible the real legislator tries to claim the account second - so it may be desirable to leave their name in the select box so they can more easily contest ownership)
If so, we do want the MAPLE admin to know if there are multiple requests for a given member (even if one request has been previously accepted) - we should expose that in the admin interface for additional context.
There was a problem hiding this comment.
This does raise an issue about user verification I'd love to discuss:
- Should we allow unverified users to be approved as legislators? (e.g. I sign up for a
Rebecca Rauschlegislator profile with her statehouse email, a MAPLE admin sees the request and approves it, and then I can post anything I want as Rebecca Rausch)- Seems like the answer shoud be no
- Instead, I feel that the flow should be:
- User signs up as a Pending Legislator
- We tell them they must verify their email
- Only after they verify their email does their account show up as "Pending Legislator" in the MAPLE admin view
- IMO there's not a quick way to hook into the email verification flow (we host those links in an unconventional way, so it might be easiest to just hide pendingLegislator profiles with
email_verified: falsefrom the admin view
- IMO there's not a quick way to hook into the email verification flow (we host those links in an unconventional way, so it might be easiest to just hide pendingLegislator profiles with
- The MAPLE admin accepts them
- The account is fully upgraded to Legislator status
There was a problem hiding this comment.
As a nice-to-have (that may or may not make things easier in this PR, so I'll bring it up anyway):
- Should we have special handling for government email addresses?
- On the one hand, it would be a nice UX boost to auto-fill the appropriate legislator when the user uses their government email (e.g.
my_legislator@ma.senate.gov) and we could even auto-approve requests to claim a legislator from a verified government email address (to cut down on the worklog for our admins) - On the other, they may not actually want to use their government email for things like this (e.g. preferring a personal/campaign email, or a staffer's email).
- On the one hand, it would be a nice UX boost to auto-fill the appropriate legislator when the user uses their government email (e.g.
@mvictor55 How do you plan to approve/reject legislator profile requests? Do we need them to sign up with their government email so we have some proof they're real, or are there other signals we should look/ask for? We should discuss this at hack night.
| refresh() | ||
| } | ||
|
|
||
| async function handleAcceptLegislator(record: any) { |
There was a problem hiding this comment.
My comments on the LegislatorProfileForm are probably relevant here too - but to reiterate:
- We should filter out requests from users that aren't
email_verified: true- if we don't even require email verification, then we have no signal to determine that anyone is actually connected to the legislator in question - We should surface if there are multiple requests for the same member (including a closed request if it was accepted and the Legislator is currently claimed). This may change if Matt V has other signals he'll be looking for to determine whether to accept these requests besides email address, but an admin should be able to see at a glance how many people are claiming ownership of one Legislator (so they at least know there's a conflict and don't auto-approve without realizing the ownership is contested).
2 participants
Summary
Addresses issue #2137
legislatorandpendingLegislator(mirroring organizations) as well as new routes to interact with this new account type and track which MA legislators already have profiles linked to them.Checklist
firestore.indexes.json(Please do not only create indexes through the Firebase Web UI, even though the error messages may recommend it - indexes created this way may be obliterated by subsequent deploys)Screenshots
Desktop
Mobile
Known issues
If you've run against limitations or caveats, include them here. Include follow-up issues as well.
Steps to test/reproduce
Go to the home page
Start the sign up flow
select "Legislator"
select a legislator from the drop down. This should filter our already selected legislators
Complete the sign up process normally
Check to ensure you cannot post testimony and the legislator specific message appears.
Log in as an admin
Check the
PENDINGLEGISLATORSrequests in the Upgrade Requests tab of the admin portalApprove your new legislator account
Check to see that you can post testimony and all blocks are cleared
Go to the home page
Click on a testimony
See that it's loaded with a loading spinner