search

vaizard / glued-archived

1 stars 3 forks source link

Fb Events / calendar merger #39

Open killua-eu opened 6 years ago

killua-eu commented 6 years ago

Integrate fb events into our calendar solution. https://developers.facebook.com/docs/graph-api/reference/page/events/

[edit] On hold due to Cambridge Analytica scandal. See:

killua-eu commented 6 years ago
  1. Chceme ui na přidávání, editaci, (ne)sledování a mazání stránek, že kterých se to má tahat. Editace má smysl víc s místy (viz následující bod) ale i se stránkami (editace ve smyslu změna nastavení), přerušení a spuštení sledování stránek = zda tahat či netahat data z api, mazání = nastavit na netahat a zároveň (smazat/možná spíš marknout invisible) z databáze stažená data (finální smazání by byl další krok)
  2. Chceme ui na přidávání míst (např zadání mista Uliční 12, Město a okolí 50m - bude nabízet events ze všech stránek co padají do této oblasti. Zadání míst nejlépe s našeptáváním). Současně chceme těm místům a stránkám dávat tagy/kategorie. Jejich smysl vysvětlím následujícím bodu.

Q: co se tyce adres, chces aby to vybiralo okruh, ze stranek ketre sledujeme? nebo ze vsech co existujou, ktere nesledujeme? ANO Q: Ty okruhy adres, to chces taky ukladat jako trvale stahovani? ANO. To zadání adresy je tam nejen na stránky, ale i na events které budou na stránce pražské firmy která udělá na brněnské adrese event. Otázkou je, zda to dokážeme vytáhnout. Q: Můžeš napsat víc k bodu 1 editace? Při editaci bys měl vidět odkdy (dokdy) sleduješ,.. Pokud přerušíš tak být to měl vidět jako víc datových rozsahu. Měl bys mít možnost si zadat rozptyl od do co stáhnout, abys mohla stáhnout i minule eventy

  1. Chceme vypsat stažena event metadata s použitím css a HTML naší bootstrap šablony. Tedy nejen zobrazit pure json, ale pěknou html tabulku, kterou jak uvidíme nějak nahozenou zredukujeme, upravíme a načančáme. Na tomto výpisu budeme chtít filtrovat podle stránek a místa a podle témat. Témata si tam zadá uživatel, takže si tam bude moct doplnit tagy které upřesní, že event je přednáška, koncert, nebo trh Uživatel bude také moct zadat jazyk, ve kterém se event odehrává. Tyto informace zadá pro glued (ne pro sebe, a nebude se to posilat zpět na FB).

Mělo by jít pripadne moct upravit popis eventu, také potrebujeme, aby s kazdou aktualizaci se u dat zobrazovalo co se zmenilo aby si to uživatel-editor mohl projit a rozhodnout co s tím. Některá data bude mozne autoaktualizovat bez editora, ale jeste nevime jak to ted zakomponovat do UI, takze to nechame na pozdeji. Půjde napr. o to, ze pokud nekdo nastavi/zmeni na eventu link na prodej vstupenek, pak by se mel automaticky prenastavit i glued zaznam).

Q: ty zmeny to bude komplikovane. protoze treba od vcerejsi aktualizace se nic nezmenilo, ale od predvcerejsi jo. a kdyz se neco zmeni mezi 4 a 5 a mezi 7 a 8 a ty jsi na 9, tak ktere vsechny zmeny chces videt? A: rozhodne datum je datum kdy eventu uzivatel priradi tag. ten tag urci, ze s tim eventem budeme dale pracovat takze to nam da prvni okamzik.

K situaci popisovane v otazce: rekneme, ze data mame z okamziku 4 ptvrzena editorem jako platna. mezitim se ulozilo 5,6,7,8,9. automaticky nabidneme editorovi 9 u vsech datovych polich. ale bylo by fajn, kdybychom meli treba postahovany 3 ruzny obrazky, ejden z verze dokumentu 4, jeden z 6 a jeden z 9, tak se nabidne sice 9ka, ale bude mozne u toho obrazku napr. klikanim na jedno tlaciko prorotovavat vsechny stazene obrazky ( tak vybrat ten, ktery se ma zobrazovat ). ty zmeny/verze bychom ted meli pripravit na backendu (tedy stahujme ta data). jak s nimi pracovat na frontendu bychom meli vybrat podle toho, jak eventy opravdu zobrazime v html, at prilist netrapime nasi predstavivost. prvni proof-of-concept pro predstavu jak bychom to treba na frontendu mohli udelat je mit u kazdeho eventu:

Se stazenymi daty budeme cilit na 3 cilove pouziti:

a] rezim agregace haldy fb eventu na web b] rezim history tracking eventu nejakych stranek c] rezim parovani s ukoly naplanovanymi v nasem pixel modulu

a] budem tam muset jeste asi jeste doplnit k eventu tlacitko publish s vyberem kam se ma publikovat. publikaci je mysleno to, ze se fb data zkopiruji do nasi datove struktury v pixel json dokumentu. nasledne pak pixel eventy s nastavenou vlakou published a id/kanalem ve kterem se ma publikovat ... pod nejakou api adresou, napr. glued.com/api/pixel/events/list/channel=$channelid&date=upcomming&limit= to pak napriklad vypise nami strukturovany json se vsemi eventy zverejenymi do daneho kanalu. ty json data pak vezme nejaky kousek javascriptu a udela z toho html vystup. takto si bude moct n spolupracujicich organizaci dat spolecny eventkalendar na web b] ditto, jen bude v tom prehledu v parametru date=20170101-20171231 a pridame tam treba prametr &fmt=html a vypise to jednoduchem nestylovanem html data, kter muze uzivatel snadno copy and pastnout do zaverecne zpravy kdyz musi vykazovat aktivitu za rok treba kvuli firemni politice, dotacim, atp. c] prolinkovani eventu s nasimi issues

killua-eu commented 6 years ago
  1. nevidím způsob, jak přidávat tokeny, můžu vybrat jen jeden z jednoho.
  2. zjisti prosím, proč se to zařízne na 25 eventech.
  3. zobraz všechny eventy, tedy udělej přehledovou tabulku, kde bude

event-id, event-name, start-time, location a ideálně i pořadatelé.

V tabulce všech eventů i v tabulce eventů stránky umožni zobrazit více informací. minimálně chceme vidět header fotku, počet lidí, popis akce. prima je videt vše (předpokládám, že ukládáš celý json z fb a neomezuješ ho a z něj jen zobrazuješ části, nebo ukladas ta data, co jsme si odsouhlasili pred par mesici) - tedy např. zobrazit prettyprint celého jsonu. pro toto bych zvolil zobrazovaní typu harmonika, napr. na výsku 5, 6 radkku tak, aby to slo rozkliknout na první dobrou.

Dále budeme chtít zvýraznit změny v termínu konání, popisu, názvu eventu a místu, resime tedy verzovani. Staci mit asi jen aktualni verzi proti verzi přijaté editorem.

Dále budem chtít ukládat edge data o tom, kdo byl na jakém eventu (pokud to api dovolí). Takovým způsobem, aby v případě, že se toto FB rozhodne zabít, glued neprepsal posledni platny guest list prazdnou hodnotou.

Workflow užívání by měl být následující:

  1. jsem root - můžu přidat apikey, přidat stránky, atp. a dělat vše co editor. oproti stávajícímu potřebujem ješte form na definování témat (tabulka: events_topics) a možnost přiřadit fb stránce nějaká témata ... tabulka events_page_topics
  2. jsem editor - vidím seznam eventů agregovaných ze všech stránek. muzu si vyfiltrovat jen eventy patrici strankam s nejakymi topicy (select2), muzu si vyfiltrovat nezpracovane eventy, muzu si vyfiltrovat eventy se zmenou.
  3. Kazdy nezpracovany event bude mit nejaky priznak (toto musis asi doplnit do tabulky eventu, asi bych pouzil id?)
  4. Do nove tabulky events bych rad zkopiroval vsechna pro nas zajimava data, stahl take backup header obrazku.
  5. Editor bude moct jednotliva data typu misto eventu, datum, nazev, popis, atp. opravit, popis a název by měl jít přeložit (výstup půjde česky a anglicky).
  6. Vybere pro event jeden či více topiců.
  7. Obdobně bude fungovat možnost vložit event přes web form u nás pro ty, co nemaj eventy na FB. bude nějaká tabulka, ve které si budou moct editovat cizí uživatelé, a tato tabulka bude pak promítávána s tabulkou dle bodu 4.

Z této tabulky se pak budou data zobrazovat přes api. Api endpoint bude vracet json se všemi eventy s nějakým limitem. Zobrazí se pouze anonymizovaná data (tzn. nesmí tam být vidět např. edge data kdo se účastní čeho).

pohadkar commented 6 years ago

ad 2) pokud neni v dotazu uvedeno limit=cislo bere se limit jako 25. dalsi stranku lze nacist dvema zpusoby: 1. pokud stranku jedna ziskame z response takto: $feedEdge = $response->getGraphEdge(); tak stranku 2 ziskame takto $nextFeed = $fb->next($feedEdge); pokud uz tam zadne dalsi polozky nejsou, vrati to null

jako limit u dalsi stranky se pouzije bud 25, nebo zadany limit u prvni stranky.

2. zjistime si sami z edge hodnotu dalsiho kurzoru $hodnota = $feedEdge->getNextCursor(); pokud to vrati cokoliv mimo null, jsou tam dalsi stranky a muzeme ho pouzit pro konstrukci dotazu pro nacteni dalsi stranky. (nebo muzeme udelat to next(), nebo si to muzeme ulozit pro pozdeji nacteni. ale pak uz nepujde udelat next, jen zkonstruovat novy dotaz)

krome kurzoroveho strankovani existuje jeste time based strankovani a offset based strankovani (zalezi na konstrukci puvodniho dotazu) , ktere ale nejdou pouzit na vsechny edge. tam je mozne se na dalsi stranku dostat jen tim next() z prvniho prikladu.