← Back to docs

vBulletin-registrering & extern gruppadministration

Language: SV | EN | SV

vBulletin-registrering & extern gruppadministration

Tools har nu ett eget registreringslager för vBulletin där invite-status, granskningskö och slutligt åtkomstbeslut lagras i Tools medan själva forumkontot fortfarande bor i vBulletin.

Kortversion för dig som vill föra över ändringar till ett eget Google Drive-dokument:

Vad det nuvarande registreringsflödet täcker

  • Adminsida under /admin/security/vbulletin
  • Egen adminsida för nyckelgeneratorn under /admin/security/vbulletin/onboarding/keys
  • Egen publik registreringssida under /vbulletin/onboarding
  • Publik registreringsstartsida via antingen /vbulletin/onboarding/{slug} (skriv in inbjudningskoden manuellt) eller /vbulletin/onboarding/{slug}/{inviteKey} (koden är redan ifylld)
  • Varje registreringsflöde kan nu också ha ett eget valfritt välkomstmeddelande på den publika invite-sidan
  • Den publika registreringssidan listar nu bara de flöden som uttryckligen markerats för publik listning; dolda flöden fungerar fortfarande via delad direktlänk
  • Publika registreringssidor och statussidor finns nu både på engelska och svenska
  • Statussida per registreringsförfrågan
  • Konfigurerbara registreringsflöden med egen introduktionstext, regler och tillåtna vBulletin-grupp-ID:n
  • Tom gruppkonfiguration för registrering faller nu tillbaka till vBulletin-grupp 155 som standard
  • Valfri koppling från ett registreringsflöde till ett specifikt vBulletin-profilfält (till exempel field66)
  • Valfritt per-flöde-läge där forumkontot måste finnas i förväg innan den publika registreringsförfrågan startas
  • Referral-/engångsnycklar med maxanvändning och valfri utgångstid
  • Tydligare språk i nyckelgeneratorn där Referral link nu uttryckligen betyder den återanvändbara invite-varianten medan One-time key förblir engångsalternativet
  • Bulk-skapning av invite-länkar för både admins och delegerade nyckelskapare, inklusive lägena utan expiry, exakt expiry och förlängning i dagar
  • Delegerad nyckelskaparsida för vanliga användare under /vbulletin/onboarding/keys
  • Den delegerade nyckelsidan visar nu alla invite-nycklar för de slugs som kontot får hantera, inte bara nycklar som just det kontot själv skapade
  • Admin- och delegerade nyckelsidor kan nu också radera invite-nycklar via AJAX
  • Varje invite-nyckel kan nu också spara både namn på mottagaren/den tilldelade personen och mottagarens e-post, och de fälten autosparas via AJAX på både adminens och den delegerade nyckelsidan så att man snabbt ser vem som redan har fått vilken nyckel och vilken adress som är klar för invite-mail
  • Adminens och den delegerade nyckelsidan har nu också en invite-kompositör där man väljer en sparad mottagare från en lista, öppnar en konfigurerbar messenger-klar meddelandemall eller växlar över till en HTML-mailmall för direkt utskick
  • Invite-kompositören väntar nu tills du lämnar det aktuella mall-/avsändarfältet (eller byter invite) innan den sparar, så längre textändringar kastar inte längre ut markören ur textarea mitt under skrivandet
  • Invite-kompositören visar nu också varje invite-nyckels aktuella status direkt i mottagarlistan (Aktiv, Förbrukad, Utgången eller Inaktiv), och nycklar som redan är förbrukade/utgångna/inaktiva ligger kvar bara för granskning medan mottagarredigering samt Messenger-/mailutskick låses
  • Invite-nycklar kan nu också markeras som Testkod / endast dry run. De går fortfarande att använda för att prova hela onboardingflödet, men ett godkännande ger aldrig riktig forumåtkomst eller skarpa vBulletin-grupper.
  • Invite-nycklar kan nu också markeras som This is a trusted user både på adminens nyckelsida, på den delegerade sidan /vbulletin/onboarding/keys och i det inlineformulär där mottagare sparas. När en sådan invite senare blir godkänd kan Tools använda den sparade mottagaradressen för att låsa upp /vbulletin/onboarding/keys för samma person och skicka ett uppföljningsmail med nyckelsidan plus den aktuella invite-listan för sluggen
  • Livscykeln väntar/granskning/godkänd/nekad/revoked lagrad i Tools
  • AJAX-sökbar vBulletin-användarlista i admin
  • Begränsad grant/revoke av forumgrupper utifrån vald registreringskonfiguration
  • Samma scoped group writes triggar nu också ett fjärranrop till vBulletins core/api.php och därefter ett separat-host-säkert cache-refreshsteg, så forumets cachestatus kan uppdateras direkt även när Tools och forumet inte ligger på samma server
  • Schemalagd matchning av forumkonton via php artisan vbulletin:onboarding-sync
  • Välkomst-/informationsmeddelanden som kan visas i vBulletin via ett litet hostat JavaScript-include
  • Historik över profilfälts-assignments som kopplar äldre ersatta invite-värden till den nyare Tools-nyckeln och berört vBulletin-användarnamn

Adminflöde

Öppna:

  • /admin/security/vbulletin Nödvändiga rättigheter:
  • vbulletin.manage
  • åtgärder som approve/reject/revoke/link/group writes använder dessutom vbulletin.onboarding.review
  • delegerad skapning av invite-nycklar för vanliga användare använder vbulletin.onboarding.keys.create plus en per-config-grant från adminsidan

1. Skapa en registreringskonfiguration

Varje config representerar ett registreringsflöde, till exempel:

  • en forumdel/team/community-yta
  • en särskild invited-grupp
  • ett tillfälligt test-/provlopp Viktiga fält:
  • Namn / slug
  • Invite-code profile field ID när registreringsflödet ska synka varje invite-kod till ett dolt/redigerbart vBulletin-profilfält som field66
  • Befintligt forumkonto krävs först när sökanden måste registrera sig i vBulletin innan själva Tools-delen av registreringen öppnas
  • Introduction text som visas på den publika registreringssidan
  • Optional welcome message som kan visas som en separat välkomst-/infobox på den publika invite-sidan
  • Rules / minimum terms
  • List on public registration page när just det här flödet ska synas i den publika startsidan; lämna av när länken bara ska spridas privat
  • Forumdestinationens URL / etikett som används av den publika statussidan när åtkomsten är klar; lämnas fältet tomt faller Tools tillbaka till https://forum.tornevall.net
  • Allowed vBulletin group IDs
    • om fältet lämnas tomt faller Tools nu tillbaka till grupp 155
  • Manual review required
  • Auto approve
  • Relevant forum IDs (metadata/scope för senare utbyggnad)

2. Skapa referral eller engångsnyckel

Varje registreringslänk hör till en config. Alternativ för nyckeln:

  • referral eller one_time

  • valt publikt språk (English eller Svenska)

  • valfri override för profilfält när just den nyckeln ska använda ett annat vBulletin-fält än configens standard

  • mål-användare i vBulletin (user.userid) när nyckeln hör till ett redan känt forumkonto

  • label

  • inviter/referrer name

  • valfri inviter-email (används när Tools ser att registreringen är klar)

  • valfri redirect-URL / knappetikett för lyckad onboarding när just den här invite-nyckeln ska skicka användaren någon annanstans än configens standarddestination

  • max uses

  • valfri expiry

  • valfri batchstorlek när flera invite-länkar ska skapas i samma körning

  • expiry kan nu sättas till ingen expiry, ett exakt datum/klockslag eller en relativ förlängning i antal dagar

  • valfri group override om just den nyckeln ska ge andra grupper än configens standard När nyckeln skapats visar Tools nu både:

  • slug-URL:n (/vbulletin/onboarding/{slug})

  • den direkta invite-URL:n (/vbulletin/onboarding/{slug}/{inviteKey})

Mallar för invite-utskick

Admins kan nu konfigurera tre valfria mallfält per registreringsflöde:

  • Messenger-mall för registrering
  • Ämnesmall för registreringsmail
  • HTML-mall för registreringsmail

Samma onboardingflöde kan nu också lagra standardvärden för avsändaren i outreach-mail:

  • Avsändarnamn för registreringsmail
  • Avsändaradress för registreringsmail

I invite-kompositören autosparas båda avsändarfälten på samma sätt som mallarna, så operatören kan förbereda en återanvändbar avsändaridentitet per registreringsflöde i stället för att skriva om den varje gång.

Mall- och avsändarfälten sparas nu först när operatören lämnar fältet eller byter till en annan invite, i stället för att avbryta mitt i själva skrivandet.

HTML-mallen för registreringsmail följer nu också Messenger-mallen automatiskt tills en operatör uttryckligen skriver en egen separat HTML-version. Det betyder att det nu räcker att justera Messenger-texten först när man vill hålla standardmailet i synk.

Stödda platshållare:

  • {{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}} (den konfigurerade supportadressen, support@tornevall.net som standard)

När standardmallarna ska hänvisa vidare till supporten bör de nu använda {{tools_support_email}} i stället för att hårdkoda en viss adress.

På adminens och den delegerade nyckelsidan kan invite-kompositören därefter:

  • låta redan förbrukade/utgångna/inaktiva nycklar ligga kvar synliga med tydlig låsstatus i stället för att man råkar redigera eller skicka ut samma invite igen
  • öppna ett messenger-klart meddelande för vald mottagare
  • växla till en HTML-mailkompositör för samma mottagare
  • skicka ett testmail / dry run till det aktuella Tools-kontots e-postadress
  • skicka det riktiga HTML-mailet till den sparade mottagaradressen när sådan finns på nyckeln

Viktigt beteende:

  • dry-run-/teståtgärden skickar alltid det renderade mailet till det just nu inloggade Tools-kontots e-postadress
  • den skickar alltså aldrig av misstag en dry run till den sparade invite-mottagaren

Rekommenderad grundtext i både Messenger- och e-postmallar:

  • förklara att mottagaren ska öppna registreringslänken eller skriva in koden manuellt
  • berätta att forumregistreringen ska slutföras innan man väntar sig godkännande
  • påminn mottagaren om att spara sin personliga statussida när Tools visar den
  • nämn alltid att om koden eller länken inte fungerar ska mottagaren kontakta support@tornevall.net och personen som gav inbjudan

De inbyggda standardmallarna följer nu den här mer pedagogiska tonen automatiskt när ingen egen mall har sparats.

Auditlogg för registreringen

Adminsidan visar nu tydligare auditlogg för registreringsrelaterade steg.

Loggen kan nu till exempel visa:

  • när någon öppnar den publika registreringssidan för en invite-kod
  • när invite-koden faktiskt används för att skapa en registreringsförfrågan
  • när Tools fortfarande väntar på att forumregistreringen ska slutföras
  • när någon öppnar sin personliga registreringsstatus igen senare

Det gör det lättare att se både kodanvändning och faktisk registreringsprogress utan att behöva gissa från forumets tidsstämplar.

Om nyckeln skapades med svenska som publikt språk följer språkvalet också med i de genererade länkarna, så att slug-sidan, onboardingformuläret och den senare statussidan öppnas på svenska som standard.

Om en nyckelspecifik destinations-URL för lyckad onboarding sparas använder den publika statussidan den destinationen först när onboardingen blir klar. Annars faller Tools fortfarande tillbaka till onboarding-configens destination och därefter huvudforumets URL.

Om onboarding-configen använder ett invite-code-profilfält och en mål-användare i vBulletin anges, skriver Tools nu också den skapade invite-koden till just den användarens userfield.fieldN-kolumn i vBulletin när nyckeln skapas. På så sätt kan en onboardingnyckel kopplas direkt till ett redan existerande forumkonto innan användaren ens öppnar onboardingflödet i Tools.

Om samma profilfält redan innehöll ett äldre invite-värde sparar Tools nu också en liten assign-historikrad som försöker koppla det ersatta värdet tillbaka till en äldre Tools-nyckel tillsammans med vilket vBulletin-användarnamn som påverkades.

Alla publika invite-länkar som bygger på ett invite-code-profilfält behandlas nu också som ett befintligt-konto-först-flöde i Tools, även när nyckeln redan pekar mot en känd forumanvändare. I praktiken betyder det att den publika sidan visar profilfältsinstruktionerna först, visar den exakta invite-koden tydligt och först därefter öppnar det minimala steget Starta onboarding.

När admins eller delegerade nyckelskapare genererar flera invite-länkar i samma batch behåller Tools samma delade inställningar för varje nyckel, numrerar etiketten automatiskt när en label angavs och låter batchen antingen sakna expiry helt, få ett exakt slutdatum eller få en relativ giltighetstid i antal dagar från skapandet.

Tools blockerar medvetet bulk-skapning när samma batch samtidigt skulle skriva direkt till ett specifikt existerande vBulletin-konto/profilfält, eftersom samma forumprofil annars skulle överskrivas med en hel serie olika invite-koder. Sådana kontobundna invite-nycklar ska fortfarande skapas en och en.

När onboarding-configen i stället använder Befintligt forumkonto krävs först kan samma invite-code-profilfält användas utan någon förinställd mål-användare. I det läget registrerar sökanden forumkontot först, lägger in invite-nyckeln manuellt i det konfigurerade profilfältet och startar därefter själva Tools-delen av onboardingen.

Admins har nu också en separat sida på /admin/security/vbulletin/onboarding/keys som fokuserar på det dagliga nyckelarbetet. Huvudsidan /admin/security/vbulletin är nu tänkt som platsen där själva flödet förkonfigureras (grupper, mallar, destination, profilfältskoppling och default max uses), medan nyckelsidan hålls enklare och låter de flesta nya nycklar återanvända dessa sparade standarder.

Både adminsidan och den delegerade nyckelskaparsidan fokuserar nu på en konkret mottagare i taget i stället för stora copy-listor. Operatören väljer onboardingflöde, fyller i mottagare/inbjudare och öppnar bara Advanced overrides när just en viss nyckel måste avvika från det förkonfigurerade flödet. Samma sidor kan fortfarande radera äldre referral-/engångsnycklar när de inte längre ska användas.

Samma nyckelsidor visar nu också ett eget inlinefält Sent to / assigned to per invite-nyckel. Så fort operatören fyller i mottagarens namn sparar Tools det direkt på just den nyckeln och behandlar det som den aktuella tilldelningsmarkeringen för länken. Om fältet töms tas markeringen bort igen.

2b. Delegera nyckelskapning för en slug

Admins kan nu ge en vanlig Tools-användare rätt att skapa fler invite-länkar för en specifik onboarding-config.

  • granten sätts på configsidan under /admin/security/vbulletin
  • den delegerade användaren måste också ha permission vbulletin.onboarding.keys.create
  • den delegerade användaren får därefter en separat sida på /vbulletin/onboarding/keys
  • den sidan visar de onboarding-slugs som faktiskt delegerats till kontot, alla invite-nycklar som hör till dessa slugs samt den senaste historiken för profilfältsersättningar inom samma flöden
  • den delegerade sidan följer nu samma förenklade mönster som adminens nyckelsida: vanliga användare väljer främst flöde, mottagare och språk, medan admins behåller de riktiga standardinställningarna på huvudsidan för vBulletin-admin

Både den delegerade sidan och adminsidan har nu också ett lättviktigt per-nyckel-fält för mottagare/tilldelad person, så batcher med invite-länkar kan skapas först och sedan märkas upp i efterhand med namn som Jessica, Menekse eller annan verklig mottagare utan att man måste öppna ett större redigeringsformulär.

Adminens nyckelgenerator på /admin/security/vbulletin/onboarding/keys har nu också ett eget exportblock för Google Docs för aktiva invite-koder. Varje export kan kopiera:

  • en rubrik (Inbjudningskoder och länkar)
  • två korta registreringsinstruktioner
  • en riktig tabell med Kod, Länk och Person?

Det finns två kopieringslägen:

  • Kopiera som Google Docs-tabell försöker lägga både rik HTML och ren text på clipboard så att Google Docs kan klistra in det som en riktig tabell
  • Kopiera ren text behåller samma innehåll som fallback när webbläsaren inte kan skriva rik clipboard-data

Sidan visar både en export för alla aktiva invite-koder och separata exporter per onboardingflöde, så operatören kan välja mellan en bred översikt eller bara klistra in ett specifikt projekt/flöde i ett delat dokument.

Om en invite dessutom markeras som This is a trusted user och den inviteförfrågan senare blir godkänd kan Tools nu automatiskt ge samma mottagaradress delegerad åtkomst till sluggen på /vbulletin/onboarding/keys och skicka ett uppföljningsmail som pekar vidare dit. Den här trusted-user-genvägen är medvetet knuten till inviter som faktiskt har en sparad e-postmottagare.

För vanliga användare är det viktigaste nu att den publika sidan använder enklare ord: registreringslänk, inbjudningskod och ett tydligt namn på fältet där koden ska klistras in.

3. Publik onboardingstart

Publik ingångssida:

  • /vbulletin/onboarding

Stödda direktformat:

  • /vbulletin/onboarding/{slug} → användaren anger inbjudningskoden manuellt
  • /vbulletin/onboarding/{slug}/{inviteKey} → koden finns redan i URL:en

Den inbjudna personen öppnar slug- eller nyckel-URL:en och fyller i:

  • namn
  • e-post
  • planerat forumanvändarnamn (valfritt men hjälpsamt)
  • notering

För flöden som kräver ett redan registrerat forumkonto, och för alla direkta länkar där koden ska sparas i profilen först, börjar den publika sidan nu med ett välkomst-/instruktionssteg i stället för att kasta användaren direkt in i formuläret. Där förklaras i enklare språk att kontot måste finnas i förväg, den exakta inbjudningskoden visas tydligt för kopiering, rätt profilfält visas med namn och sidan säger uttryckligen att användaren ska klistra in inbjudningskoden i fältet fieldN innan man går vidare.

Det här befintligt-konto-läget kräver inte längre att sökanden fyller i namn eller e-post igen. Tanken är i stället: lägg in inbjudningskoden i profilen först och klicka sedan vidare här. Inbjudare/referrer kan fortfarande följa med från själva nyckeln.

Den publika hubben kan nu länkas från Services / startsidan och ger användaren en egen stylad sida där man kan:

  • läsa onboardingflödet innan start
  • klistra in hela registreringslänken eller bara inbjudningskoden
  • läsa slugens konfigurerade introduktionstext och regler med bevarade radbrytningar när sådana fält finns sparade
  • växla mellan engelska och svenska direkt på de publika onboardingsidorna
  • fortsätta till själva formuläret utan att adminsidan för vBulletin behöver vara synlig alls

Om ett onboardingflöde inte ska vara upptäckbart i hubben kan administratören nu lämna det olistat där. Själva slug-URL:en och direkta invite-länkar fortsätter ändå fungera när de delas privat.

För Snöbollseffekten finns nu också en separat steg-för-steg-guide med skärmdumpar:

Tools skapar en onboardingförfrågan och försöker därefter matcha forumkontot direkt om det redan finns.

När en nyckel redan pekar mot en känd vBulletin-användare via invite-code-profilfältet prioriterar Tools nu det forumkontot direkt i stället för att bara luta sig mot den äldre exakta matchningen på e-post / användarnamn.

När nyckeln inte är knuten till en förvald forumanvändare men ändå har en invite-code-profilfältsmappning kontrollerar Tools nu också just det profilfältet efter den exakta invite-tokenen. Det gör att onboardingflöden för redan registrerade konton kan matcha rätt forumkonto efter att sökanden har sparat invite-nyckeln i profilen.

API-hook efter färdig registrering för ett framtida forumscript

Tools exponerar nu också en särskild completion-endpoint för ett framtida vBulletin-frontendscript som körs när forumets registreringssida bedömer att kontot ser färdigskapat ut:

  • POST /api/vbulletin/onboarding/invite/complete

Föreslagen request-body:

{
  "invite_code": "once-example-code",
  "forum_user_id": 123,
  "forum_username": "exampleuser",
  "forum_email": "user@example.com"
}

Nuvarande kontrakt:

  • endpointen är publik för forumets frontend-hook och kräver ingen bearer-token
  • invite_code är obligatorisk.
  • invite_code kan nu vara antingen själva invite-tokenen eller en full onboarding-URL som innehåller tokenen; Tools plockar i så fall ut själva koden före lookupen
  • forum_user_id, forum_username och forum_email är valfria hjälpfält.
  • forum_email behandlas bara som en opålitlig hint. Den kan hjälpa Tools att hitta rätt forumkonto, men den accepteras aldrig ensam som bevis.

Det här gör Tools nu på endpointen:

  • validerar att invite-koden finns
  • försöker lösa rätt forumkonto så säkert som möjligt från invite-koden plus de forumidentiteter som skickas med
  • återanvänder en befintlig onboardingförfrågan för samma invite när en sådan redan finns, eller skapar en ny Tools-sida förfrågan när inviten fortfarande är giltig och ingen tidigare request finns än
  • länkar det upplösta forumkontot till inviten bara när kontot matchar de förväntade invite-villkoren
  • auto-approvar och ger forumåtkomst bara när den befintliga onboarding-configen redan tillåter automatisk approve utan manuell review
  • annars lämnas requesten i forum_account_linked eller pending_review så att moderator/reviewer fortfarande kan ta slutbeslutet

Viktigt säkerhetsbeteende:

  • om invite-nyckeln är bunden till en viss forumanvändare måste det upplösta kontot vara just den användaren
  • om onboardingflödet använder ett invite-code-profilfält kräver Tools nu att det upplösta forumkontot fortfarande innehåller samma invite-kod i just det konfigurerade vBulletin-profilfältet innan completion-anropet kan lyckas
  • upprepade completion-anrop för samma redan godkända invite är idempotenta: Tools returnerar det redan godkända läget i stället för att skapa dubblettförfrågningar eller ge åtkomst igen

Nuvarande implementationsråd för det framtida frontendscriptet:

  • den starkaste signalen är fortfarande invite-koden som sparats i det konfigurerade vBulletin-profilfältet
  • det framtida scriptet bör därför försöka bevara/läsa just det invitefältets värde tillsammans med forum_user_id eller forum_username när registreringsflödet exponerar dem
  • e-postfångst förblir valfri eftersom Google/Facebook/andra externa providerflöden inte alltid gör slutlig e-postadress stabilt tillgänglig för browser-JavaScript efter att registreringen slutförts

I praktiken är den rekommenderade nästa vägen för det framtida forumscriptet fortfarande:

  1. behåll invite-koden knuten till vBulletins anpassade profilfält när det flödet använder ett sådant fält
  2. fånga forum_user_id när sidan efter registreringen exponerar det
  3. skicka också med forum_username som extra fallback
  4. skicka forum_email bara när den naturligt finns tillgänglig från det vanliga registreringsformuläret

Det finns nu också en separat praktisk frontend-guide för just detta hookmönster, med hook arguments, anpassad bootstrap för field66, client-side-normalisering av invitekoden, publikt fetch()-exempel och exempel på en stylad success-popup:

4. Granskningskön

Adminsidan visar väntande förfrågningar och låter granskare:

  • länka en forumanvändare manuellt via forum_user_id
  • approve
  • reject
  • revoke tidigare given åtkomst

Approve/revoke och de manuella grant/revoke-knapparna gör nu två saker i samma steg:

  • uppdaterar själva medlemskapet i den tillåtna sekundärgruppen
  • anropar därefter vBulletins egen API-saveväg
  • kör sedan en separat-host-säker cache-refreshväg som i första hand använder en dedikerad fjärrendpoint eller direkt rensning av forumets cachetabeller via den konfigurerade forumdatabasanslutningen

Det betyder att den gamla nödlösningen att öppna forumets användaradmin och klicka Save, eller manuellt köra Maintenance → Clear System Cache, normalt inte längre ska behövas för vanliga onboardingrelaterade gruppändringar även när Tools och vBulletin driftas separat.

5. AJAX-sökbar forumanvändarsökning

Adminsidan innehåller också en live-sökning mot forumanvändare. Den används för att:

  • slå upp användare via användarnamn/e-post
  • se deras grupp-ID:n
  • se om de redan ligger i configens tillåtna gruppscope
  • grant/revoke configens grupper för just den användaren

Schemalagd matchning av forumkonton

Kommando:

php artisan vbulletin:onboarding-sync

Valfri full scan:

php artisan vbulletin:onboarding-sync --force

Laravel-schemat kör nu även detta automatiskt var femte minut.

Automatiskt godkännande sker när allt detta stämmer:

  • configen har Auto approve aktiverat
  • samma config kräver inte manuell granskning
  • Tools har redan lyckats matcha onboardingförfrågan mot ett riktigt vBulletin-konto

Om det automatiska forumsidiga gruppsparandet misslyckas sparas den publika onboardingförfrågan nu ändå i stället för att invite-sidan kraschar. Tools flyttar då förfrågan till Pending review så att en administratör kan slutföra godkännandet senare när forumkopplingen fungerar igen.

Välkomst-/infomeddelanden inne i vBulletin

Adminsidan låter dig skapa flera welcome/info-meddelanden med:

  • titel
  • brödtext
  • stil (info, success, warning, neutral)
  • valfri knapptext + URL
  • valfria målstatusar för onboarding
  • valfria målgrupp-ID:n

Den separata adminsidan för nyckelgeneratorn visar nu också dessa välkomst-/infomeddelanden i en mer presentationsinriktad vy, så admins lättare ser vad som faktiskt kan visas för användaren beroende på slug, status och gruppscope. Tools serverar dem via:

  • /vbulletin/onboarding/messages.js Rekommenderat vBulletin-include:
<script src="https://tools.tornevall.com/vbulletin/onboarding/messages.js?forum_user_id={$bbuserinfo.userid}"></script>

Du kan också lägga den script-URL:en i den befintliga sektionen vBulletin frontend script boxes på samma adminsida.

Publik statussida

Varje onboardingförfrågan får sin egen statussida så att den inbjudna personen kan se om Tools fortfarande väntar på forumregistreringen, om kontot har länkats eller om förfrågan blivit godkänd/nekad.

Statussidan fungerar nu också mer som en levande progressvy:

  • den visar en enda primär statusruta i stället för dubbla gröna success-rutor
  • den fortsätter polla i bakgrunden medan Tools fortfarande kontrollerar forumkonto / gruppåtkomst
  • när den konfigurerade forumåtkomsten väl är aktiv byter sidan till ett tydligt klart-läge i stället för att fortfarande låta som om granskning väntar
  • när åtkomsten är klar visas en knapp till den konfigurerade forumdestinationen tillsammans med en tydlig länktext för att klicka vidare manuellt
  • om ingen per-config-URL sparats faller Tools tillbaka till huvudforumet https://forum.tornevall.net

Extra HTML-block för vBulletin

På huvudsidan för vBulletin-admin finns nu också en liten widgetgenerator som skapar färdiga HTML-block att klistra in i ett vBulletin HTML-/snippet-block.

Nuvarande inbyggda widgets:

  • Senaste medlemmen för en eller flera valda forumgrupper, till exempel Vi välkomnar vår senaste medlem {name}
  • Medlemsantal för en eller flera valda forumgrupper, till exempel Vi växer hela tiden! Just nu är vi {count} medlemmar

Widgets serveras från Tools via:

  • /vbulletin/widgets/latest-member.js
  • /vbulletin/widgets/member-count.js

Generatorn på /admin/security/vbulletin låter administratören välja:

  • en eller flera forumgrupp-id:n
  • stylad ruta eller ren text
  • textmall för senaste-medlem-widgeten ({name}-placeholder)
  • textmall för count-widgeten ({count}-placeholder)

Resultatet blir ett färdigt HTML-block med en container-<div> och ett hostat <script src="…"></script>-include som kan klistras in direkt.

För onboardingflöden som kräver ett redan registrerat forumkonto påminner vänteläget fortfarande uttryckligen användaren om att kontrollera att forumkontot redan finns och att invite-nyckeln ligger i det konfigurerade profilfältet. Sidan är fortfarande tänkt att återbesökas senare, så användaren bör bokmärka den efter att onboardingformuläret sparats.

Rensning av invite-nyckeln efter godkännande

När en onboardingförfrågan godkänns och den konfigurerade sekundära forumgruppen har tilldelats tar Tools nu också bort samma invite-nyckel från det konfigurerade vBulletin-profilfältet, så länge fältet fortfarande innehåller exakt den onboardingtoken som nyckeln använder. På så sätt ligger gamla invite-koder inte kvar i profilen efter slutförd onboarding.

Noteringar / nuvarande begränsningar

Den här första versionen är medvetet enkel:

  • vBulletin är fortfarande källan till själva forumkontot
  • Tools gör bara scoped writes av sekundära grupper utifrån configens allowed group IDs
  • nuvarande forumkontomatchning bygger på exakt e-post / exakt användarnamn
  • relevant forum IDs lagras nu för framtida utbyggnad, men första versionen inspekterar ännu inte tråd-/posthistorik per forum innan approve
  • om användaren ska skickas till ett visst underforum direkt efter vBulletin-registrering är det fortfarande en forum-/vBulletin-fråga; Tools skriver inte över forumets egen post-register-redirect idag