Uw startup opbouwen wijzigingen in de planning aanvragen

Wat je gaat creëren

Deze tutorial maakt deel uit van de Envato Tuts+ Bouw je Startup met PHP-serie. In deze serie begeleid ik je door het opstarten van een startup van concept naar realiteit met behulp van mijn Meeting Planner app als een realistisch voorbeeld. Elke stap die ik doe, zal ik de Meeting Planner-code vrijgeven als open-source voorbeelden waar je van kunt leren. Ik zal ook opstartgerelateerde zakelijke problemen aanpakken zodra deze zich voordoen.

Uw vergaderplannen wijzigen

Toen de alfaproeffase van de vergaderingplanner begon, was het grootste verschil in functie het onvermogen om een ​​vergadering te wijzigen nadat deze was gepland. Het is geen gemakkelijk probleem. Is het goed om een ​​vergadering te wijzigen zonder toestemming van een deelnemer? Of moet je dat vragen? Of ook, afhankelijk van uw rol bij het organiseren van de vergadering? Stel dat je gewoon wilt vragen of het oké is om 15 minuten later te voldoen - dat zou gemakkelijk moeten zijn, toch??

Het oplossen van dit alles vereiste enige reflectie op de sociale aspecten van het aanpassen van een vergadering. 

Na verloop van tijd realiseerde ik me dat het vermogen om vergaderingen gemakkelijk aan te passen nadat ze zijn gepland, het merk Meeting Planner kan maken of breken. 

In onze laatste aflevering over geavanceerde planning implementeerde ik Veranderingen maken, waarmee een organisator of deelnemer met het organiseren van machtigingen de vergadering in wezen opnieuw kan plannen zonder toestemming te vragen. In de tutorial van vandaag zal ik je begeleiden bij het bouwen van de Wijzigingen aanvragen infrastructuur. Het vereist dat deelnemers om wijziging (en) vragen en vervolgens kunnen anderen deze accepteren of weigeren, met gevolgen voor de definitieve vergaderkalenderdetails.

Terwijl u aan het lezen bent, hoop ik dat u de nieuwe functie "verzoek om wijziging" op de live site zult uitproberen en uw gedachten en feedback in de onderstaande opmerkingen kunt delen. Ik neem deel aan de discussies, maar je kunt me ook bereiken @reifman op Twitter. Ik sta altijd open voor nieuwe functie-ideeën voor Meeting Planner en suggesties voor toekomstige serie-afleveringen.

Ter herinnering, alle code voor Meeting Planner wordt open source gegeven en geschreven in het Yii2 Framework voor PHP. Als je meer wilt weten over Yii2, bekijk dan mijn parallelle serie Programming With Yii2.

Laten we beginnen.

Wijziging van bouwverzoek

Een hoge berg om te beklimmen

Afgezien van de vergaderingsweergave en planningsfuncties, vereiste Wijzigingen meer tijd en een nieuwe code dan enige andere functie in dit project.

Zoals ik in de vorige aflevering al zei, duurt het een beetje langer dan allesomvattende prototypes om alles met elementaire beveiliging te coderen, maar het ontwerpen en bouwen van deze functie heeft ook veel andere platformgebieden getroffen:

  • Ontwerpen met de social engineering van het aanvragen van en het maken van wijzigingen in het schema.
  • De UX voor wijzigingsverzoeken eenvoudig houden, mensen helpen bij het aanvragen en reageren op wijzigingsverzoeken zonder de interface te overbelasten.
  • Afhandeling van aanvragen voor 1: 1-vergaderingen zou eenvoudig zijn, maar coderen voor de aankomende functie voor meerdere deelnemers zou een veel geavanceerdere infrastructuur vereisen.
  • Afhandeling van de antwoorden op verzoeken met meerdere deelnemers verderop.
  • E-mailberichten over nieuwe en ingetrokken verzoeken, geaccepteerde en geweigerde reacties.
  • Het bijwerken van de vergaderingbevestiging en kalendergegevens wanneer geaccepteerde verzoeken van invloed zijn op het schema.

Hoewel dit geen perfect beeld is van de wijzigingen alleen voor deze functie, zijn hier schermafbeeldingen van de uiteindelijke productie-servercode aanwezig.

Dit zijn de wijzigingen in de bestaande code:

En hier zijn de nieuwe bestanden:

Er was veel nieuwe code bij deze functie betrokken.

De tabellen en hun migraties

Uiteindelijk heb ik gekozen voor een architectuur gebouwd rond twee tafels. De eerste was verzoeken:

$ this-> createTable ('% request', ['id' => Schema :: TYPE_PK, 'meeting_id' => Schema :: TYPE_INTEGER. 'NOT NULL DEFAULT 0', 'requestor_id' => Schema: : TYPE_BIGINT. 'NOT NULL DEFAULT 0', 'completed_by' => Schema :: TYPE_BIGINT. 'NOT NULL DEFAULT 0', 'time_adjustment' => Schema :: TYPE_SMALLINT. 'NOT NULL DEFAULT 0', 'alternate_time' => Schema :: TYPE_BIGINT. 'NOT NULL DEFAULT 0', 'meeting_time_id' => Schema :: TYPE_BIGINT. 'NOT NULL DEFAULT 0', 'place_adjustment' => Schema :: TYPE_SMALLINT. 'NOT NULL DEFAULT 0', 'meeting_place_id' => Schema :: TYPE_BIGINT. 'NOT NULL DEFAULT 0', 'note' => Schema :: TYPE_TEXT. 'NOT NULL DEFAULT ""', 'status' => Schema :: TYPE_SMALLINT. 'NOT NULL DEFAULT 0', 'created_at' => Schema :: TYPE_INTEGER. 'NOT NULL', 'updated_at' => Schema :: TYPE_INTEGER. 'NOT NULL',], $ tableOptions); $ this-> addForeignKey ('fk_request_meeting', '% request', meeting_id ',' % meeting ',' id ',' CASCADE ',' CASCADE '); $ this-> addForeignKey ('fk_request_user', '% request', requestor_id ',' % user ',' id ',' CASCADE ',' CASCADE '); 

Hier zijn de constanten die het model verder uitleggen:

 const STATUS_OPEN = 0; const STATUS_ACCEPTED = 10; const STATUS_REJECTED = 20; const STATUS_WITHDRAWN = 30; const TIME_ADJUST_NONE = 50; const TIME_ADJUST_ABIT = 60; const TIME_ADJUST_OTHER = 70; const PLACE_ADJUST_NONE = 80; const PLACE_ADJUST_OTHER = 90;

Er zijn twee manieren om de tijd aan te passen: TIME_ADJUST_ABIT, dat wil zeggen intervallen van minuten of uren eerder of later dan de gekozen tijd, of TIME_ADJUST_OTHER, een andere vergadertijd helemaal.

En de tweede tafel was RequestResponses:

$ this-> createTable ('% request_response', ['id' => Schema :: TYPE_PK, 'request_id' => Schema :: TYPE_INTEGER. 'NOT NULL DEFAULT 0', 'responder_id' => Schema: : TYPE_BIGINT. 'NOT NULL DEFAULT 0', 'note' => Schema :: TYPE_TEXT. 'NOT NULL DEFAULT ""', 'response' => Schema :: TYPE_SMALLINT. 'NOT NULL DEFAULT 0', 'created_at' => Schema :: TYPE_INTEGER. 'NOT NULL', 'updated_at' => Schema :: TYPE_INTEGER. 'NOT NULL',], $ tableOptions); 

Kortom, wie heeft de wijziging aangevraagd, wie heeft erop gereageerd en wat de reactie was: accepteren of weigeren.

De tweede tabel is nodig voor een omgeving met meerdere deelnemers.

Een wijziging aanvragen

Vergaderorganisatoren en deelnemers hebben toegang Wijzigingen aanvragen via de vervolgkeuzelijst opties menu dat we in de laatste aflevering hebben gebouwd:

Het wijzigingsformulier voor aanvragen

RequestController.php's actionCreate () laadt het formulier waaruit het verzoek van de gebruiker verandert:

En hier begon de complexiteit. Welke soorten wijzigingen kunnen deelnemers vragen??

  • Wil je eerder of later ontmoeten??
  • Wil je elkaar ontmoeten op een heel ander moment??
  • Wil je elkaar op een andere plaats ontmoeten??

Notitie: Ik heb nog niet de mogelijkheid geïmplementeerd om nieuwe plaatsen en tijden toe te voegen. Momenteel kunt u alternatieve datumtijden en plaatsen kiezen voor plaatsen die zijn aangeboden tijdens het planningsproces.

Een dropdown van eerdere en latere tijden

De code om de vervolgkeuzelijst te maken was ingewikkeld. Ik heb het zo gemaakt dat je twee en een half uur vroeger of later kon kiezen, in stappen van 15 minuten in de buurt van de oorspronkelijke tijd en daarna in stappen van 30 minuten:

voor ($ i = 1; $ i<12;$i++)  // later times if ($i<4 || $i%2 == 0)  $altTimesList[$chosenTime->start + ($ i * 15 * 60)] = Ontmoeting :: friendlyDateFromTimestamp ($ chosenTime-> beginnen + ($ i * 15 * 60), $ tijdzone, false);  // eerdere tijden $ earlyIndex = ((12- $ i) * - 15); if ($ i% 2 == 0 || $ i> = 9) $ altTimesList [$ chosenTime-> start + ($ earlyIndex * 60)] = Meeting :: friendlyDateFromTimestamp ($ chosenTime-> start + ($ deerIndex * 60) , $ tijdzone, false);  $ altTimesList [$ chosenTime-> start] = '────────────────────'; $ altTimesList [-1000] = Yii :: t ('frontend', 'Selecteer een alternatieve tijd hieronder'); ksort ($ altTimesList);

Ik heb gevuld $ altTimesListmet toetsen van elke mogelijke tijd met waarden van de vriendelijke tijd aangepast voor de tijdzone van de gebruiker. Toen gebruikte ik ksort () om de vervolgkeuzelijst zo te sorteren dat eerdere tijden eerder verschenen.

Een van de adviseurs van Meeting Planner (ik heb er momenteel slechts één), stelde voor de momenteel geselecteerde vergadertijd te laten zien, wat ik hieronder deed. Ik heb ook een scheidingsteken toegevoegd met de optie Uitgeschakeld in een vervolgkeuzelijst. Het verdeelt eerdere tijden van latere tijden maar is niet selecteerbaar:

Dit is de dropdown-code, die laat zien hoe je het scheidingsteken uitschakelt op basis van de scheidingstabel $ currentStart indexsleutel:

field ($ model, 'alternate_time') -> label (Yii :: t ('frontend', 'Kies een tijd iets eerder of later dan currentStartStr', ['currentStartStr' => $ currentStartStr])) -> dropDownList ($ altTimesList, ['options' => [$ currentStart => ['disabled' => true]]]); ?> 

En wanneer deelnemers een van de andere keren willen kiezen, is er JQuery om de vervolgkeuzelijsten te wijzigen, een andere complexiteit voor het bouwen van de formulieren:

 registerJsFile (MiscHelpers :: buildUrl (). '/ js / request.js', ['depends' => [\ yii \ web \ JqueryAsset :: className ()]]); ?> 

Hier is /frontend/web/js/request.js:

 $ ("# adjust_how") .change (function () if ($ ("# adjust_how") .val () == 50) $ ("# choose_earlier"). addClass ('hidden'); $ (" #choose_another "). addClass ('hidden'); else if ($ (" # adjust_how ") .val () == 60) $ (" # choose_earlier "). removeClass ('hidden'); $ (" #choose_another "). addClass ('hidden'); else $ (" # choose_earlier "). addClass ('hidden'); $ (" # choose_another "). removeClass ('hidden');); 

Dit is hoe het formulier eruit ziet met de alternatieve tijden verborgen:

Verschillende plaatsen zijn gewoon geïntegreerd in de vervolgkeuzelijst van de plaats (zoals u kunt zien aan de bovenste, afgebeelde afbeelding).

De aanvraag afhandelen

Zodra het verzoek is gedaan, stellen we de aanvrager op de hoogte dat andere deelnemers aan de vergadering op de hoogte worden gebracht. En, wanneer er actieve verzoeken zijn voor een vergadering, is er een link naar Bekijk ze:

Ik besloot dat dit een eenvoudige, overzichtelijke benadering zou zijn voor mensen om toegang te krijgen tot verzoeken.

De lijst met vergaderverzoeken

Hier is de lijst met verzoeken voor een vergadering, meestal slechts één:

Request :: buildSubject () maakt de bovenstaande string op basis van de inhoud van de aanvraag, d.w.z. tijd en / of plaatswijziging:

openbare statische functie buildSubject ($ request_id, $ include_requestor = true) $ r = Verzoek: findOne ($ request_id); $ requestor = MiscHelpers :: getDisplayName ($ r-> requestor_id); $ timezone = MiscHelpers :: fetchUserTimezone (Yii :: $ app-> user-> getId ()); $ rtime = "; $ place ="; switch ($ r-> time_adjustment) case Request :: TIME_ADJUST_NONE: break; case Request :: TIME_ADJUST_ABIT: $ rtime = Meeting :: friendlyDateFromTimestamp ($ r-> alternate_time, $ timezone); breken; aanvraag: :: TIME_ADJUST_OTHER: $ t = MeetingTime :: findOne ($ r-> meeting_time_id); if (! is_null ($ t)) $ rtime = Meeting :: friendlyDateFromTimestamp ($ t-> start, $ timezone) ;;  pauze;  if ($ r-> place_adjustment == Verzoek: PLACE_ADJUST_NONE || $ r-> place_adjustment == 0 && $ r-> meeting_place_id == 0) // do nothing else // get place name $ place = MeetingPlace :: findOne ($ r-> meeting_place_id) -> plaats-> name;  $ result = $ aanvrager.Yii :: t ('frontend', 'gevraagd om te voldoen aan'); if ($ rtime == "&& $ place ==") $ result. = Yii :: t ('frontend', 'oeps ... er zijn geen wijzigingen aangevraagd.');  else if ($ rtime <> ") $ result. = $ rtime; if ($ place <>") $ result. = Yii :: t ('frontend', 'and');  if ($ plaats <> ") $ result. = $ place; return $ result; 

Deze functie wordt ook herhaaldelijk gebruikt in e-mailmeldingen.

Er zijn ook limieten in RequestController.php die voorkomen dat gebruikers meer dan één verzoek per vergadering tegelijkertijd doen:

public function actionCreate ($ meeting_id) // verifiëren is deelnemer als (! Meeting :: isAttendee ($ meeting_id, Yii :: $ app-> user-> getId ())) $ this-> redirect (['site / authfailure ']);  if (Request :: countRequestorOpen ($ meeting_id, Yii :: $ app-> user-> getId ())> 0) $ r = Request :: find () -> where (['meeting_id' => $ meeting_id ]) -> enWhere (['requestor_id' => Yii :: $ app-> user-> getId ()]) -> andWhere (['status' => Request :: STATUS_OPEN]) -> one (); Yii :: $ app-> getSession () -> setFlash ('info', Yii :: t ('frontend', 'U heeft al een bestaand verzoek hieronder.')); return $ this-> redirect (['view', 'id' => $ r-> id]);  

Hier is de pagina met weergaveaanvragen die de beperking toont:

Als het uw eigen verzoek is, kunt u Trek uw verzoek in.

Zoals je kunt zien, was er veel verschillende UX-functionaliteit om hiervoor te bouwen. En ik heb je niet laten zien wanneer andere mensen dan de aanvrager reageren.

E-mails voor aanvraag en reactie-kennisgeving

Bij het bouwen van deze functies heb ik besloten om te maken generic_html en generic_text e-mailsjablonen en een herbruikbare Request :: melden () functie om de bezorging van verschillende soorten aankondigingen rondom Meeting Planner te vergemakkelijken.

Hier is de Request :: create () methode voor het opstellen van een e-mail:

public function create () $ user_id = $ this-> requestor_id; $ meeting_id = $ this-> meeting_id; $ subject = Verzoek: buildSubject ($ this-> id); $ content = ['subject' => Yii :: t ('frontend', 'Change Requested to Your Meeting'), 'heading' => Yii :: t ('frontend', 'Requested Change to Your Meeting'), 'p1' => $ subject, 'p2' => $ this-> note, 'plain_text' => $ subject. ". $ this-> note. '...' .Yii :: t ('frontend', 'Reageren op het verzoek via deze link: '),]; $ button = [' text '=> Yii :: t (' frontend ',' Reageren op verzoek '),' command '=> Meeting :: COMMAND_VIEW_REQUEST,' obj_id '=> $ this-> id,]; $ this-> notify ($ user_id, $ meeting_id, $ content, $ button); // toevoegen aan log MeetingLog :: add ($ meeting_id, MeetingLog :: ACTION_REQUEST_SENT, $ user_id , 0);

De $ inhoudarray wordt ingevuld voor het e-mailonderwerp, de berichtkop en paragrafen, terwijl de $ button array wordt gebruikt voor elke opdrachtknop, zoals Reageren op verzoek of Bekijk vergadering.

Hier is de de hoogte () methode, vergelijkbaar met de vorige sturen() en afronden() acties die e-mail verzenden:

public static function notify ($ user_id, $ meeting_id, $ content, $ button = false) // stuurt een generiek bericht op basis van argumenten $ mtg = Meeting :: findOne ($ meeting_id); // bouw een deelnemersarray voor alle deelnemers zonder contactgegevens $ cnt = 0; $ deelnemers = array (); foreach ($ mtg-> deelnemers als $ p) $ auth_key = \ common \ models \ User :: find () -> where (['id' => $ p-> deelnemer_id]) -> one () -> inlogcode; $ deelnemers [$ cnt] = ['user_id' => $ p-> participant_id, 'auth_key' => $ auth_key, 'email' => $ p-> deelnemer-> email, 'gebruikersnaam' => $ p-> participant-> gebruikersnaam]; $ Cnt + = 1;  // organisator toevoegen $ auth_key = \ common \ models \ User :: find () -> where (['id' => $ mtg-> owner_id]) -> one () -> auth_key; $ deelnemers [$ cnt] = ['user_id' => $ mtg-> owner_id, 'auth_key' => $ auth_key, 'email' => $ mtg-> owner-> email, 'username' => $ mtg-> eigenaar-> gebruikersnaam]; // gebruik deze code om foreach te sturen ($ deelnemers als $ cnt => $ a) // controleer of e-mail in orde is en ok van deze afzender_id als ($ user_id! = $ a ['user_id'] && Gebruiker :: checkEmailDelivery ($ a ['user_id'], $ user_id)) Yii :: $ app-> timeZone = $ timezone = MiscHelpers :: fetchUserTimezone ($ a ['user_id']); // Bouw de absolute links naar de vergadering en commandeert $ links = ['home' => MiscHelpers :: buildCommand ($ mtg-> id, Meeting :: COMMAND_HOME, 0, $ a ['user_id'], $ a [' auth_key ']),' view '=> MiscHelpers :: buildCommand ($ mtg-> id, Meeting :: COMMAND_VIEW, 0, $ a [' user_id '], $ a [' auth_key ']),' footer_email '=> MiscHelpers :: buildCommand ($ mtg-> id, Meeting :: COMMAND_FOOTER_EMAIL, 0, $ a ['user_id'], $ a ['auth_key']), 'footer_block' => MiscHelpers :: buildCommand ($ mtg-> id , Meeting :: COMMAND_FOOTER_BLOCK, $ user_id, $ a ['user_id'], $ a ['auth_key']), 'footer_block_all' => MiscHelpers :: buildCommand ($ mtg-> id, Meeting :: COMMAND_FOOTER_BLOCK_ALL, 0, $ a ['user_id'], $ a ['auth_key']),]; if ($ button! == false) $ links ['button_url'] = MiscHelpers :: buildCommand ($ mtg-> id, $ button ['command'], $ button ['obj_id'], $ a ['user_id '], $ a [' auth_key ']); $ Inhoud [ 'BUTTON_TEXT'] = $ knop [ 'text'];  // verzend het bericht $ message = Yii :: $ app-> mailer-> compose (['html' => 'generic-html', 'text' => 'generic-text'], ['meeting_id' = > $ mtg-> id, 'sender_id' => $ user_id, 'user_id' => $ a ['user_id'], 'auth_key' => $ a ['auth_key'], 'links' => $ links, ' inhoud '=> $ inhoud,' meetingSettings '=> $ mtg-> meetingSettings,]); // te doen - volledige naam $ message-> setFrom (array ('[email protected] '=> $ mtg-> owner-> email)); $ Bericht-> setReplyTo (. 'Mp _' $ mtg-> id '@ meetingplanner.io'.); $ message-> setTo ($ a ['email']) -> setSubject ($ content ['subject']) -> send (); 

In wezen is de lay-out generic_html.php gebaseerd op de eenvoudige tekstuele bijwerksjabloon waar ik het over had in onze zelfstudies over e-mailsjablonen. Het biedt een goed opgemaakte manier om deelnemers via e-mail met een paar alinea's bij te werken.

Hier is het viewbestand generic_html.php met de integratie van de $ inhoud en $ button gegevens. Het controleert op een tweede en derde alinea, bijv. $ p2, $ p3en $ button gegevens:

  

Hoi ,

") ?>

") ?>

"Cabin", Helvetica, Arial, sans-serif; font-size: 14px; font-weight: regelmatig; line-height: 45 pixels; mso-hide: alles; text-align: center; width: 155px "bgcolor =" # ff6f6f ">

Hier is een voorbeeld van een melding dat Rob Smith heeft mij gevraagd om onze vergadertijd en -plaats te wijzigen (gegenereerd op basis van de bovenstaande code):

Reageren op verzoeken

Wanneer ik klik Reageren op verzoek, Ik word meegenomen naar de Aanvraag antwoord controleur actionCreate () methode:

Gedurende de UX-aanvraag heb ik de mogelijkheid voor mensen opgenomen om notities te schrijven die context bieden voor de verzoeken en antwoorden.

Een uitdaging van dit formulier was het bepalen van de manier waarop antwoorden op verschillende controlemechanismen konden worden gestuurd op basis van de knop waarop werd geklikt. Met andere woorden, onderscheid maken tussen verschillende verzend POST-knopklikken.

public function actionCreate ($ id) $ request = Request :: findOne ($ id); if (! Meeting :: isAttendee ($ request-> meeting_id, Yii :: $ app-> user-> getId ())) $ this-> redirect (['site / authfailure']);  // heeft deze gebruiker al gereageerd $ check = RequestResponse :: find () -> where (['request_id' => $ id]) -> and Where (['responder_id' => Yii :: $ app-> user- > getId ()]) -> count (); if ($ check> 0) Yii :: $ app-> getSession () -> setFlash ('error', Yii :: t ('frontend', 'Sorry, je hebt al gereageerd op dit verzoek.')); return $ this-> redirect (['meeting / view', 'id' => $ request-> meeting_id]);  if ($ request-> requestor_id == Yii :: $ app-> user-> getId ()) Yii :: $ app-> getSession () -> setFlash ('error', Yii :: t ('frontend ',' Sorry, kan niet reageren op uw eigen verzoek. ')); return $ this-> redirect (['meeting / view', 'id' => $ request-> meeting_id]);  $ subject = Verzoek: buildSubject ($ id); $ model = new RequestResponse (); $ model-> request_id = $ id; $ model-> responder_id = Yii :: $ app-> gebruiker-> getId (); if ($ model-> load (Yii :: $ app-> request-> post ())) $ posted = Yii :: $ app-> request-> post (); if (isset ($ posted ['accept'])) // accept $ model-> response = RequestResponse :: RESPONSE_ACCEPT; $ Model-> save (); $ Aanvraag-> accepteren ($ model); Yii :: $ app-> getSession () -> setFlash ('succes', Yii :: t ('frontend', 'Verzoek geaccepteerd. We zullen de details van de vergadering bijwerken en andere deelnemers informeren.'));  else // reject $ model-> response = RequestResponse :: RESPONSE_REJECT; $ Model-> save (); $ Aanvraag-> verwerpen ($ model); Yii :: $ app-> getSession () -> setFlash ('succes', Yii :: t ('frontend', 'Uw weigering is geregistreerd. We zullen andere deelnemers dit laten weten.'));  return $ this-> redirect (['/ meeting / view', 'id' => $ request-> meeting_id]);  else return $ this-> render ('create', ['model' => $ model, 'subject' => $ subject, 'meeting_id' => $ request-> meeting_id,]); 

Hier is /frontend/views/request-response/_form.php:

field ($ model, 'note') -> label (Yii :: t ('frontend', 'Include a note')) -> textarea (['rows' => 6]) -> hint (Yii :: t ('frontend', 'optioneel'))?>
'btn btn-success', 'name' => 'accept',])?> 'btn btn-danger', 'name' => 'reject', 'data' => ['confirm' => Yii :: t ('frontend', 'Weet je zeker dat je dit verzoek wilt weigeren?'), 'methode' => 'plaatsen',],])?>

In wezen heb ik zojuist toegevoegd naam waarden van 'aanvaarden' of 'Verwerpen' op elke knop. Vervolgens wordt dit als een geposte waarde afgeleverd, zoals weergegeven:

 if ($ model-> load (Yii :: $ app-> request-> post ())) $ posted = Yii :: $ app-> request-> post (); if (isset ($ posted ['accept'])) // accept $ model-> response = RequestResponse :: RESPONSE_ACCEPT; $ Model-> save (); $ Aanvraag-> accepteren ($ model); Yii :: $ app-> getSession () -> setFlash ('succes', Yii :: t ('frontend', 'Verzoek geaccepteerd. We zullen de details van de vergadering bijwerken en andere deelnemers informeren.'));  else // reject $ model-> response = RequestResponse :: RESPONSE_REJECT; $ Model-> save (); $ Aanvraag-> verwerpen ($ model); Yii :: $ app-> getSession () -> setFlash ('succes', Yii :: t ('frontend', 'Uw weigering is geregistreerd. We zullen andere deelnemers dit laten weten.'));  return $ this-> redirect (['/ meeting / view', 'id' => $ request-> meeting_id]); 

Wanneer de responder het verzoek accepteert of weigert, wordt een flitsbericht weergegeven en een e-mail verzonden. De vergadering heeft ook geen actieve verzoeken meer te laten zien:

Hier is de Gevraagde wijziging geaccepteerd kennisgeving e-mail:

Er gebeurt veel in Request :: accept () hieronder:

public function accept ($ request_response) // to do - dit zal moeten veranderen als er meerdere deelnemers $ this zijn -> status = Request: STATUS_ACCEPTED; $ This-> update (); $ m = Meeting :: findOne ($ this-> meeting_id); // is er een nieuwe schakelklok ($ this-> time_adjustment) case Request :: TIME_ADJUST_ABIT: // maak een nieuwe vergadertijd met alternate_time $ this-> meeting_time_id = MeetingTime :: addFromRequest ($ this-> id); $ This-> update (); // markeer als geselecteerd MeetingTime :: setChoice ($ this-> meeting_id, $ this-> meeting_time_id, $ request_response-> responder_id); breken; case Request :: TIME_ADJUST_OTHER: // markeer als geselecteerd MeetingTime :: setChoice ($ this-> meeting_id, $ this-> meeting_time_id, $ request_response-> responder_id); breken;  // is er een andere plaats als ($ this-> place_adjustment == Request: PLACE_ADJUST_OTHER || $ this-> meeting_place_id! = 0) MeetingPlace :: setChoice ($ this-> meeting_id, $ this-> meeting_place_id, $ request_response-> responder_id);  if ($ m-> isOwner ($ request_response-> responder_id)) // zij zijn een organisator $ this-> completed_by = $ request_response-> responder_id; $ This-> update (); MeetingLog :: toe te voegen ($ this-> MEETING_ID, MeetingLog :: ACTION_REQUEST_ORGANIZER_ACCEPT, $ request_response-> responder_id, $ this-> id);  else // ze zijn een deelnemer MeetingLog :: add ($ this-> meeting_id, MeetingLog :: ACTION_REQUEST_ACCEPT, $ request_response-> responder_id, $ this-> id);  $ user_id = $ request_response-> responder_id; $ subject = Verzoek: buildSubject ($ this-> id, true); $ p1 = MiscHelpers :: getDisplayName ($ user_id) .Yii :: t ('frontend', 'accepteerde het verzoek:'). $ subject; $ p2 = $ request_response-> opmerking; $ p3 = Yii :: t ('frontend', 'U ontvangt een bijgewerkte vergaderingbevestiging die deze wijziging (en) weerspiegelt en bevat ook een bijgewerkte bijlage voor uw agenda.'); $ content = ['subject' => Yii :: t ('frontend', 'Accepted Requested Change to Meeting'), 'heading' => Yii :: t ('frontend', 'Requested Change Accepted'), 'p1 '=> $ p1,' p2 '=> $ p2,' p3 '=> $ p3,' plain_text '=> $ p1. ". $ p2.". $ p3.' ... '.Yii :: t (' frontend ',' Bekijk de vergadering hier: '),]; $ button = ['text' => Yii :: t ('frontend', 'View the Meeting'), 'command' => Meeting :: COMMAND_VIEW, 'obj_id' => 0,]; $ this-> notify ($ user_id, $ this-> meeting_id, $ content, $ button); // Wijzigingen aanbrengen in de vergadering $ m-> increaseSequence (); // opnieuw verzenden van de afronding - die ook moet worden gedaan voor opnieuw verzenden uitnodiging $ m-> finalize ($ m-> owner_id);  

Voordat de e-mail wordt verzonden, wordt het vergaderrooster bijgewerkt om elke nieuwe datum / tijd en / of nieuwe plaats weer te geven. Nadat de e-mail is verzonden, is de vergadering voltooid. Dit levert een nieuwe vergadering-update met het bijgewerkte kalenderbestand op voor alle deelnemers:

Wat is het volgende?

Ik hoop dat je deze tutorial leuk vond. Het bouwen van deze functie duurde langer dan ik had gehoopt, maar bleek redelijk goed. Ik denk dat het een dimensie toevoegt aan het plannen met Meeting Planner, ongeëvenaard door andere services.

Als u dat nog niet hebt gedaan, gaat u uw eerste vergadering plannen met Meeting Planner. Ik ben doorgegaan met het maken van ongelooflijke vooruitgang in de richting van de beta-release, ondanks afleiding (codering is moeilijk):

Ik ben ook van plan om een ​​tutorial over crowdfunding te schrijven, dus overweeg om onze WeFunder Meeting Planner-pagina te volgen. 

Deel alstublieft uw opmerkingen hieronder. Ik sta altijd open voor nieuwe functie-ideeën en suggesties voor onderwerpen voor toekomstige zelfstudies. Je kunt me ook bereiken via @reifman. 

Blijf op de hoogte van dit alles en meer komende tutorials door te kijken naar de Building Your Startup With PHP-serie. En bekijk zeker onze Programming With Yii2-serie (Envato Tuts +).

Gerelateerde Links

  • Meeting Planner
  • Volg het financieringsprofiel van Meeting Planner