Oikeuksien aikavälit #948

Closed dezhidki closed 2 years ago

In GitLab by @Smibu on May 24, 2016, 18:13

Testattavissa koneessa http://timdevs1.it.jyu.fi/

Checklist

[x] Käyttöliittymä (rights editoriin muutoksia)
[x] Palvelimen oikeustarkistus
[x] Kesto
[x] Ajastin dokumenttiin
[x] Duration ryhmälle
[x] Tarkemmat ilmoitukset
[x] Durationin unlockaukselle alku- ja loppuväli
[x] Jos keston määrä 0, niin älä vaihda tyyppivalintaa vuosiksi

In GitLab by @Smibu on Jan 5, 2017, 20:55

GUI-logiikka on jo aika hyvällä mallilla. Editointi tekemättä (lähinnä voisi editoida aikaväliä tai kestoa).

Ei vielä missään testattavissa.

Set durationin alla on 2 kenttää: luku ja yksikkö. Yksiköitä on sekunti, minuutti, tunti, päivä, viikko, kuukausi ja vuosi. Oletus on tunti.

Noiden "Ends/begins" Bootstrap-tooltipeissä on tarkka aikaleima.

In GitLab by @Smibu on Jan 5, 2017, 20:59

@Smibu Voiskos tuossa olla ihan samanalainen kuin luentokysmyksissä se kesto? Tekisi sille komponentin tarvittaessa ja käyttäisi kaikissa kestoissa samaa tapaa. Alkuaikaakin varten on hieman erilaisia komponentteja eri paikosisa TIMiä. – Vesa Lappalainen

In GitLab by @Smibu on Jan 5, 2017, 21:24

@vesal Joo yritän tehdä noista yhdenmukaisia (varmaan juuri komponentti kannattaa tehdä); pitää katsoa missä noita on käytössä.

In GitLab by @Smibu on Jan 5, 2017, 21:41

@Smibu Mieleen tulee ainakin:

luentokysmyksen luonti
luennon luonti
collapsed alueen aikaraja

Sitten varmaan niistä komponenteista kannattaa joku ohjesivu tehdä josta voi katsoa mitä milläkin pitäis tehdä. – Vesa Lappalainen

In GitLab by @Smibu on Jan 10, 2017, 21:23

@vesal Tämä on nyt aika lailla valmis. Enää näkyvä ajastin puuttuu dokusta; nyt mistään ei käyttäjä näe, että paljonko aikaa on jäljellä.

Toinen lievä puute on, että duration toimii vain yksittäiselle käyttäjälle laitettuna. Eli ryhmällekin voi kyllä käyttöliittymässä laittaa sen, mutta se ei toistaiseksi vaikuta mihinkään.

Laitoin timdevs1:lle:

http://timdevs1.it.jyu.fi

Laitoin tuohon korttiin (https://trello.com/c/cnfqZ1nG) ruksin komponenttien dokumentaatiosta ja mun todo-korttiin ruksin niiden tekemisestä. Mulla on jo siellä titles-haarassa jotain komponenttipäivityksiä meneillään, niin teen niitä komponentteja titlesin yhteydessä/sen jälkeen.

In GitLab by @Smibu on Jan 10, 2017, 21:32

Sinänsä se duration ryhmälle on vähän ongelmallinen, koska jos laittaa sekä henk. kohtaisen durationin ja ryhmädurationin, niin kumpi pitäisi aktivoida, kun dokuun mennään (jos käyttäjä kuuluu siihen ryhmään)?

In GitLab by @Smibu on Jan 10, 2017, 21:59

@Smibu Voisikos se kesto olla pisin mihin oikeudet liittyvät ja sitten henkilökohtaista aikaa siinä mitataan eli vaikka on ryhmän jäsen, niin siihen ajan mittaukseen ei vaikuta onko joku muu tehnyt jo.

Mutta sitten kokeilein tuota henkilökohtaista ja saan errorin kun vastaan kysymyskeen ajan loputtua. Aikavälirajoitetussa voisi tulla dokusta ilmoitus että doku on luettavissa tällä välillä. Nyt tulee vaan ettei ole oikeutta dokuun.

Ajanpituudella rajoitetun ilmoitusviestikin on aika lyhyt: Your access to this item has expired. Voisi ehkä olla jotakin tyyliin että Oli käytössä 50 sek ja se on nyt käytetty tms. – Vesa Lappalainen

In GitLab by @Smibu on Jan 10, 2017, 22:06

@Smibu Ei nyt tähän hätään, mutta tää pikkuisen modifioituuna voisi olla hyvä mun demoissakin. Eli loppuaika olisi aina ma 13:00, mutta sitten se koskisisikin vain pelkkää vastaamista. Sen jälkeen tulisi niiitä imvalid vastauksia. Ja antaisin tuon aikavälin siis ryhmälle. Dokua pitäisi luonnollisesti päästä katsomaan. Mutta siten voisisin sairastapauksissa antaa lisää vastausaikaa joillekin.

Eli mitä se tahtoisi sanoa käyttöliittymän/oikeuksien osalta. Kilpailuun tuo kokonaan piilottaminen sopii hyvin ja tentteihin. Mutta tosiaan demoissa yms se saisi rajoittaa vaan vastausaikaa, sen jälkeenkin pitäisi saada tehdä niitä invalid-ajoja. – Vesa Lappalainen

In GitLab by @Smibu on Jan 10, 2017, 22:14

@Smibu Joo, tuo ajastin ehkä olisi syytä olla. Miten se sitten näkyy TIMissä, niin se onkin vähän toinen juttu. Jos menee toiseen dokuun, niin tuon aloitetun aikhan varmaan juoksee? Mutta pitäisikö se toisessakin dokussa ollessa nähdä että se yksi on kohta loppumassa. Pitäisikö uhrata jopa hampurilaismenun alta pieni osa "globaalille" kellolle joka näyttää ekana loppuvan dokun aikaa.

Tuleeko hirvee homma käydä haalimassa kaikki kesken olevat oikeudet ja etsiä niistä nopeimmin päättyvä. Ja kiinnostaako m ue edes filosofian doku johon mulla olisi lukuoikeus jonka aika päättyy 3 tunnin päästä.

Eli mitä se aikalaskuri oikeasti näyttäisi ja millä perusteella. Niinkä yksinkertaisesti että jos menen aikarajoitettuun dokuun, niin kello hyppää esiin. Ja pysyy siinä johonkin asti jollakin kriteerillä. Jos samalla menen toiseen dokuun joka on myös aikarajoitettu, mutta loppuu nopeammin,niin siirtyisikö kello sitä dokua näyttämään? Entä kun sen aika loppuu, niin vaihtuisiko automaattisesti takaisin siihen edelliseen? Kuinka kauan ja missä nämä muistetaan?

Tätä Tukes-kisa vartenhan homma on helppoa, koska oletetaan että ne eivät edes pääse muihin dokuihin.

Tuli muuten aikalskurista mieleen että samaa ideaa muokaten voisi tehdä globaalin kellokortin, johon voisi aina sanoa mitä projektia tekee ja se tekisi sitten suoraan Soleen kopsittavan raportin oikeille projektinumeroilla. Mutta voisivat myös opiskelijat seurata demojen tekoon kulunutta aikaa. – Vesa Lappalainen

In GitLab by @Smibu on Jan 10, 2017, 22:25

@Smibu Tuleehan tuossa hieman muitakin ristiriitaisuuksia. Jos on aikavälioikeus toisen ryhmän kautta ja duration toisen kautta, niin minkä mukaan mitataan?

Sitten pitäisikö vaihtoehtona olla vielä että alkuajankohdan voi asettaa ja sitten sen jälkeen voi avata duration moodiin. Itse asiassa tämä olisi oleellisin kilpailua varten kun sillä on joku alkuajankohta milloin eka saa osallistua. Toki tähän hätään tuo voidaan hoitaa manuaalisesti kun joku lisää käyttäjät vasta alkuhetkellä. Sama olisi ehkä ollut Ohj1 tentissä, eli eka saa aloitta klo 8 ja sen jälkeen kullakin on se 2 tuntia aikaa. Ellei valvoja pidennä henkilökohtaisesti jollekin jostakin teknisestä syystä. – Vesa Lappalainen

In GitLab by @Smibu on Jan 10, 2017, 22:28

@Smibu Tuossa kun annoin vastaajalle uuden durationin, niin ilmoitus olis että "Item was unlocked successfully" mutat ei ollut ihan selkeää että alkaako se uusi annettu aika taas avausklikkauksesta vaiko mistä. Olisiko se selkeyden vuoksi ihan sama viesti tuossa kun ekalla kertaa että tietää että nyt alkoi. – Vesa Lappalainen

In GitLab by @Smibu on Jan 10, 2017, 22:32

@Smibu Saisiko jopa nuo alku/loppuviestit kirjoittaa itse dokumenttiin? Koululaisille suunnatussa kilpailussa nuo voisivat olla suomea ja ehkä erityisesti lopetuksessa joku kiittely kisaan osallistumisesta. – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2017, 13:00

Voisikos se kesto olla pisin mihin oikeudet liittyvät ja sitten henkilökohtaista aikaa siinä mitataan eli vaikka on ryhmän jäsen, niin siihen ajan mittaukseen ei vaikuta onko joku muu tehnyt jo.

Tuo saattaisi onnistua kyllä.

Mutta sitten kokeilein tuota henkilökohtaista ja saan errorin kun vastaan kysymyskeen ajan loputtua. Aikavälirajoitetussa voisi tulla dokusta ilmoitus että doku on luettavissa tällä välillä. Nyt tulee vaan ettei ole oikeutta dokuun.

Ajanpituudella rajoitetun ilmoitusviestikin on aika lyhyt: Your access to this item has expired. Voisi ehkä olla jotakin tyyliin että Oli käytössä 50 sek ja se on nyt käytetty tms.

Joo, pitää tarkentaa noita ilmoituksia.

Eli mitä se tahtoisi sanoa käyttöliittymän/oikeuksien osalta. Kilpailuun tuo kokonaan piilottaminen sopii hyvin ja tentteihin. Mutta tosiaan demoissa yms se saisi rajoittaa vaan vastausaikaa, sen jälkeenkin pitäisi saada tehdä niitä invalid-ajoja.

Joo, noista oikeuksista pitää vaan tehdä vähän hienojakoisempia. View pitäisi pilkkoa ainakin kahtia; eli että voi lukea dokua ja että voi vastailla tehtäviin "validisti". Erikseen voisi olla myös kommenttioikeus, koska ei esim. tenttidokussa ole järkeä voida kommentoida tentin kuluessa...

Tuleeko hirvee homma käydä haalimassa kaikki kesken olevat oikeudet ja etsiä niistä nopeimmin päättyvä. Ja kiinnostaako m ue edes filosofian doku johon mulla olisi lukuoikeus jonka aika päättyy 3 tunnin päästä.

Ei se varmaan iso homma olisi.

Eli mitä se aikalaskuri oikeasti näyttäisi ja millä perusteella. Niinkä yksinkertaisesti että jos menen aikarajoitettuun dokuun, niin kello hyppää esiin. Ja pysyy siinä johonkin asti jollakin kriteerillä. Jos samalla menen toiseen dokuun joka on myös aikarajoitettu, mutta loppuu nopeammin,niin siirtyisikö kello sitä dokua näyttämään? Entä kun sen aika loppuu, niin vaihtuisiko automaattisesti takaisin siihen edelliseen? Kuinka kauan ja missä nämä muistetaan?

Varmaan on käyttäjälle helpointa ymmärtää, jos kellossa näkyy aina nykyisen dokun aika. Ja jos ei olla missään dokussa, niin näkyisi se nopeimmin päättyvä ja linkki siihen. Ja jotenkin tooltippiin, että mitä se aika tarkoittaa. Mutta kunhan nyt aluksi tekee nykyiseen dokuun tuon.

Se laskuri pitäisi kai pystyä piilottamaan, koska tuollainen alaspäin juokseva aika voi olla vähän häiritsevä.

Tuleehan tuossa hieman muitakin ristiriitaisuuksia. Jos on aikavälioikeus toisen ryhmän kautta ja duration toisen kautta, niin minkä mukaan mitataan?

Voimassa oleva aikavälioikeus menee aina keston edelle, koska alkamaton kesto ei ole vielä varsinainen oikeus. Vasta sitten kun klikataan unlock, niin kesto-oikeuteen asetetaan aikaväli ja se tulee voimaan.

Sitten pitäisikö vaihtoehtona olla vielä että alkuajankohdan voi asettaa ja sitten sen jälkeen voi avata duration moodiin. Itse asiassa tämä olisi oleellisin kilpailua varten kun sillä on joku alkuajankohta milloin eka saa osallistua. Toki tähän hätään tuo voidaan hoitaa manuaalisesti kun joku lisää käyttäjät vasta alkuhetkellä. Sama olisi ehkä ollut Ohj1 tentissä, eli eka saa aloitta klo 8 ja sen jälkeen kullakin on se 2 tuntia aikaa. Ellei valvoja pidennä henkilökohtaisesti jollekin jostakin teknisestä syystä.

Tuo voisi onnistua jopa ilman kantamuutoksia. Koska alkamattomalla kestolla on alku ja loppu null, ja unlockatulla asetetaan molemmat, niin tuossa vapaana vaihtoehtona on vielä, että vain alku + kesto on asetettu. Ja sen voisi tulkita niin, että unlockata saa vasta, kun nykyhetki >= alku.

Sinänsä voisi olla hyvä, jos voisi määrittää myös loppuajan samalla tavalla, eli tietyn ajankohdan jälkeen ei voisi enää unlockata. Sitten melkein tarviisi vielä yhden sarakkeen.

Tuossa kun annoin vastaajalle uuden durationin, niin ilmoitus olis että "Item was unlocked successfully" mutat ei ollut ihan selkeää että alkaako se uusi annettu aika taas avausklikkauksesta vaiko mistä. Olisiko se selkeyden vuoksi ihan sama viesti tuossa kun ekalla kertaa että tietää että nyt alkoi.

Joo, sitä voisi selventää.

Saisiko jopa nuo alku/loppuviestit kirjoittaa itse dokumenttiin? Koululaisille suunnatussa kilpailussa nuo voisivat olla suomea ja ehkä erityisesti lopetuksessa joku kiittely kisaan osallistumisesta.

Laitoin tuostakin ruksin.

In GitLab by @Smibu on Jan 11, 2017, 15:29

@Smibu Jäikös multa kirjoittamatta että jos vastaa kysmykseen ajan loppumisne jälkeen tulee virhe. Siitä voisi tulla nätti ilmoitus – Vesa Lappalainen

In GitLab by @Smibu on Jan 11, 2017, 16:36

@vesal Joo olit senkin maininnut.

In GitLab by @Smibu on Jan 12, 2017, 18:35

@vesal Ajastin on nyt tehty. Näkyy oikeassa yläkulmassa.

Kun ajastin menee nollaan, niin tulee automaattinen F5.

In GitLab by @Smibu on Jan 12, 2017, 18:57

@Smibu

Tuo voisi onnistua jopa ilman kantamuutoksia. Koska alkamattomalla kestolla on alku ja loppu null, ja unlockatulla asetetaan molemmat, niin tuossa vapaana vaihtoehtona on vielä, että vain alku + kesto on asetettu. Ja sen voisi tulkita niin, että unlockata saa vasta, kun nykyhetki >= alku.

Sinänsä voisi olla hyvä, jos voisi määrittää myös loppuajan samalla tavalla, eli tietyn ajankohdan jälkeen ei voisi enää unlockata. Sitten melkein tarviisi vielä yhden sarakkeen.

VL: Mutta kun toisaaltya ajattelee, niin tosiaan voisi olla niin että aikaväli ja duration olisivat erillään ja duration voi soveltaa allways ja aikavälitilanteessa. Aikavälissä voi jätää jomman kumman pään pois. Tässäkin Tukesin kilpailussa on alkuaika ja loppuaika jonka välissä jokainen saa sen tuntinsa käyttää.

Varmaan on käyttäjälle helpointa ymmärtää, jos kellossa näkyy aina nykyisen dokun aika. Ja jos ei olla missään dokussa, niin näkyisi se nopeimmin päättyvä ja linkki siihen. Ja jotenkin tooltippiin, että mitä se aika tarkoittaa. Mutta kunhan nyt aluksi tekee nykyiseen dokuun tuon.

VL: mutta jos nykyisen dokun aika on pitempi kuin nopeammin päättyvän? Pitäisikö se jotenkin kertoa? – Vesa Lappalainen

In GitLab by @Smibu on Jan 12, 2017, 19:12

@Smibu Jos ajattelen ensi viikon Ohj1 uusintatenttiä.

Voisin tehdä niin, että lisään kaikki ilmoittautuneet tuonne 0 h ajalla ja alku 12:00, loppu 17:00. Sitten sitä mukaa kun saavat koneita auki, niin vaihtaisi oh tilalle 4h. Sen evrran tuo meni kokeilussa pieleen, että se tarjoaa oletuksena silloin 0 y (kun tietysti yksikköä ei ole mihinkään tallennettu). Voisikohan se muistaa sen edes localstoragessa jota se käyttäyisi jos aika on 0? Eli idea olisi että voisi nopeasti antaa ajan noille.

Sitten sellaien ilmiö ehkä että jos jollekin pitää antaa lisäaikaa, niin sitä ei voi antaa niin, että lupaan että ok, nyt sulla lähit kone käyntiin nyt sulla on 4 h aikaa. Nimittäin jos kaveri ei heti refresshaa, vaan tekee 3 tuntia ja sitten refreshaa, niin alkaa uusi 4 h jakso. En tiedä miten tuon tekisi siististi niin ettei tarviisi koko ajan pollata serveriä. – Vesa Lappalainen

In GitLab by @Smibu on Jan 13, 2017, 13:34

Mutta kun toisaaltya ajattelee, niin tosiaan voisi olla niin että aikaväli ja duration olisivat erillään ja duration voi soveltaa allways ja aikavälitilanteessa. Aikavälissä voi jätää jomman kumman pään pois. Tässäkin Tukesin kilpailussa on alkuaika ja loppuaika jonka välissä jokainen saa sen tuntinsa käyttää.

Joo, lisäsin tuosta ruksin.

mutta jos nykyisen dokun aika on pitempi kuin nopeammin päättyvän? Pitäisikö se jotenkin kertoa?

Olisi se jotenkin hyvä ilmaista. Montaa ajastinta ei kannata näyttää ainakaan oletuksena kerralla.

Voisikohan se muistaa sen edes localstoragessa jota se käyttäyisi jos aika on 0? Eli idea olisi että voisi nopeasti antaa ajan noille.

Joo eiköhän sen localstorageen saa.

Sitten sellaien ilmiö ehkä että jos jollekin pitää antaa lisäaikaa, niin sitä ei voi antaa niin, että lupaan että ok, nyt sulla lähit kone käyntiin nyt sulla on 4 h aikaa. Nimittäin jos kaveri ei heti refresshaa, vaan tekee 3 tuntia ja sitten refreshaa, niin alkaa uusi 4 h jakso.

Aina kun duration asetetaan managessa, niin käyttäjän pitää unlockata uudestaan. Eli sinänsä tuo refresh on pakko tehdä, jotta tehtäviin pystyy vastaamaan. Jos ainoastaan lukee tehtäviä ja suunnittelee vastauksia paperille, niin se on tietysti eri juttu :)

Mutta jos lisäaikaa annettaisiinkin myöhentämällä oikeuden päättymishetkeä, niin sittenhän tuossa ei tulisi muuta ongelmaa kuin se, että kun ajastin menee nollaan, niin tulee turha refresh, koska tuo jatkamistieto ei mene selaimeen muuten.

In GitLab by @Smibu on Jan 16, 2017, 18:56

@vesal Nyt voi asettaa myös kestolle erikseen aikavälin.

In GitLab by @Smibu on Jan 16, 2017, 20:55

@Smibu Joko uskaltaa laittaa tuotantoon kokeeksi? – Vesa Lappalainen

In GitLab by @Smibu on Jan 16, 2017, 21:22

@vesal Teen vielä tuon ryhmäkeston, niin sitten voisi. Ennen noita kahta viimeistä teen ensin sen url-jutun loppuun.

In GitLab by @Smibu on Jan 16, 2017, 22:44

@Smibu Ehtiikö kokeilla pe tentissä? – Vesa Lappalainen

In GitLab by @Smibu on Jan 17, 2017, 10:37

@vesal Joo helposti luulisi kerkeävän.

In GitLab by @Smibu on Jan 18, 2017, 21:40

@Smibu Kattoppas kun tuotannossa tuntimäärän reikä on niin pieni, ettei sinne saa aikaa kirjoitettua. Sitten yritin sulle antaa 4 tunnit tenttioikat, niin se kesto onkin 2 päivää.

Oikeuksia on helppo lisätä, mutta tentin päättymisen jälkeen olisi kiva saada niitä massana helpommin pois. – Vesa Lappalainen

In GitLab by @Smibu on Jan 18, 2017, 22:07

Kattoppas kun tuotannossa tuntimäärän reikä on niin pieni, ettei sinne saa aikaa kirjoitettua.

Ainiin, unohtui /resetcss. Nyt näkyy järkevästi.

Sitten yritin sulle antaa 4 tunnit tenttioikat, niin se kesto onkin 2 päivää.

Tuota en ite tunnu saavan toistettua. Tuleeko tuo bugi aina/usein?

Oikeuksia on helppo lisätä, mutta tentin päättymisen jälkeen olisi kiva saada niitä massana helpommin pois.

Joo, sinne voisi laittaa varmaan kunkin oikeustyypin yhteyteen Clear-napin. @vesal

In GitLab by @Smibu on Jan 18, 2017, 23:41

@Smibu Oisko johtunut sitten siitä kun en nähnyt mitä lukee siinä aikaikkunassa ja kun kirjoitin siihen 0, niin se meni siinä olleen 4:n kaveriksi ja tuli 40 h. Nyt vaikuttaisi että tuli 0 h. Ajatus on että annan kaikille 0 h ja sitten kun tulee kokeeseen, klikataan 4 h. – Vesa Lappalainen

In GitLab by @Smibu on Jan 19, 2017, 08:24

@Smibu

Joo, sinne voisi laittaa varmaan kunkin oikeustyypin yhteyteen Clear-napin.

Olisikohon joten tolkullista sellainen, että kun poista yhden oikeuden, niin siinä voisi valita että samalla poistetaan muutkin vastaavat oikeudet. Tosin tuossa on esim. tentti tilanteessa se vaara että lähtee niiltäkin, jotka ovat vielä tentissä. Sama tietysti siinä clear.

Eli nyt esim pe tentissä nykyinen idea on että poislähtevältä opiskelijalta poistetaan oikeus. Jos tuossa yhdellä painikkeella samalla menisi vahingossa muiltakin, tulisi aika urakka.

Sitten tentin ja sen Tukes-kisan kannalta tuli mieleen sellainen asia, että silloin kun on duration, niin pitäisikö vielä voida jotenkin (ei ehdi tietysti tähän) sanoa että kun duration alkaa, niin sitä voi tehdä vain siltä yhdeltä istunnolta. Eli koneen vaihtaminen lopettaisi oikeuden. Tuossa tietysti sotkee varmaa Chromen yms siirtyvät cookiet ja IP-pohjaisessakin tarkastelussa olisi varmaan ongelmia. – Vesa Lappalainen

In GitLab by @Smibu on Jan 19, 2017, 11:20

@vesal Ehkä poistamisen sijaan voisi olla expire-nappi, joka ei poista kannasta riviä, vaan vain asettaa oikeuden loppumisajankohdan nykyhetkeen. Silloin managesta näkisi helposti, että kuka on poistunut milloinkin.

Ja yleensähän ihmisiä poistuu tentistä hiljalleen yksitellen, paitsi lopuksi, joten olisiko bulkki-expire-nappi edes järin hyödyllinen?

Eli sun ei tarvi kaikkia tenttijöitä lisätä alussa yksitellen, vaan nyt kun tuo ryhmäkesto toimii, niin voi olla vaan ryhmä ohj1tenttijat, jolle annetaan se nollakesto ja sitten kun käyttäjä unlockaa, niin sille luodaan oma oikeusrivi, jolle voi asettaa oikean keston. Ja tentin lopuksi riittää expirettää se ryhmäkesto, kun yksittäiset ovat expired.

Sellainen pieni reikä tuossa on, että vaikka kestoksi asettaa 0, niin doku ehtii välähtää näkyvänä hetken ennen kuin tulee ilmoitus, että aika loppui. Tuon voisin korjata vielä tänään.

Tuo istunnon rajoittaminen yhdelle koneelle voi tosiaan olla vähän hankalaa. Siitä voisi laittaa oman kortin.

In GitLab by @Smibu on Jan 19, 2017, 11:42

@Smibu Ongelma on siis se, että jos kaveri lähtee pois tentistä tai Tukes-kisasta ennenkuin aika expiroituu. Ja siten saa periaattessa oikeuden jatkaa tenttiä/kisaa luokan ulkopuolella ja lähetellä siitä muille vaikka mitä tietoa. Meidän tentissähän tämä ei ole niin iso ongelma tiedonvälitysken osalta muille kun uusia ei saa tulla enää kun poistumisaika alkaa.

Mutta molemmissa tuo on ongelma sen suhteen, että jos poistuu ilman että poistetaan oikeus, niin saa katsella vastauksia kavereiden kanssa.

Mutta sitten tentin päätyttyä lista halutaan ehkä siistiksi niin, että näkee että kenelläkään ei enää ole oikeuksia ja siksi tuollainen kaikkien poisto.

Tuo tenttiryhmä auttaisi vähän, mutta kun kaikilla ei ole vielä sitä oikeutta tehdä ryhmiä. Siinä on tuo Korppi-LDAP tulossa, joka hieman helpottaa tuota ja voisi antaa LDAP-ryhmän teko-oikeuden isomalla joukkolle niin, että niitä ryhmäläisiä ei näe muuta kuin Korpista. – Vesa Lappalainen

In GitLab by @Smibu on Jan 19, 2017, 18:09

@vesal Laitoin sinne ruksin (oletuksena päällä), jolla voi näyttää vain aktiiviset ja tulevat oikeudet.

Samaten nyt voi "kuolettaa" oikeuden kahdella klikillä (edit, expire).

In GitLab by @Smibu on Jan 19, 2017, 20:58

@Smibu Oliko tuo missä käytössä? – Vesa Lappalainen

In GitLab by @Smibu on Jan 19, 2017, 21:52

@vesal Ihan tuotannossa on.

In GitLab by @Smibu on Jan 19, 2017, 22:38

pitäisikö nolla näyttää nollana? – Vesa Lappalainen

In GitLab by @Smibu on Jan 20, 2017, 07:14

kännykällä 0:n muuttaminen muuksi hankalaa koska edit aukeaa eri paikkaan. oisko muutenkin järkee että edit aukeaisi kohdalle? – Vesa Lappalainen

In GitLab by @Smibu on Jan 20, 2017, 12:31

pitäisikö nolla näyttää nollana?

Joo pitäisi; se kirjasto, joka tuossa on käytössä, ei jostain syystä huomioi nollaa...

Ja tosiaan edit voisi aueta kohdalle tai dialogiin.

In GitLab by @Smibu on Jan 22, 2017, 16:16

@Smibu Tuo:

Show only active or upcoming rights

voisi näkyä ehkä vain silloin, kun sillä on merkitystä, eli on olemassa piiloon menneitä. – Vesa Lappalainen

In GitLab by @Smibu on Jan 23, 2017, 14:12

Joo, laitoin tuonne ruksin: https://trello.com/c/yYcQx3Sm

In GitLab by @Smibu on Nov 14, 2017, 01:09

closed

TIM-JYU / TIM

Oikeuksien aikavälit #948

Checklist