feat(user): let members change their own details and additional membership improvements - #146
Open
tomudding wants to merge 8 commits into
Open
feat(user): let members change their own details and additional membership improvements#146tomudding wants to merge 8 commits into
tomudding wants to merge 8 commits into
Conversation
I like security, so now everything uses the same scheme as the password resets already use. Before, a renewal or payment link was a token that was stored as it was mailed and stayed in the address of the page it opened. A click from a mailbox is a navigation from another origin, so that token ended up in the referrer of everything the page loaded, stayed in the browser history, and arrived without the session cookie the form behind it needs. Action links now carry a split token, of which the register keeps the selector and a hash of the verifier. Following one exchanges it for a hash that is good for one use and three minutes (though we might want to increase that for this form), and the page that renews or restarts a checkout answers behind that, with the link held in the session. Because only the hash is kept, a link cannot be provided again. If this is required a new link must be generated.
This functionality was never implemented. Now that both applications are one it is also no longer necessary to keep around.
…s them All user-facing translatable messages must use `t()`, `new TranslatableMessage()`, or `trans()`. Without it, the translator does not pick it up properly, and you are at the mercy of your favourite AI agent to fix it for you.
For sake of transparency, show how the memberhsip of someone changed each year.
Member
Author
|
For transparency, Qwen3.8-27B reviewed (and edited) this code. |
Member
Author
5 tasks
5 tasks
tomudding
added a commit
that referenced
this pull request
Sep 4, 2026
Study never needed in GEWISWEB, so it was not included in ReportDB at the time. The board would like to have this information available, and to allow this to potentially become part of GH-146, I have now added the propagation logic. Existing rows are set to Unknown by the migration. They will be updated when the records are regenerated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Members can now change what the register holds about them: their email address,
their three addresses and the mailing lists that are theirs to manage, on a My
details page beside the other settings and behind sudo like them. What only the
secretary may change is shown there read-only, so everything on file is in one
place. Changing an email address takes effect only once a link sent to the new
address is followed while signed in, and the address that was replaced is told
that it happened; the subscriptions held under the old address are carried over
on the flush that writes it, wherever it was written from.
Whoever's membership is about to run out and who is not installed in a body is
now written to 45 days ahead and asked whether they want to stay on as a
graduate, because a student registered with a TU/e address stops being reachable
once they leave. They can accept, decline, or decline and ask the secretary to
remove their data. The secretary's bulk conversion stays for the people the
sweep cannot reach, and the two now settle one ending exactly once.
Both member pages also list the memberships somebody has held, and a weekly
check reports memberships that overlap or run backwards.
Along the way: action links (renewal, payment, and the two new kinds) carry a
split token of which only a hash is stored and are handed in for a single-use
claim, the way the password reset already worked; the dormant "pending member
updates" flow is dropped; and the messages the translation extractor could not
see, which
--cleanhad been deleting on every run, are written where it readsthem and translated.
Worth knowing when this deploys: every renewal and payment link currently in
somebody's mailbox stops working, four migrations run, the self-service flag is
off for every mailing list until the secretary turns it on, and two commands
join the schedule (
check:membership:conversion:graduateevery half hour,check:membership:consistencyweekly).Screenshots of the three new pages still to be added.
Related issues/external references
Fixes GH-118
Fixes GH-46
Fixes GH-66
Types of changes