Working fullstack (Cavai)

Denne guiden er laget for å gi en enkel "order of operations" når du skal forstå, endre og verifisere endepunkter og funksjonalitet som går gjennom backend og frontend (f.eks. rename på creatives).

1) Start med å finne endepunktet (routes)

• Backend routes er definert i Application-Backend/start/routes/*.
• Finn hvilken route som faktisk brukes.

Eksempel (creatives):

• Fil: Application-Backend/start/routes/creatives.ts
• Du finner at Route.resource('creatives', 'CreativeGroupCreativesController')... setter opp:
  • GET /v1/creatives
  • GET /v1/creatives/:id
  • PUT /v1/creatives/:id
  • POST /v1/creatives/:id/clone
  • osv.

Mål: vite nøyaktig hvilken controller/metode requesten treffer.

2) Gå til controller-metoden (business logic)

• Når du vet hvilken route, gå til controlleren.
• For creatives: Application-Backend/app/Controllers/Http/CreativeGroupCreativesController.ts

Her ser du:

• Hva endpointet gjør (update/clone/etc)
• Hvilke side-effekter det har (build, versjonering, logging, osv)
• Hvilke query params som påvirker flyt (f.eks. ?build=false)

3) Finn request.validate() (payload contract)

Backend er source of truth for hva payload forventer.

Se etter mønsteret:

• const payload = await request.validate({ schema: schema.create({ ... }) })

Regel:

• Felter uten .optional() er påkrevd.

Eksempel (update creative):

• name: required
• header_title: required
• creative_group_id: required

Mål: kunne si: "For å kalle PUT /creatives/:id må jeg sende X, Y, Z".

4) Se hva frontend får lov til å gjøre (Resources → links/actions)

Resources er backend-laget som former API-responsen (inkl. hvilke actions som vises i UI).

• For creative-group view: Application-Backend/app/Resources/CreativeGroupCreativeResource.ts

getLinks() returnerer et links-objekt, f.eks:

• edit: /v1/creatives/:id
• rename: /v1/creatives/:id
• clone: /v1/creatives/:id/clone

Policy sjekker hvilke actions brukeren faktisk har lov til:

• resolvedActions.update → gir edit/rename/clone

Mål: verifisere at "Rename" faktisk blir sendt til frontend som en tilgjengelig action.

5) Verifiser i browser først (Network → Response)

Før du bruker Insomnia, sjekk at backend faktisk returnerer det du tror.

1. Åpne DevTools → Network
2. Finn requesten som henter creatives
3. Se i Response:
   • Finn links.rename på en creative

Hvis links.rename er der, vet du at backend “annonserer” rename til frontend.

6) Verifiser hva frontend faktisk sender (Network → Request)

Når du klikker Rename i UI:

1. DevTools → Network
2. Klikk rename i UI
3. Finn requesten som går ut
4. Verifiser:
   • Method (skal være PUT for update)
   • URL (skal være /v1/creatives/:id)
   • Request body inneholder alle required felter fra backend validation

Mål: se eksakt payload som UI sender.

7) Bruk Insomnia for isolert testing (uten UI)

Insomnia er nyttig når du vil:

• teste endpoint før du implementerer i frontend
• reprodusere bug med kontrollert payload
• verifisere edge cases uten å klikke i UI

A) Autentisering i Insomnia (session cookie)

Hvis backend bruker session-auth (cookie), må Insomnia sende korrekt Cookie header.

Viktig skille:

• set-cookie = respons-header fra server (server “setter” cookies)
• Cookie = request-header fra klient (du “sender tilbake” cookies)

Du skal altså ikke sende set-cookie: i request.

B) Unngå doble Cookie: headers

Hvis Insomnia både:

• sender cookies via cookie-jar, og
• du legger inn manuell Cookie header

…kan du ende med to Cookie: headers i request, og auth kan feile.

Anbefaling:

• Velg én strategi:
  • enten cookie-jar (Manage Cookies)
  • eller manuell Cookie header

C) Riktig cookie-format

Når du sender cookies manuelt:

• Header name: Cookie
• Header value: name=value; name2=value2

Ta bare name=value-delen (før første ;) fra hver set-cookie.

8) Implementer i frontend

Typisk flyt i frontend:

1. links fra backend blir mappet til actions
2. Action-menyer viser kun actions som finnes i responsen
3. Når brukeren trykker "Rename":
   • åpne dialog
   • på confirm, kall updateCreative(id, payload)
4. Payload må matche backend request.validate()

Mål: frontend skal kalle riktig URL/method og sende riktig payload.

Eksempel: Rename flyt (konkret kjede)

Dette er den konkrete rekkefølgen for rename i creative-group view.

1. Backend annonserer actions (links)

• Fil: Application-Backend/app/Resources/CreativeGroupCreativeResource.ts
• Metode: getLinks()

Backend returnerer f.eks:

• links.rename = "/v1/creatives/:id" når policy tillater update.

1. Frontend lagrer links inn på raden som actions

• Fil: Application-Frontend/src/pages/Chatbots/index.vue

• Når table data bygges, ender du med et row-objekt som har:

• item.actions.rename (URL) hvis backend sendte links.rename.

1. tableActions bygger dropdown-menyen fra item.actions

• Fil: Application-Frontend/src/mixins/tableActions.ts

actions(item) gjør:

• filtrerer item.actions via whitelistedActions
• mapper action-navn til en handler med samme navn: this[action]

Konsekvens:

• Hvis rename ikke er i whitelistedActions, vises ikke Rename i menyen.
• Hvis komponenten/mixinen ikke implementerer rename(item), vil klikk ikke gjøre noe.

NB: rename()-stubben i tableActions.ts er primært en «kontrakt/placeholder» (og kan hjelpe type/forventning). Den er ikke i seg selv funksjonell, men det er nyttig at mixinen definerer at metoden finnes (og at en page kan override/implementere den).

1. creatives_table_mixin implementerer handlerne

• Fil: Application-Frontend/src/mixins/creatives_table_mixin.ts

Denne mixinen implementerer:

• rename(item) → åpner dialog, setter selectedItem og selectedAction = 'rename'
• renameCreative(newName) → gjør API-kallet

1. Dialog confirm ruter til riktig handling

• Fil: Application-Frontend/src/pages/Chatbots/index.vue

TextInputDialog sin @confirm sjekker selectedAction:

• rename → renameCreative($event)
• clone → duplicateChatbot($event)

1. Service-kall → backend update

• Fil: Application-Frontend/src/services/chatbotService.js
• Metode: updateCreative(creativeId, entity, build)

Den kaller:

• PUT /creatives/:id?build=false (når build=false)

1. Backend validerer payload

• Fil: Application-Backend/app/Controllers/Http/CreativeGroupCreativesController.ts
• Metode: update()

Denne krever at payload inneholder:

• name
• header_title
• creative_group_id

Debug: hvor du sjekker hva som feiler

• Hvis Rename ikke vises i UI:

  • Sjekk at backend response har links.rename
  • Sjekk at frontend row-objektet faktisk har actions.rename
  • Sjekk at rename finnes i whitelistedActions

• Hvis Rename vises men klikk ikke gjør noe:

  • Sjekk at rename(item) er implementert i en mixin/page (f.eks creatives_table_mixin.ts)

• Hvis Rename sender request men endrer ikke navn:

  • Sjekk Network → Request payload inneholder alle required felter
  • Sjekk at request går til PUT /v1/creatives/:id (ikke feil URL)

9) Debug checklist (hurtig)

• Ser du links.rename i API-responsen?
• Treffer frontend riktig endpoint (PUT /v1/creatives/:id)?
• Inneholder payload name, header_title, creative_group_id?
• Får du 422 med valideringsfeil, eller 200?
• Hvis Insomnia gir 401:
  • sjekk at request faktisk har Cookie: header
  • sjekk at du ikke sender to Cookie: headers
  • sjekk at cookie-verdiene er komplette