Refactor member onboarding experience #177

Activity

1. wen-templari

   added

   enhancementNew feature or requestNew feature or request

   on Apr 19, 2025
2. wen-templari

   self-assigned this

   on Apr 19, 2025
3. wen-templari

   added the

   Feature

   issue type on Apr 19, 2025
4. wen-templari

   added this to Weekendon Apr 19, 2025
5. wen-templari

   moved this to 2025S1 in Weekendon Apr 19, 2025
6. m1ngsama commented on Sep 21, 2026

   

   m1ngsama

   on Sep 21, 2026

   Member

   More actions

   Hi @wen-templari, this issue is the remaining blocker for nbtca/Roadmap#64, so I'd love to see it move forward. I'm happy to help with the Saturday or Home side.

   While looking around, I noticed two things that might be useful:

   • Sunday's /register calls POST /members/{id}/logto, which was removed in the Huma migration, so self-registration is currently broken.
   • Approving a member in Sunday only updates Saturday's role column. It doesn't assign the Logto Repair Member role, which is what auth actually checks.

   I'm not sure how you'd like onboarding to work, e.g. who can apply or how Logto roles get assigned. I'd rather follow your design. If you can share the rough direction or split out a task, I'll pick it up.
7. wen-templari commented on Sep 21, 2026

   

   wen-templari

   on Sep 21, 2026

   MemberAuthor

   More actions

   After deprecating Sunday, we no longer have an UI for member/role management or an approval process. I am adding user using following steps:

   • Assign user role (Repair Member) in Logto admin panel
   • Add member (user) record in Saturday's database.

   Then after user login, role will be synced to Saturday's database.

   Here are the feature requirements I can think of:

   • Everyone should be able to apply access to repair tickets (with additional info like Personal No...)
   • User with role should be able to accept repair tickets
   • Admin should be able to review role requests
   • Admin should be able to manage user access (manual prevision/ off boarding)
   • Admin should be able to see audit log for User role operation

   For implementation, I am considering following two options

   A. Using external service built on Cloudflare workers. Provide: Initial application form, Role management, call Logto/ Saturday to sync role/ user info. (Could reference the previous join-us worker)
   B. Follow existing pattern, update Saturday and Home, add API and UI for onboarding/ user management.

   I personally prefer option A as it can move more of our infrastructure to Cloudflare. And as we are currently not only relay on Saturday's api for repair ticket but also for getting entire org's member list, we can move responsibilities to this worker.

   Please consider this and we can finalize an implementation plan.
   @m1ngsama @LazuliKao @Yuna-Celisse
8. m1ngsama commented on Sep 22, 2026

   

   m1ngsama

   on Sep 22, 2026

   Member

   More actions

   I ran Logto, Saturday and Home locally and walked the flow with four test accounts. Here is what the current setup does, and what we think the design should cover.

   Current behavior

   • Access needs two things: the Repair Member role in Logto, and a Saturday member row with a matching logto_id.
   • A user with the role but no member row can open /repair/admin, but every member API returns 401. The page shows an empty list and no error.
   • A user without the role is sent back to the login hint page. It gives no reason and no way to apply.
   • Roles are not synced on login from Home. The sync lives in GET /member/token/logto, and only Sunday calls it.
   • Saturday's member.role still matters. New-ticket notifications go only to members whose stored role is member or admin, and POST /members stores new members as member_inactive.
   • The self-registration route POST /members/{id}/logto was dropped in 045054f. Its handler is still in router/member.go.

   Our view

   • Option A works for us. We'd like Logto to be the only place that stores roles. Saturday already checks Logto on every request, so removing a role takes effect at once.
   • The worker should not have to write to both Logto and Saturday. If one write fails, we get the role-only state above. Instead, Saturday can create the member row on the first request from a user who has the role.
   • For that, the worker writes the student number and name into the user's Logto custom_data at approval. Home already requests the custom_data scope.
   • Notifications should read roles from Logto, not from member.role. Otherwise stored roles drift from real access.
   • Moving the org member list to the worker can wait until onboarding works.

   Questions

   • Do you add member rows with SQL or with POST /members? The API path stores them as member_inactive, so they get no new-ticket notifications.
   • What should the application collect, and who can see it?
   • Who deploys the worker and owns its Logto M2M credentials?
9. wen-templari commented on Sep 22, 2026

   

   wen-templari

   on Sep 22, 2026

   MemberAuthor

   More actions

   This worker should provide following features:

   For new user who want to join org,

   • Provide a form for info needed for entry (as we are requiring internal org member to have: Student No, Name, Class info). For existing users, open this form will show hint: already joined. For user had submitted form before, show hint about last submission. We should get user identity by putting this form behind auth.
   • Provide notification on entry form status change (approve/denied)

   For org admin,

   • UI for resolve new user request
   • UI for user management (manage those user in Saturday, basic info, account linking, role...)

   ---

   What should this worker store

   • new org user request record
   • audit log for approval, org user management

   For that, the worker writes the student number and name into the user's Logto custom_data at approval. Home already requests the custom_data scope.

   I would suggest not to use custom_data, as it is not meant to be used for storing sensitive data https://docs.logto.io/user-management/user-data#custom-data

   As for where should role be created after admin approves user join request, currently Saturday read role info from logto after user login, I think we can keep that way, and keep Saturday more clean and focus on repair ticket logic.

   👍React with 👍1Reacted by 小明
10. wen-templari commented on Sep 27, 2026

    

    wen-templari

    on Sep 27, 2026

    Last edited by wen-templari

    MemberAuthor

    More actions

    We can also consider merge https://github.com/nbtca/serverless-active and https://nbtca.space/freshman/join into this new design.