In deze aflevering is het doel om de SCR – Roll an Move flow aan de juiste speler aan te bieden op hun Player record pagina. Deze gebruiken we nu als het Dashboard waar de spelers vandaan zullen ‘werken’. Vooral omdat de Player record variabele voor deze flow alle benodigde input informatie biedt.

Een screen flow op een Lightning Page plaatsen is op zichzelf eenvoudig. Wat we echter wel willen bereiken, is dat spelers deze flow alleen kunnen gebruiken wanneer ze zelf aan de beurt zijn.

En daarvoor moeten we eerst een laag aan ons datamodel toevoegen: Game. We moeten dit gaan gebruiken voor een aantal zaken.

• Spelers behoren tot één bepaalde Game
• Binnen de Game zijn de spelers in een vaste volgorde aan de beurt
• De Game record moet kunnen aangeven welke speler op dat moment aan de beurt is

Verdere invloed van het Game object

Later zullen we het Game kader ook op de rest van het datamodel toepassen.

• Een Board bestaat binnen één Game
• De Positions op dat Board daardoor dus ook
• De Assets en Rules die aan die Positions gekoppeld zijn behoren ook tot één Game

Om het vergelijk met een fysieke versie van het spel te maken: elke afzonderlijke Game kun je zien als een andere doos met een eigen bord, pionnen, eigendomsbewijzen, kanskaarten en algemeen fonds kaarten. Je beweegt je pion over het bord waarop jij met jouw groep aan het spelen bent. Niet op het bord op de tafel naast je. Als je op Kans komt, krijg je de Kans kaart, die op jullie tafel bovenop de stapel ligt, niet die van de buurtafel. Een hetzelfde gaat ook op voor de Assets. In de groep aan de andere tafel kan iemand alle stations in handen hebben, maar als jij op een station belandt, betaal je geen huur aan de persoon aan de andere tafel. Die bezit namelijk geen enkel station op de tafel waar jij aan het spelen bent.

Die aanpassingen zijn echter voor een andere keer. Voor deze aflevering volstaat het om via de Game te weten wie er nu aan de beurt is.

De stappen voor deze aflevering

• We moeten een Game object maken.
• Op het Game Object moeten we een lookup maken naar Player. Deze vertegenwoordigt de Player die nu aan de beurt is.
• We moeten een Lookup Relatie maken op het Player object naar Game.
• We moeten een getal veld maken op Player dat de speelvolgorde van de verschillende Players in dezelfde Game aangeeft.
• Op het Player object moeten we een formule maken die aangeeft of deze speler nu aan de beurt is.
• We moeten een flow maken die de volgende speler die aan de beurt komt opzoekt en daarmee de Game record bijwerkt.
• Die flow moet helemaal aan het einde van de SCR – Roll and Move flow worden toegevoegd als subflow, want als de beurt van de ene speler klaar is, moet de beurt naar de volgende gaan.
• De zichtbaarheid van de SCR – Roll and Move flow, moeten we voorwaardelijk maken. Deze mag alleen op de Player pagina staan, wanneer deze speler aan de beurt is.

Het Game object

We hebben in deze serie de meeste objecten aangemaakt met schema builder. Het voordeel daarvan is dat velden aanmaken veel sneller gaat, maar het nadeel is dat je achteraf een tabblad en page layouts moet maken.

Dit keer gaan we het nieuwe object gewoon aanmaken via Object Manager.

Bij stap 2 kies ik ervoor dat het tabblad Hidden is voor alle profielen. We hebben immers besloten de toegang tot de Monopoly app en functionaliteiten te geven via de Permission Sets die we eerder gemaakt hebben.

Bij stap 3 voegen we dit nieuwe tabblad alleen toe aan de Monopoly app en niet aan alle andere apps.

We voegen de Active Player lookup toe aan het object. Omdat de lookup van Player naar Game nog niet bestaat, kunnen we nu het lookup filter nog niet meteen aanmaken. Daar komen we zometeen voor terug.

Ook voor dit veld vinken we in stap 4 de toegang op alle profielen weer uit, want alle toegang komt via de Permission Sets.

In stap 5 nemen we dit veld gewoon op in de standaard Page Layout voor het Game object. In stap 6 vinken we het opnemen van de Games related list op het Player object uit. Die hebben we niet nodig.

Nieuwe velden op het Player object

Op het Player object maken we nu 3 velden aan:

• Game – een lookup naar de Game waar deze Player in aan het spelen is.
• Hierna voegen we een lookup filter toe aan de Player lookup die we zojuist op het Game object gemaakt hebben.
• Playing Order – een getal dat aangeeft wanneer deze speler aan de beurt is.
• It’s my turn now – een formule met output checkbox die aangevinkt is wanneer deze speler aan de beurt is.

Game lookup

Omdat we zometeen nog een keer op het Game object moeten zijn, open ik een nieuw tabblad met Object Manager zodat ik het Game tabblad open kan laten.

Net zoals bij elk veld dat we voor ons Monopoly spel aanmaken nemen we de toegang op in geen van de profielen.

Anders dan bij het nieuwe Game object, hebben we voor Player al een Lightning Pagina en mogen we hier ook kiezen om dat nieuwe veld eraan toe te voegen en dat doen we ook.

De Related List met Player op het Game object willen we wél hebben, dus ook bij stap 7 laat je de vinkjes gewoon aan staan.

Nu moeten we deze nieuwe lookup velden eerst toevoegen aan onze Permission Set voor we het lookup filter kunnen maken.

Lookup filter

Nu de relatie van Player naar Game ook bestaat, kunnen we het lookup filter toevoegen aan de Game naar Player relatie die we net gemaakt hebben.

Een lookup filter is een voorwaarde waaraan een record moet voldoen om gekozen te mogen worden in dat relatieveld. Een Player mag aan de beurt zijn binnen een Game, alleen wanneer de Player tot die Game behoort.

In het bovenstaande voorbeeld mogen Anna, Boris en Chloë, die zelf meespelen in Game 001 wel de Active Player zijn van Game 001, maar Duco, Eline en Finn mogen dat niet voor Game 001. Omgekeerd mogen voor Game 002 juist alleen Duco, Eline en Finn als Active Player gekozen worden, want alleen zij doen mee aan dat potje.

Hiervoor openen we via Object Manager > Game > Fields & Relationships het veld Active Player en daar klikken we op Edit. Klik onder het kopje Lookup Filter op Show Filter Settings en selecteer onder Field: Current Lookup Active Player:

Kies vervolgens voor Game (let op: de versie zonder : erachter). Gebruik de Operator Equals, kies voor Field onder Value/Field en kies vervolgens voor Game: Record ID. Pas indien gewenst de tekst van de Error Message aan en sla op met de Save knop.

Playing Order

Hiervoor maken gewoon een eenvoudig Number field. 18 cijfers voor en 0 na de komma is prima. Verder kun je de instellingen laten staan zoals ze zijn.

Toegang tot het veld geven we wederom niet via Profielen. Wel mag het nieuwe veld meteen worden opgenomen op de Lightning Page en Page Layout.

It’s my turn now

Deze formule hebben we nodig om te bepalen of de SCR – Roll and Move flow zichtbaar mag zijn op de record pagina van de Player. De output van de formule is een checkbox. Deze moet aangevinkt of True zijn wanneer de Id van deze Player gelijk is aan de Id in het Active Player veld van de Game waar de Player in speelt. Net als de andere velden komt deze wel op de Lightning pagina en Pagina layout, maar in geen enkel Profiel.

De Permission Sets

Flow om de beurt van de volgende speler te starten

Dit wordt een eenvoudige autolaunched flow om aan het einde van de beurt van een speler in te voegen in de SCR- Roll and Move flow, waardoor de beurt hierna overgaat naar de volgende speler.

Zoals elke subflow die we tot nu toe voor in de SCR – Roll and Move flow gemaakt hebben, starten we ook hier weer met het aanmaken van de inputvariabele inputPlayer.

Eerst zoeken we naar de eerstvolgende speler binnen dezelfde Game met een hoger getal in het Playing Order veld.

Als de huidige actieve speler degene met het hoogste Playing Order nummer binnen die Game is, zullen we niets vinden en moeten we een andere zoekopdracht gebruiken. Omdat ik alleen het Player Id nodig heb uit één van beide zoekopdrachten, wil ik de uitkomst opslaan in één en dezelfde variabele. Daarom kiezen we nu niet voor Automatically store all fields onder How to Store Record Data. Op deze manier zal de variabele nextPlayerId sowieso het juiste Player Id bevatten. Of die nu in de eerste of de tweede zoekopdracht wordt gevonden.

Stel dat we 3 spelers hebben, Anna, Boris en Chloe, die de Playing Orders 1, 2 en 3 hebben.

Wanneer Anna nu aan de beurt is, zal de linker zoekopdracht het Id van Boris opleveren.

Aan het einde van de beurt van Boris, zal de linker zoekopdracht het Id van Chloe opleveren.

Aan het einde van Chloe’s beurt, levert de linker zoekopdracht null op en gaan we de rechter zoekopdracht gebruiken die weer naar Anna zal leiden.

Vervolgens kunnen we met een Update Records element het Active Player van de Game updaten. Nog een null check hiervoor is niet nodig. Stel dat er geen Player is die door één van beide zoekopdrachten wordt gevonden, dan zijn er geen Players of is iemand alleen aan het spelen en hoeft de Game dus helemaal geen Active Player te hebben.

Nu moeten we deze flow nog opslaan en activeren zodat we deze kunnen invoegen in de SCR – Roll and Move flow.

Deze nieuwe flow voegen we helemaal aan het einde toe in de SCR – Roll and Move flow.

SCR – Roll and Move op de Player Lightning Page plaatsen

In de Lightning App Builder op de pagina MON – LRP – Player kun je onder Components in de linkerbalk zoeken naar Flow. Deze slepen we op de pagina. We configureren dat de gegevens van de getoonde record meegegeven worden aan de inputvariabele (recordId) van de flow en we maken deze component voorwaardelijk zichtbaar: de flow wordt alleen zichtbaar wanneer It’s my turn now waar is.

Volgende keer

Voor we aan de slag gaan met hoe spelers vrij kunnen komen uit de gevangenis, gaan we in het volgende deel eerst een kleine, maar fijne verbetering aanbrengen. Bij het instellen van de voorwaardelijke zichtbaarheid van bepaalde secties en knoppen, kunnen we iets vereenvoudigen en dat gaan we in het volgende deel eerst even regelen.