podpora pre fázy - Githubissues

svtimport commented 13 years ago

Feature #1 imported from https://svt-devel.fmph.uniba.sk/chiliproject/issues/1 Author: Martin Králik Assignee: Tomáš Belan Priority: Normal Target version: Hlasovanie na prifuku

Pridať podporu pre jednotlivé fázy ankety.
Predbežný zoznam fáz je takýto:
- otvorené hlasovanie študentov
- uzamknutá anketa len pre učiteľov, ktorý môžu reagovať na anonymné komentáre
- výsledky dostupné pre študentov
- výsledky dostupné pre verejnosť
Presnejší zoznam by mal byť k dispozícii čoskoro.

Prechody medzi fázami by mali byť automatické, riadené podľa (vopred) zadaných dátumov.

Created by Martin Králik on 2011-10-10 at 23:04:44+02:00

Priority set to Normal
Project set to Anketa
Subject set to podpora pre fázy
Tracker set to Bug
Status set to New
Description set to Pridať podporu pre jednotlivé fázy ankety. Predbežný zoznam fáz je takýto: ...

svtimport commented 13 years ago

Updated by Martin Králik on 2011-10-10 at 23:09:09+02:00

Tracker changed from Bug to Feature

svtimport commented 13 years ago

Updated by Tomáš Belan on 2011-10-18 at 22:52:19+02:00

Este medzi prvou fazou (hlasovanie) a druhou fazou (odpovedanie) ma byt moratorium cez ktore nikto nemoze nic.

svtimport commented 12 years ago

Updated by Tomáš Belan on 2012-03-27 at 01:27:51+02:00

Assignee set to Tomáš Belan

Design:

Nastavenie faz: cez O(1) booleanov v config.yml. Napriklad takyto format:

beziace_fazy:
    hlasovanie:             false
    vysledky_aktivnej_sezony:
        prihlaseni_vidia:   true
        vsetci_vidia_cisla: false
        robenie_responses:  true
        vidno_responses:    true
    vysledky_starych_sezon:
        prihlaseni_vidia:   true
        vsetci_vidia_cisla: true
        robenie_responses:  false
        vidno_responses:    true

(Pocet pripadne mozme zredukovat, ak si povieme ze 9 je vela a chceme nieco z toho mergnut/vyhodit.)

Tieto booleany tvoria nadmnozinu smernice aj jej alternativnych interpretacii (tj veci co tam boli nejasne), a mam pocit ze aj cokolvek co si vymyslia ine fakulty by sa do tychto nastaveni snad mohlo zmestit.

Prepinanie faz: konkretne v pripade FMFI (a nasej smernice) vyzera takto:

zaciatok hlasovania (dva tyzdne pred koncom semestra):
> pripravi sa databaza (vyrobi sa Season, importuje sa vsetko mozne atd - vid tiez Importy na wiki)
> v config.yml sa zapne hlasovanie a vypne vsetko vo vysledky_aktivnej_sezony
> vhodne sa upravia texty vo welcome, FAQ atd - miestami sa tykaju konkretnej sezony (TODO eventualne odtial take referencie vymazat)
koniec hlasovania (dva tyzdne po zaciatku skuskoveho):
> v config.yml sa vypne hlasovanie
> spusti sa anonymizacny skript
otvorenie vysledkov (koniec skuskoveho):
> v config.yml sa vo vysledky_aktivnej_sezony zapne prihlaseni_vidia, robenie_responses a vidno_responses
spristupnenie vysledkov verejnosti (mesiac po zaciatku semestra):
> v config.yml sa vo vysledky_aktivnej_sezony zapne vsetci_vidia_cisla
zatvorenie odpovedania (nevedno kedy vlastne):
> v config.yml sa vo vysledky_aktivnej_sezony vypne robenie_responses

Doteraz bolo vzdy treba vo welcome a section_bar zakomentovavat a vykomentovavat dane prvky - toto bude proste riesene vhodnymi ifmi. Jediny pripad, ked treba welcome alebo FAQ atd upravovat, bude pri starte novej sezony.

Automatizacia: opisane kroky este wrapovat do nejakych skriptov podla mna nema zmysel. Zaciatok hlasovania: pripravu db a upravu textov aj tak treba robit rucne, zmenit config.yml uz je to najmenej. Koniec hlasovania: ok, tam este rozumiem ze by tie dva kroky isli spojit, ale nepride mi to velmi zmysluplne. Ostatne zmeny fazy: idu spravit na jeden krok, tam nie je co skriptovat (teda ledaze by sa spravili skripty co su hardcodovane konkretne na nasu fakultu a smernicu, ale tomu by som sa rad vyhol).

Implementacia: chcem jednak spravit API, ktorym moze welcome template zistit aktualny stav, a druhak nejako symfony presvedcit, aby programaticky pridal dane access_control riadky (tak ako fazy fungovali doteraz). Section_bar nebude zistovat aktualny stav, ale bude simulovat request na vhodnu URL, aby zistil, ci k nej ma konkretny uzivatel pristup. (Tym padom nebudu vsetky access pravidla zduplikovane v section_bare.)

Poprosim design review. Pripomienky? Komentare? Lgtm?

svtimport commented 12 years ago

Updated by Tomáš Belan on 2012-04-01 at 00:16:17+02:00

Zmena: Anty ma presvedcil, aby to bolo v databaze. Takze plati horeuvedene, okrem toho, ze namiesto tych booleanov v configu bude ekvivalentnych 5 boolean stlpcov v tabulke Season.

Zvysok je lgtm?

svtimport commented 12 years ago

Updated by Martin Králik on 2012-04-01 at 11:23:51+02:00

Teda rozumiem tomu spravne, ze faza ma meno, jeden boolean hovori, ci je aktivna, a ostatne nieco o pravach?

A v skratke, aky bol argument preco v DB? Aby sme k tomu vedeli spravit UI pre tych, co to budu menit na inych fakultach?

svtimport commented 12 years ago

Updated by Tomáš Belan on 2012-04-01 at 12:00:35+02:00

Hmm, vlastne v momentalnom designe asi nie su "fazy" spravny nazov...
Fazy nemaju mena. Neexistuje tabulka "Faza" apod., len sa zmeni schema tabulky Season tak, ze okrem "id", "description", "studentCount", "slug" a "active" tam budu boolean stlpce "hlasovanie", "vidno_vysledky", "vidno_verejne_cisla", "robenie_responses", "vidno_responses" (nazvy TBD) vyjadrujuce, co sa s touto Season prave teraz da robit.
Tym padom neexistuje nikde stlpec "nazov fazy".
Zmenit fazu znamena (okrem ineho) nastavit v databaze v aktivnej Season nove hodnoty tych booleanov (t.j. napr. UPDATE Season SET robenie_responses = FALSE WHERE active = TRUE).

Preco v databaze a nie v configu:
\- nemame to len pre "aktivnu sezonu" a "vsetky ostatne sezony", ale pre kazdu sezonu zvlast. tym padom moze teoreticky eventualne bezat viacero seasons naraz, alebo podobne.
\- ked to bude v databaze, potencialne by sa na to dal spravit admin interface.

Preco priamo 5 stlpcov v Season:
Rozmyslalo sa aj nad tym, aby existovala tabulka Faza(id,description,tych 5 booleanov) a Season sa odkazovala na Fazu. To by sa v praxi prejavilo tak, ze v admin interface by clovek nevidel pri kazdom seasone 5 checkboxov, ale selectbox "aktivna faza". Lenze:
\- hlavny dovod za fazy je ze "nemusis si pamatat zo smernice, co ma byt zapnute v ktorej faze" - ale aj tak si musis pamatat zo smernice, kedy sa to ma prepinat na dalsiu. (imho je aj tak oboje lahko zapamatatelne...)
\- potrebovali by sme dva admin interfaces, jeden co meni stlpec Season.faza_id a druhy co meni obsah tabulky Faza.
\- ked je tam priamo 5 checkboxov, daju sa lepsie riesit specialne okolnosti (nieco typu "z politickych dovodov teraz musime rychlo vypnut robenie responses" alebo podobne...)
\- smernica je miestami ambiguous, napr mi stale nie je jasne, ci sa ma zatvorit robenie odpovedi pred alebo po zverejneni ciselnych vysledkov. ak tam budu checkboxy, mozme to riesit rucne podla situacie. keby sme chceli zachovat tuto moznosti s fazami, potrebujeme jednu fazu "odpovede ano, cisla nie" a jednu "odpovede nie, cisla ano".
Takze je imho lepsie, ked system o Fazach nebude vediet, bude len vediet o tom, co je povolene v tomto seasone. (Takze issue by sa asi nemal volat "podpora pre fazy" ale "podpora pre permissions co nebudu vsade hardcodovane ale budu sa brat zo Season"...)

svtimport commented 12 years ago

Updated by Martin Králik on 2012-04-01 at 13:44:10+02:00

Dobre, paci sa mi to.

svtimport commented 12 years ago

Updated by Martin Králik on 2012-04-02 at 13:55:12+02:00

Target version set to Hlasovanie na prifuku

svtimport commented 12 years ago

Updated by Tomáš Belan on 2012-04-14 at 13:29:04+02:00

Status changed from New to Closed

issue #1 closed

yesss

fmfi-svt / anketa

podpora pre fázy #1