Tools now includes a dedicated vBulletin registration layer that keeps the invite state, review queue, and final access decision in Tools while the actual forum account still lives in vBulletin.
Short version for operators who keep a separate Google Drive document:
/admin/security/vbulletin/admin/security/vbulletin/onboarding/keys/vbulletin/onboarding/vbulletin/onboarding/{slug} (enter the invite code manually) or /vbulletin/onboarding/{slug}/{inviteKey} (the code is already filled in)155 by defaultfield66)/vbulletin/onboarding/keysActive, Consumed, Expired, or Inactive), and keys that are already consumed/expired/inactive stay visible only for review while recipient edits plus Messenger/email send actions are locked/vbulletin/onboarding/keys page, and in the inline recipient editor. When that invite later gets approved, Tools can use the saved recipient email to unlock /vbulletin/onboarding/keys for that same person and send one follow-up mail with the delegated key page plus the currently visible invite list for that slugcore/api.php save step and then a separate-host-safe cache refresh step, so forum-side cache state can be refreshed immediately even when Tools and the forum do not run on the same serverphp artisan vbulletin:onboarding-syncOpen:
/admin/security/vbulletin
Required permission:vbulletin.managevbulletin.onboarding.reviewvbulletin.onboarding.keys.create plus a per-config grant from the admin pageEach config represents one registration flow, for example:
field66https://forum.tornevall.net155Every registration link belongs to one config. Key options:
referral or one_time
preferred public language (English or Svenska)
optional profile-field override when one specific key should use another vBulletin custom field than the config default
target vBulletin user.userid when the key belongs to one already known forum account
label
inviter/referrer name
optional inviter email (used when Tools detects the registration)
optional success destination URL / button label when one specific invite key should send the finished applicant to another destination than the onboarding config default
max uses
optional expiry
optional batch quantity when several invite links should be created in one go
expiry handling can now be no expiry, one exact date/time, or a relative extension by days
optional group override if the key should grant different groups than the config default After a key is created, Tools shows both:
the slug-only public URL (/vbulletin/onboarding/{slug})
the direct invite URL (/vbulletin/onboarding/{slug}/{inviteKey})
Admins can now configure three optional template fields per onboarding flow:
The same onboarding flow can now also keep default email sender values for outreach mail:
On the outreach composer, both sender fields autosave just like the templates do, so operators can prepare one reusable sender identity per registration flow instead of retyping it for every invite.
Those invite-composer template/sender fields are now saved when the operator leaves the field or switches to another invite, instead of interrupting typing in the middle of the textarea.
The registration email HTML template now also follows the Messenger registration template automatically until an operator explicitly writes a separate custom HTML version. That means changing the Messenger wording first is now enough for the default email body to stay in sync too.
Supported placeholders include:
{{recipient_name}}{{recipient_email}}{{invite_code}}{{invite_url}}{{config_name}}{{forum_destination_url}}{{forum_destination_label}}{{inviter_name}}{{inviter_email}}{{tools_user_name}}{{tools_user_email}}{{tools_support_email}} (the configured support address, support@tornevall.net by default)When the default templates should point people to support, they should now prefer {{tools_support_email}} instead of hardcoding a specific address.
On the admin and delegated key pages, the invite-outreach composer can then:
Important behavior:
Recommended wording for both Messenger and email templates:
{{tools_support_email}} and the person who gave them the inviteThe built-in default templates now follow that more pedagogical wording automatically when no custom template has been saved yet.
The admin page now keeps a clearer audit trail for registration-related steps.
Recent audit rows can now show events such as:
This makes it easier to confirm both code usage and real registration progress without having to guess from forum-side timestamps alone.
If the key was created with Swedish selected as the preferred public language, the generated URLs also carry the language choice so the public slug page, onboarding form, and later status page open in Swedish by default.
If a key-specific success destination URL is saved, the public status page uses that destination first when the onboarding finishes successfully. Otherwise, Tools still falls back to the onboarding config destination and then the main forum URL.
If the onboarding config uses an invite-code profile field and a target forum user is supplied, Tools now also writes the generated invite code into that user's userfield.fieldN column in vBulletin when the key is created. This lets one onboarding key be tied directly to one existing forum account before the applicant even opens the Tools-side onboarding page.
If that same profile field already contained an older invite value, Tools now stores a small assignment-history row that links the replaced value back to any matching older Tools key together with the vBulletin username that was affected.
Any public invite page backed by an invite-code profile field is now treated as an existing-account-first onboarding flow on the Tools side, even when the key already targets one known forum user. In practice that means the public page leads with the profile-field instructions first, shows the exact invite code clearly, and only then exposes the minimal Start onboarding step.
When admins or delegated key creators generate several invite links in one batch, Tools keeps the shared settings for every key, numbers the label automatically when a label was supplied, and lets the batch either stay without expiry, expire at one exact timestamp, or expire after a chosen number of days from creation.
Tools intentionally blocks bulk creation when the same batch would also write directly into one specific existing vBulletin account/profile field, because that would otherwise overwrite the same forum profile with a whole chain of different invite codes. Those account-bound invite keys should still be created one at a time.
When the onboarding config instead uses Existing forum account required first, the same invite-code profile field can be used without a preset target user. In that mode the applicant registers the forum account first, stores the invite key in the configured profile field manually, and then starts the Tools-side onboarding request.
Admins now also have a separate page at /admin/security/vbulletin/onboarding/keys focused on the day-to-day key workflow. The main /admin/security/vbulletin page is now the place where the flow itself is preconfigured (groups, templates, destination, profile-field mapping, and default max uses), while the key page stays simpler and expects most new keys to reuse those saved defaults.
Both the admin page and the delegated key-creator page now focus on one concrete recipient at a time instead of large bulk copy lists. Operators choose the onboarding flow, fill in the recipient/inviter details, and only open Advanced overrides when one specific key should behave differently than the preconfigured flow. Those same pages can still delete older referral/one-time keys that should no longer be used.
Those same key pages now also show one inline Sent to / assigned to field per invite key. As soon as an operator types the recipient's name there, Tools stores that name on the key itself and treats it as the current assignment marker for that invite link. Clearing the field removes that assignment again.
Admins can now grant a normal Tools user access to create more invite keys for one specific onboarding config.
/admin/security/vbulletinvbulletin.onboarding.keys.create/vbulletin/onboarding/keysBoth the delegated and admin key views now also keep a lightweight per-key recipient assignment field, so invite batches can be created first and then tagged afterwards with names such as Jessica, Menekse, or another real recipient without reopening a larger edit form.
The admin key-generator page at /admin/security/vbulletin/onboarding/keys now also includes a Google Docs export section for active invite keys. Each export block can copy:
Inbjudningskoder och länkar)Kod, Länk, and Person?There are two copy modes:
The page shows one export for all active invite keys together with per-flow exports, so operators can keep one broader overview or paste only one selected onboarding flow into a separate shared document.
If one invite is also marked as This is a trusted user, and that invite later reaches an approved onboarding decision, Tools can now grant the same recipient email delegated access to the slug on /vbulletin/onboarding/keys automatically and send one follow-up mail that points the person to that page. This trusted-user shortcut is intentionally tied to invites that have a real saved email recipient.
For ordinary invitees, the important part is now that the public page uses simpler wording: registration link, invite code, and a clearly named field where the code should be pasted.
Public entry page:
/vbulletin/onboardingSupported direct entry styles:
/vbulletin/onboarding/{slug} → user enters the invite code manually/vbulletin/onboarding/{slug}/{inviteKey} → the code is already embedded in the URLThe invited person opens the slug or key URL, then fills in:
For flows that require an already registered forum account, and for any direct link where the code must be stored in the profile first, the public page now starts with a welcome/instruction step instead of dropping straight into the form. That step uses simpler wording, shows the exact invite code clearly, shows the exact profile field name, and explicitly tells the applicant to paste the invite code into the shown fieldN field before continuing.
That existing-account step no longer requires the applicant to enter name or email again. The goal is simply: save the invite code in the profile first, then continue from the same page. Inviter/referrer context can still stay attached from the key itself.
The public hub can now be linked from Services / the front page and gives users a separate stylized page where they can:
If one onboarding flow should not be discoverable from that hub, the admin can now keep it hidden there. The direct slug URL and invite URLs still continue to work when they are shared privately.
There is now also a separate screenshot-driven walkthrough for Snöbollseffekten:
Tools creates an onboarding request and then tries to match the forum account immediately if it already exists.
When a key already targets one known vBulletin user through the invite-code profile-field mapping, Tools now prefers that forum user immediately instead of relying only on the older exact email / exact username match.
When the key is not tied to one preset forum user but does carry an invite-code profile-field mapping, Tools now also checks that profile field for the exact invite token. This lets existing-account onboarding tracks match the correct forum account after the applicant has saved the invite key in the profile.
Tools now also exposes a dedicated completion endpoint for a future vBulletin frontend script that runs after the forum registration page believes the account creation has finished:
POST /api/vbulletin/onboarding/invite/completeSuggested request body:
{
"invite_code": "once-example-code",
"forum_user_id": 123,
"forum_username": "exampleuser",
"forum_email": "user@example.com"
}
Current contract:
invite_code is required.invite_code may now be either the raw invite token or a full onboarding URL that contains the token; Tools strips the URL down to the actual code before lookupforum_user_id, forum_username, and forum_email are optional hints.forum_email is treated as an untrusted hint only. It can help Tools locate the new forum account, but it is never accepted as proof on its own.What Tools now does on that endpoint:
forum_account_linked or pending_review so a moderator can still make the final decisionImportant safety behavior:
Current implementation guidance for the later frontend script:
forum_user_id or forum_username when the forum registration flow exposes themIn practice, the recommended next step for the future forum-side script is still:
forum_user_id when the registration-complete page exposes itforum_username as an extra fallbackforum_email only when it is naturally available from the normal registration formThere is now also a dedicated practical frontend guide for this hook pattern, including hook arguments, adapted field66 bootstrap code, client-side invite-code normalization, a public fetch() example, and a styled success popup example:
The admin page shows pending requests and lets reviewers:
forum_user_idApprove/revoke and the manual grant/revoke buttons now do two things in one step:
That means the old workaround of opening the forum admin user editor and clicking Save, or manually opening Maintenance → Clear System Cache, should normally no longer be necessary for ordinary onboarding-related group changes even when Tools and vBulletin are hosted separately.
The admin page also includes a live forum-user search box. Use it to:
Command:
php artisan vbulletin:onboarding-sync
Optional full scan:
php artisan vbulletin:onboarding-sync --force
Laravel scheduler now also runs this automatically every five minutes.
Automatic approval happens when all of the following are true:
If that automatic forum-side group save fails for any reason, the public onboarding request is now still kept instead of crashing the invite page. Tools moves the request into Pending review so an admin can finish the approval later after the forum connection problem has been fixed.
The admin page lets you create multiple welcome/info messages with:
info, success, warning, neutral)The dedicated admin key-generator page also lists these welcome/info messages in a presentation-oriented view so admins can review what applicants and linked forum users may actually see for each slug/status combination. Tools serves them through:
/vbulletin/onboarding/messages.js
Recommended vBulletin include example:<script src="https://tools.tornevall.com/vbulletin/onboarding/messages.js?forum_user_id={$bbuserinfo.userid}"></script>
You can also place that script URL inside the existing vBulletin frontend script boxes area on the same admin page.
Every onboarding request gets its own status page so the invited user can see whether Tools is still waiting for the forum registration, whether the account has been linked, or whether the request has been approved/rejected.
That status page now also behaves more like a live progress page:
https://forum.tornevall.netThe main vBulletin admin page now also includes a small widget generator for paste-ready HTML blocks that can be dropped into a vBulletin HTML/snippet block.
Current built-in widgets:
We welcome our latest member {name}We keep growing! Right now we are {count} membersThese widgets are served from Tools through:
/vbulletin/widgets/latest-member.js/vbulletin/widgets/member-count.jsThe generator on /admin/security/vbulletin lets the admin choose:
{name} placeholder){count} placeholder)The generated output is a ready-to-paste HTML block containing one container <div> plus one hosted <script src="…"></script> include.
For existing-account onboarding tracks, the waiting state still explicitly reminds the applicant to check that the forum account already exists and that the invite key is stored in the configured profile field. The page is still meant to be revisited later, so applicants should bookmark it after submitting the onboarding form.
When an onboarding request is approved and the configured secondary forum group has been assigned successfully, Tools now also clears the same invite key from the configured vBulletin profile field if that field still contains the exact onboarding token. This keeps the profile field from holding stale invite codes after a finished onboarding.
This first version is intentionally simple: