TIMiin ajanvaraus niin, että näyttää muiden tekemien ruksien määrät ja on ylärajat #1791

Closed dezhidki closed 2 years ago

In GitLab by @vesal on Apr 25, 2020, 10:42

Vaikka ajat jaettaisiin niin, että ruksivat mahdolliset ajat ja niistä lasketaan parhaiten sopiva jako, voisi silti näyttää kunkin ruksin kohdalla moniko on saman ajan ruksinut. Ja ohjeessa kehotettaisiin laittamaan rukseja myös niihin kohtiin, joissa on vähän rukseja, jotta ajat saadaan riittämään paremmin.

Eli kyllä tuota silti voisi lähteä miettimään sellaisen komponentin kautta, johon ruksitaan aikoja ja liian montaa ei saa ruksia. Tässä tapauksessa vaan rajoiksi laitettaisiin riittävän isot.

Yleistä ajanvarausta varten:

[x] ruutua ei näytetä jos määrä ylittynyt (jos määrä >0 näytetään määrä tai vapaat kuitenkin, attribuutti)
[ ] jos tallennushetkellä jokin ruutu on jo ylittänyt määrän, ei siihen ruutuun tallenneta

Ohj-kursseja varten lisäksi:

[x] sähköpostia mikäli ruksi lähtee/tulee ruutuun tietyn ajanhetken jälkeen (attribuuttina sp)
[x] attribuutilla voi rajoittaa milloin saa "vastata" (taitaa jo ollakin), mutta voisi olla "selväkielisempi", vrt Korpin ajanvaraus

Kalenteriasioita EI tehdä vk20 projektissa ja se voi vaatia että koko komponentti uusiksi:

[x] automaattinen muodostaminen päivät vaakaan tai pystyyn kun annetaan varausajan pituus (vrt Korppi)
[x] integrointi kalenteriin niin että omat ruksit näkyvät kalenterissa
[x] integrointi kalenteriin niin, että jos kalenterista poistaa tapahtuma, ruksi lähtee pois
[ ] integrointi kalenteriin niin, että rukseja tehdessä näkyy omat menot

Kalenterikomponentin suunnittelua

Käyttötapaus: Luennot + pääteohjaukset

timezone: Europe/Helsinki  # oletus
weeks: [35-38, 40]
weekdays:  # oletus
 - mon
 - tue
 - wed
 - thu
 - fri
weekevents:
 luento:
  - [Luento 1, 'mon 10:15-12:00']
  - [Luento 2, 'tue 12:15-14:00', {weeks: [36, 41]}]  # oletusviikoista poikkeavat
 paate:
  - [Pääte 1, 'wed 10:15-12:00', {max: 15}]
  - [Pääte 2, 'thu 12:15-14:00']
events:  # tähän voi lisätä epäsäännöllisiä tapahtumia
 - [Muu tapahtuma, '6.11.2020 14:00-15:00']
eventgroups:
 luento:
  suggestAllInEventGroup: true  # jos yhdenkin luennon ruksii, niin ehdotetaanko, että ruksitaan kaikki
 paate:
  suggestForEachWeek: true  # ehdotetaanko jokaisen viikon osalta saman tapahtuman ruksimista
  max: 20  # oletusmaksimiosallistujamäärä jokaiseen tämän ryhmän tapahtumaan
  maxPerPerson: 1  # yksi henkilö voi osallistua korkeintaan näin moneen tämän ryhmän tapahtumaan per viikko

Käyttötapaus: Harjoitustöiden ohjausaikojen asettaminen ja varaaminen

weeks: [35-38, 40]
weekevents:
 ohjaus:
  - [Ohjaus, 'mon 8:00-18:00', {splitToMulti: 20mins}]
  - [Ohjaus, 'tue 8:00-18:00', {splitToMulti: 20mins}]
filterEvents:
 right: view
 deadline: 6h  # ajat varattava viimeistään 6h etukäteen
 allowIfHasParticipant: ohj1  # näytetään view-oikeudellisille vain ne ajat, joissa on ainakin 1 ohj1-ryhmään kuuluva
eventgroups:
 ohjaus:
  max: 2  # ohjaaja + opiskelija

Ratkaisemattomat ongelmat:

Jos harjoitustyö halutaan tehdään ryhmässä, miten se ilmaistaan? Tuntuisi, että answer-taulu taipuu tähän huonosti.

In GitLab by @vesal on Aug 14, 2020, 11:48

Laitan tähän mailin, joka mulla oli liittyen siihen, että tätä voisi tehdä myös cbFildillä joka mahdollistaa vapaamman visuaalisen suunnittelun, mutta ilman sopivaa editoria tuottaa ehkä enemmän hommaa käyttäjälle. Jos tätä rupee toteuttamaan, pitää miettiä mikä on paras tapa tehdä tämä kokonaisuus vai tarvitaanko molempia tapoja? Joskus voi yhden tai kahden tapahtuman ilmoittautumisessa olla hyödyllistäkin että ruksit voi upottaa normaalin tekstin sekaan.

Mites muuten saisikohan tuon:

https://tim.jyu.fi/view/tim/koe/taulukko/viikot/demo-1

tehtyä siten, että olisi tuon cbfiled kaveriksi (vaikka peritty) filed-tyyppi, jossa olisi mm attribuutti

 max: 5

joka tarkoittaisi että siinä saa olla aktiivisena vain max 5 ruksia. Ja se näyttäisi ruksin vieressä pienellä montako ruksia on (siis eri vastaajat tehneet) ja olisi disabled jos määrä olisi sama kuin max. Jos kaksi tekee yhtäaikaa "viimeisen" ruksin, niin silloin ensin perille ehtinyt saa sen ja toinen hylätään.

Tulevaisuudessa tuolle sitten pitäisi vielä saad group, eli ne jotka kuuluvat samaan grouppiin, muodostavat joukon, josta saisi ruksia itselleen vaan

 maxSelect: 3

kappaletta rukseja. Kun maxSelect tulee täyteen, niin muut menevät disbaled ja jos jää vajaaksi, niin enabled.

Isoin haaste saattaa olla saada se ruksien lasku riittävän nopeaksi jossa näytetään montako tuota on valittuna?

En tiedä pitäisikö se tehdä ihan niin, että answeriin tallennetaan sen hetkisten rukisen määrä ja jos joku muuttaa omaansa, niin siihen tallennu edellisestä vastaavasta answerista määrä +/- 1.

Tai niin, että ruksi tallentuu kuten muutenkin, mutta sitten vastaavaan GLO_ tallentuu ruksien tämän hetkinen määrä. Tuossa haasteena voisi olla noiden muutosten saaminen atomaariseksi?

In GitLab by @vesal on Aug 14, 2020, 11:57

Sitten tuli vielä toive että jos ruksien määrä on täynnä, niin voisi jäädä jonoon. Yksinkertainen jono on tietysti ilmoittautumisjärjestys, joka varmaan riittäisi ihan alkuun. Korpissa jonotukset olivat tosi monipuolisia ja sitten oli lisäksi vielä mahdollisuus tehdä funktio, joka laskee jonotusarvon.

Monessa käyttötapauksessa jonotus sitten aiheuttaa sen, että omaa ryhmään pääsyään ei voi tietää ennenkuin joku määräaika on mennyt umpeen. Ainoastaan järjestykseen perustuva jonotus antaisi mahdollisuuden tietää varma pääsy ilman määräaikaa.

Sitten jonotus aiheuttaisi myös tarpeen viestinnälle, eli jos pääsee jonossa eteenpäin, pitäisi käyttäjälle laittaa viesti johon hänen pitäisi reagoida ettei käy niin, että hän ei enää muista/halua koko aikaa ja siten jonossa seuraava ei pääse kiipeämään.

In GitLab by @vesal on Aug 14, 2020, 11:57

Jos toimintoa käytetään esim vastaanottoaikojen varaamiseen, niin silloinkin tarvittaisiin viestintää siitä, että joko koko aika on peruttu (viesti varaajalle) tai varaaja on perunut ajan.

In GitLab by @vesal on Aug 14, 2020, 11:59

Korpissa varattuihin aikoihin pystyi kiinnittämään myös viestin (esim linkki harjoitustyöhön tai TeamViewer osoite tai yleensäkin tieto hoidetaanko homma etänä vai läsnä).

In GitLab by @Smibu on Aug 21, 2020, 14:34

Rupean tätä miettimään. Koitan ekaksi kirjoittaa yhteenvedon mahdollisista toteutustavoista.

In GitLab by @Smibu on Aug 24, 2020, 14:43

Toteutustapoja

Alla olevista olen pisimmälle miettinyt calendar-pluginin, koska se tuntuu järkevimmältä.

fieldeillä

ruksit ovat checkbox-fieldejä (tai jokin siitä peritty), joihin tallentuu vastaus normaalisti
pluginin attribuutissa pitää jotenkin voida sanoa, montako ruksia voi max olla päällä

Ongelmia:

kalenteri pitää rakentaa itse markdownilla (templatet auttaa, mutta sitä joutunee usein muokkaamaan)
saako fieldien nimet automaattisesti?
suorituskyky huolestuttaa
jos halutaan näyttää useampi viikko, miten se ilmaistaan käyttöliittymässä sujuvasti?

qst

korttiin kirjoitettu ehdotus

Ongelmia:

"kuin 2 pluginia yhdessä" - tarvitaan iffittelyä, vaikeampi ylläpitää
ei taivu monimutkaisempiin käyttötapauksiin

calendar-plugin

uusi plugin "calendar", joka käyttää valmista Angular-komponenttia (MIT)
kalenterikomponentin kaikki osat ovat kustomoitavissa
Hahmottelu
ohjausajat = lista kalenterieventtejä, jotka annetaan komponentille
- saatavilla olevat ajat määritelty pluginin attribuutissa
- ilmoittautuneiden määrät lasketaan vastauksista palvelimella ja cachetaan, kunnes jokin ilmoittautuminen muuttuu
kussakin eventissä voi olla mitä tahansa omaa metatietoa, esim:
- ilmoittautuneiden lkm
- max ilmoittautujia
- onko nykyinen käyttäjä ilmoittautunut eventtiin vai ei
- milloin viimeistään ilmoittauduttava
- ohjaajien lkm (ja nimet)
- ilmoittautuneiden nimet, jos on teacher-oikeus
yhden käyttäjän valinnat = 1 vastaus
ohjaajat ilmoittautuvat samalla tavalla kuin muutkin, mutta pluginin attribuutilla heidät erotetaan muista (esim. partitionBy: [ohj1ohjaajat])
ht-ohjauksille voi olla vaatimus (pluginin attribuutti), että tavalliset opiskelijat voivat ilmoittautua eventtiin vasta kun ainakin 1 ohjaaja on
- tällöin "tapahtumaan ilmoittautuminen" ja "ohjausaikojen asettaminen saataville" hoituu samalla tavalla
Mikan suosikki näistä kolmesta

In GitLab by @vesal on Aug 24, 2020, 15:31

QST

Joo, qst sellaisenaan on näistä selkeästi huonoin. Sen ainoa hyöty olisi ollut valmis käyttöliittymä alkuhätään. Ja se olisi pitänyt jotenkin periä qst:stä tai kantaluokasta että ylläpito olisi ollut mahdollinen.

Fields

Fieldsejä voisi silti käyttää rinnalla, sillä kaikki ruksit eivät aina ole kalenteritaphtumia ja sille, että jotakin saa ruksia vain n-kpl olisi käyttöä muutenkin. Kalenteriinkin se taipuu esimerkkien mukaisesti ja nimet saavat toisella viikolla olla samoja. Esimerkeissä oli myös se miten monta viikkoa näkyy sujuvasti,

https://tim.jyu.fi/view/tim/koe/taulukko/kaikkiviikot/ajat

eli lainataan eri viikkojen taulukoita samalla sivulle. Ja tämä olisi ollut ehkä nopein saada toimivaksi alustavasti syksyn Ohj1 kurssille jos olisi ollut se että ruksin viereen saa ilmojen määrän. Jos tingitään siitä että vain 20 kpl saa ruksia aluksi. Periaatteessa tuosta saa tarvittavan mutta automaattinen laskenta puuttuu:

https://tim.jyu.fi/teacher/tim/koe/taulukko/ajanvaraus

Opiskelija helppo käyttää

Calendar

Mutta yleisissä kalenterijutuissa tietysti kunnon kalenteri on toki parempi.

Miten kalenterissa nähdään että mihin on itse ilmoittautunut?
jos on esim tapahtuma jossa saa imoittautuna n kpl m:stä (esimkahteen tapahtumaan 8:sta), niin miten se esitetään?
miten perutaan ilmoittautuminen (pitää olla helppoa, koska no show on isoimpia ongelmiamme)
onko tuossa valmiina ical tms kalenterisynkkaa?
pitkällä tähtäimellä kalenteriin pitäisi saada näkyviin myös muut omat menot, niin ei ruksi aikaa, johon on muuta menoa (vähintään ne mitä on tiedossa TIMissä muiden kurssien puitteissa ja ehkä joskus Sisusta saatavilla, tosin iCal lienee saatavilla myös Google yms kalentereista).
tässäkin välttämättä ruksi-käyttöliittymä ei olisi huono jos sellaisen saisi
kuinka kompaktiksi tuon saa tehtyä että myös kännykän näyttöön mahtuu?
luentojen yms tapauksessa pitäisi olla helppoa myös ilmoittautua kaikille kurssin luentokerroille

In GitLab by @vesal on Aug 24, 2020, 16:08

Mulla on muuten hirveä pelko noita:

 event.meta.people++;

kohtaan että jos sinne taustalle ei ole saau mitään hieno koneistoa, niin digest kierroksilla on kamalasti tutkittavaa. Ja jos otettaisiin vaikka vuosinäkymä, niin kohta ollaan samassa allikossa kuin TimTablen kanssa. Mieluummin niin, ettei ole mitään automaattipäivityksiä, aan mennään ihan set-metodin kautta, joka sitten pitää huolen että näyttö päivittyy (mutta attribuutti ei ole digest-kierroksilla mukana). Jos tuo on sisäisesti saatu hoidettu niin, että mitään kierroksia ei tehdä, vaan tuo muuttaminen oikeasti kutsuu jotakin sisäistä set-metodia (kuten C#issa), niin silloin voi olla että huolehdin turhaan. Esim Ohj1 doku on hidastunut valmiiksi tuloltaan koko ajan pelkään juuri noita (siellähän on hirveä määrä csPlugineja joissa lasketaan tavaraa joka ei suinkaa ole kokoajan muuttumassa).

In GitLab by @Smibu on Aug 24, 2020, 16:47

Miten kalenterissa nähdään että mihin on itse ilmoittautunut?

Ihan miten se halutaan kalenterissa esittää. Komponentti ei itse aseta mitään rajoitteita, koska jokaista templatea voi kustomoida.

jos on esim tapahtuma jossa saa imoittautuna n kpl m:stä (esimkahteen tapahtumaan 8:sta), niin miten se esitetään?

Eventtejä voisi varmaan pluginin yamlissa ryhmitellä ja sitten sanoa, että tässä groupissa on max 2 ilmoa per käyttäjä. Pitää vielä tämä miettiä tarkemmin.

miten perutaan ilmoittautuminen (pitää olla helppoa, koska no show on isoimpia ongelmiamme)

No kalenterissa voi olla kussakin eventissä "peru", ja varmaan noista olisi hyvä lähteä joku muistitusposti emailiin 24h ennen, jossa on linkki perumiseen.

onko tuossa valmiina ical tms kalenterisynkkaa?

Ei suoraan ole, mutta jotakin sen suuntaista on pyydetty.

tässäkin välttämättä ruksi-käyttöliittymä ei olisi huono jos sellaisen saisi

Juu, mikään ei pitäisi estää tätä.

kuinka kompaktiksi tuon saa tehtyä että myös kännykän näyttöön mahtuu?

Tuo vaikuttaa osaavan tiivistyä leveyssuunnassa jo aika hyvin. Tekstit leikkautuu vähän, eli voisi ehkä olla optio että voisi katsoa vain 1 päivä kerrallaan.

luentojen yms tapauksessa pitäisi olla helppoa myös ilmoittautua kaikille kurssin luentokerroille

Joo, siihen täytyy joku keino sanoa, että tämä tapahtuma on toistuva ja sitten ilmoittautuessa kysytään, haluatko ilmoittautua vain tähän vai kaikkiin kertoihin.

In GitLab by @Smibu on Sep 4, 2020, 15:02

Hahmottelin nyt vähän, millaiselta kalenteripluginin yaml voisi näyttää:

timezone: Europe/Helsinki  # oletus
weeks:
 - 31.8.2020
 - 7.9.2020
 - 14.9.2020
 - 21.9.2020
 - 28.9.2020
# tai kelpaa myös:
weeks:
 from: 31.8.2020
 to: 28.9.2020
weekdays:  # oletus 5 arkipäivää näkyvillä per viikko
 - mon
 - tue
 - wed
 - thu
 - fri
weekevents:
 - title: Luento 1
   time: mon 10:15-12:00
   eventgroup: luento
 - title: Luento 2
   time: mon 10:15-12:00
   eventgroup: luento
 - title: Pääte 1
   time: wed 10:15-12:00
   eventgroup: paate
   max: 15
 - title: Pääte 2
   time: thu 12:15-14:00
   eventgroup: paate
# tai ehkä:
 - [Luento 1, 'mon 10:15-12:00', {eventgroup: luento}]  # flow context vaatii hipsut '...' koska sisältää ":"
 - [Luento 2, 'tue 12:15-14:00', {eventgroup: luento}]
 - [Pääte 1, 'wed 10:15-12:00', {eventgroup: paate, max: 15}]  # vähän kömpelön näköinen
 - [Pääte 2, 'thu 12:15-14:00', {eventgroup: paate}]
events:  # tähän voi lisätä epäsäännöllisiä tapahtumia
 - title: Muu tapahtuma
   time: 6.11.2020 14:00-15:00
# tai ehkä:
 - [Muu tapahtuma, '6.11.2020 14:00-15:00']
eventgroups:
 luento:
  suggestAll: true  # jos yhdenkin luennon ruksii, niin ehdotetaanko, että ruksitaan kaikki
 paate:
  max: 20  # oletusmaksimiosallistujamäärä jokaiseen tämän ryhmän tapahtumaan
  maxPerPerson: 1  # yksi henkilö voi osallistua korkeintaan näin moneen tämän ryhmän tapahtumaan per viikko

weekevents/events-syntaksille on tuossa 2 eri vaihtoehtoa, joista toinen pitäisi valita (tai jos joku keksii vielä paremman). Olen itse varmaan tuon ekan version kannalla, siis sen, missä kirjoitetaan title: jne näkyviin.
maxPerPerson-asetukselle on hankala keksiä hyvä nimi.

In GitLab by @vesal on Sep 4, 2020, 16:15

MUsta taas tuo jälkimmäinen on kompaktimpi ja helpompi tuottaa copy/pastella. Tosin se varmaan on

     `['Luento 1', 'mon 10:15-12:00', {eventgroup: luento}]`

koska ei kai tuota muuten tule merkkijonoa.

Mutta voihan sen ekankin muodon kirjoittaa:

  - {s: 'Paate 2', t: 'thu 12:15-14:00', eg: paate }

jos ei pitäisi noita nimiä niin pitkänä, niin niitä olisi vielä helppo kirjoittaa.

Mutta miltä näyttäisi tilanne, jossa on 3:na päivänä 5 ohjaus kertaa 11 viikon ajan?

Ja/tai 10 ohjaajalla 20 min jaolla varattavia aikoja 17 viikkoa?

Noita pääteohjauksia on aluksi monesti tarjolla aika paljon, mutta sitten ryhmiä vähennetään kun porukka ei enää käy.

Eli voisiko ajatella myös jotakin

 - {s: 'Paate 2', t: 'thu 12:15-14:00', eg: paate, weeks: [35-40, 42, 45] }

Entä sitten joku tapahtumat yhdistävä asia että jos tuo on kurssin tilanne, mutta opiskelijalla voisi olla oma kalenteri, jossa näkyy kaikki mihin hän on ilmoittautunut eri kursseilla (ja joskus jopa tehdä omia tapahtumia).

Entä tietorakenne niin, että jos yksi ryhmä perutaan, niin lähtee pois ilmoittautuneilta. Ja sitten tuosta lähtevä ilmoitus. Tuo oli Korpissa sisäisesti sujuvaa, mutta siellä taas oman kalenterin kerääminen ryhmätapahtumista oli hidasta.

In GitLab by @Smibu on Sep 4, 2020, 16:36

koska ei kai tuota muuten tule merkkijonoa.

Ei sen olekaan tarkoitus olla kokonainen merkkijono, vaan taulukko. Voit kokeilla pastettaa tuon yaml-parserille ja katsoa, millaisen jsonin se antaa.

Eli voisiko ajatella myös jotakin

Sopii mulle. Tuosta tosin en nyt osaa arvata lainkaan, mistä tuo "s" on lyhenne. "eg" en myöskään olisi osannut ilman tietoa sanasta "eventgroup". Mutta voihan ne ohjeisiin kirjoittaa sitten.

Pitää vielä miettiä nuo muut pointit läpi.

In GitLab by @vesal on Sep 4, 2020, 16:46

Sopii mulle. Tuosta tosin en nyt osaa arvata lainkaan, mistä tuo "s" on lyhenne. "eg" en myöskään olisi osannut ilman tietoa sanasta "eventgroup". Mutta voihan ne ohjeisiin kirjoittaa sitten.

Ajattelin stem kun se on niin monnessa muussakin paikassa TIMissä.

Tosin ei kai se title ja time niin kauhean pitkiä ole. eventgroup on jo aika pitkä. copy/pastellahan noita tehdään, mutta jos on rivillä paljon pitkiä avaimi, niin riviltä on vaikea nopealla viökaisulla nähdä mitä siellä lukee. Voisiko tuo olle synonyymejä, eli saisi käyttää kupa vaan. Onhan meillä monesti button ja buttonText?

In GitLab by @vesal on Sep 4, 2020, 17:50

Ai en tiennytkään että taulukon merkkijonoalkion voi jättää ilman hipsuja. Se tuossa Luento 1 pelotti. Ja jos eventgroup voisi olla laitettu joksikin oletuksena, sitä ei tarviisi sanoa uudelleen. Tai jos jotenkin saisi ImageX:n tyyliin niin, että jos attribuuttia ei anna, se otetaan edellisestä (ja silloin käytännössä ekalta jolla ko attribuutti on. Silloin voisi sanoa:

 - [Luento 1, 'mon 10:15-12:00', {eventgroup: luento}] 
 - [Luento 2, 'tue 12:15-14:00']
 - [Pääte 1, 'wed 10:15-12:00', {eventgroup: paate, max: 15}]
 - [Pääte 2, 'thu 12:15-14:00', {max: }]   # palauttaa maxin oletukseen

Tai sama tietueena käyttäen lyhkäisempiä nimiä. Oleellista on että jos tuota joutuu käsin kirjoittamaan, sitä olisi helppoa lukea. Ja sitten ajan kanssa editori kuten on TimTablessa jolla voi tuota samaa tuottaa.

In GitLab by @Smibu on Sep 4, 2020, 18:37

Vielä uusi ehdotus tuolle weekevents:

weekevents:
 luento:
  - [Luento 1, 'mon 10:15-12:00']
  - [Luento 2, 'tue 12:15-14:00']
 paate:
  - [Pääte 1, 'wed 10:15-12:00', {max: 15}]
  - [Pääte 2, 'thu 12:15-14:00']

In GitLab by @vesal on Sep 4, 2020, 18:43

Ei huono :-) voisiko vielä ma ja mon olla synonyymejä. Tuossa on se hyvä että ei tarvitse toistaa sitä eventgouppia koko ajan

Sitten esim luentojen kohdalta tuli mieleen että siinä ruksatessa tuleva kysymys voisi kysyä sekä leveys että pituussuunassa, eli jos viikolla on monta luentoa, niin otetaanko ne kaikki ja jos monella viikolla, niin otetaanko ne kaikki (ja sitten huomautus ett yksittäisiä tapahtumia voi käytä ottamassa pois).

Pääteohjauksessakin voisi olla tuo pituussuuntainen automaattiruksiminen (eli kaikki viikot ehdotuksena), mutta ei muita saman viikon.

Sitten kannattaa pitää mielessä että erilaisia tilastoja varten tuosta olisi hyvä saada dataa jsrunneriin tavalla tai toisella.

Ajattelitko tuolle ihan omaa kantaa vai osaksi answer-taulua. Ehkä olisi tosiaan aika raskas answer-taulussa?

Vesa

In GitLab by @vesal on Sep 4, 2020, 19:11

weekevents: luento:

[Luento 1, 'mon 10:15-12:00']

[Luento 2, 'tue 12:15-14:00'] paate:

[Pääte 1, 'wed 10:15-12:00', {max: 15}]

[Pääte 2, 'thu 12:15-14:00']

Niin joo, tähän siis vielä kaveriksi kaipaisi syntaksia, missä voisi esittää erilaisia viikkoja kuin oletuksena. En rakasta viikonumeroita, mutta itse asiassa ne toimivat seuraavalla vuodella kopioidessa kätevämmin usein kuin päivämääräät joita joutuu jatkuvasta muuttamaan.

Mutta tosiaan esim luennot ovat 11 viikkoa ja pääteohjaukset ainakin 15 viikkoa syksyllä ja moni pääteohjausryhmä lopetetaan kesken kurssin, eli joulukuussa niitä on paljon hajanaisemmin kuin syyskuussa.

Entä millä syntaksi tuon paate jalkene sanoisi että nämä kohdistuvat viikoille ... Voisi esim tehdä niin, että sanoisi ensin

 - paate:
     weeks: [37, 38, 39]
     events:
       - ...
       - ...
       - ...
     weeks: [40, 41]
     events:
       - ...
       - ...
     weeks: [42, 43, 44, 45, 46, 47, 48, 49, 50, 51]  # tosin väli olisi kiva
     events:
       - ....
       - ...

jonkin verran välejä yms voi tehdä noilla jinja-filttereilläkin

     weeks: [%%'{0}, '|srange(41,51)%%]

https://tim.jyu.fi/view/tim/ohjeita/satunnaistus#filtterit

Sitten näihin automaattisesti toistuviin tulee se riesa, että pääsiäiset yms arkipyhät sotkee ja mahdollinen viikkojen ilmoittamisformaatti vaatisi myös negaatiota tuollaisten viikkojen kohdalle. Sitten pitkälle vietynä versiossa 3.141 voisi vähintään varoittaa ajoista jotka menevät arkipyhien päälle.

     weeks: [%%'{0}, '|srange(41,51)%% -43, -47]

In GitLab by @Smibu on Sep 7, 2020, 20:18

voisiko vielä ma ja mon olla synonyymejä.

Joo, miksei suomenkielisetkin nimet voisi käydä.

Pääteohjauksessakin voisi olla tuo pituussuuntainen automaattiruksiminen (eli kaikki viikot ehdotuksena), mutta ei muita saman viikon.

Lisäsin suggestForEachWeek tuota varten.

Mutta miltä näyttäisi tilanne, jossa on 3:na päivänä 5 ohjaus kertaa 11 viikon ajan?

Saatko Sisusta exportattua jonkun ihan real-world-kalenteriesimerkin, jossa on luennot ja pääteohjaukset, niin voisin sellaisen kokeilla muuntaa? Tosin minusta tässä ei pitäisi olla ongelmaa. Ks. kortissa käyttötapaus "Luennot + pääteohjaukset".

Ajattelitko tuolle ihan omaa kantaa vai osaksi answer-taulua. Ehkä olisi tosiaan aika raskas answer-taulussa?

Ensiajatus on answer-taulu ja sen kaveriksi cache. En kuitenkaan vielä ehtinyt keksiä, kuinka tapaus "harjoitustyöryhmässä useampi opiskelija" esitettäisiin answer-taulussa järkevästi, mistä laitoinkin korttiin huomautuksen. No jaa, juuri nyt ehkä keksin yhden mahdollisuuden. Kirjoittelen jossakin vaiheessa yhden answer-esimerkin.

vaatisi myös negaatiota tuollaisten viikkojen kohdalle

Tuolle voisi filterEvents-kohdassa olla joku publicHolidays: exclude tms. ettei noita käsin tarviisi karsia pois. Ja toki voisi saman alla olla days jolla voi manuaalisti excluudailla päiviä pois. Tuo sun ehdottama negaatiosyntaksi näyttää aika eksoottiselta.

In GitLab by @vesal on Sep 8, 2020, 24:47

Sisuta ei tahdo saada mitään ulos, mutta Korpista joku vanha kurssi:

https://korppi.jyu.fi/kotka/course/student/generalCourseInfo.jsp?course=226410

(huomaa että tuolla on puoliälykäs tiivistystoiminto noille)

Korpissa noiden tekemiseen on erinomainen käyttöliittymä:

https://korppi.jyu.fi/kotka/course/teacher/studygroups.jsp?course=226410

josta tuli mieleen että esim pääte 1.1 ilmoittautuessa voisi olla ruksi ko päivän kohdalla, mutta joku ikoni mistä saisi auki popupin, jossa olisi ruksi kaikille viikoille (näytössä vko + pvm ruksin kohdalla) ja tietysti ruksirivin päässä sellainen ruksi kaikki. ELi jos ilmoittautuu yhteen, niin se on vaan ruksin laittaminen, jos moneen samalla kertaa, niin se on popupin avaaminen, ruksi kaikki ja mahdollisesti poistaa osan jossa ei aio käydä. Olisi ainakin havannollinen että mitä tulee tapahtumaan. Parempi kuin sellainen, että sokkona ilmoittautuu kaikkiin aikoihin. Se ryhmäkäsite kannatta jotenkin noissa tapahtumissa pitää, että vaikka tyyppi olisi pääte, niin silti sen alla voi olla monta ryhmää (ja kannattaa varautua siihen että noille saisi antaa salinkin) ja jossakin tilanteessa ryhmän tapahtumia voi olla useampikin viikossa (vaikka ohj1 ei niin olekkaan). Ja nimenomaan tuo ruksirivi tulisi ryhmäkohtaisesti.

In GitLab by @vesal on Sep 30, 2020, 11:30

HT ohjausaikojen varaamisesta:

Miten tuon parhaiten tekisi opiskelijan (ja ohjaajan) perspektiivistä?

Eli opiskelijan pitäisi nähdä että mihin aikoihin viikolla on ohjauksia, ekoilla kerroilla ei niin väliä kenelle. Eli kalenterissa näkyisi kaikkien "kurssin ohjaajien" vapaat ajat. Sitten jotenkin siitä aukeaisi lista ohjaajista, joita on tuohon haluttuun aikaan käytössä ja sitten valitaan ja varataan aika.

Voisi myös aloittaa kalenterin päältä Korpin tapaan suoraan suodattamaan ne ohjaajat joilta haluaa katsoa, ääritapauksessa vain yksi. Ja sitten toimii kuten edellä.

Datapuolella ongelmaksi tulee se, että missä sanotaan ja miten että ketä ohjaajia näytetään "isossa kuvassa"? Ja entä jos ohjaajilla on erimittaisia aikoja, niin miten kalenteri pilkotaan...

Ehkä tuon ketä saisi ratkaistua siten. että URLissa sivulle tultaessa olisi ohjaajien ID:t ja tuo URL tulisi kurssin kohdasta "Varaa ohjausaika".

Sitten noita URLissa tulleita voisi kalenterin päältä ruksia (oletuksena kaikki ruksittuna, ja jos vain yksi URLissa, niin ei rukseja lainkaan).

In GitLab by @Smibu on Sep 30, 2020, 16:55

https://korppi.jyu.fi/kotka/course/student/generalCourseInfo.jsp?course=226410

Onko tuolla Demo 2 -ryhmässä virhe kun ensimmäinen on 16:15 mutta muut 16:05?

In GitLab by @vesal on Sep 30, 2020, 17:20

  https://korppi.jyu.fi/kotka/course/student/generalCourseInfo.jsp?course=226410
Onko tuolla Demo 2 -ryhmässä virhe kun ensimmäinen on 16:15 mutta muut 16:05?

Ei ole. Eka oli virallsiesti 16:15 ja sitten sovittiin että muut pidetään 16:05 niin voidaan lopettaa aikaisemmin. Eli noiden aikojen ei tarvitse olla samoja keskenään.

In GitLab by @vesal on Oct 1, 2020, 10:09

Sitten tähän olisi hyvä saada jsrunner-apia ainakin sen verran että esim sivulle:

https://tim.jyu.fi/view/kurssit/tie/ohj1/2020s/tuntiopettajat

voisi kullekin ohjaajalle tehdä kentän (teksti), jossa näkyisi tyyliin

 vko 41: 3 vapaata aikaa

In GitLab by @Smibu on Oct 1, 2020, 13:45

Ohj1 syksy 2018 voisi olla tuollainen:

Avaa YAML

```yaml year: 2018 startHourMinuteOffset: 15 weekevents: luento: - [Luento 1, ma 12-14] - [Luento 2, ti 14-16] demo: - [Demo 1, ma 14-16] - [Demo 2, 'ma 16:05-18', {excepts: [{weeks: 38, time: ma 16-18}]}] - [Demo vain netti, 'ma 11:00-11:05'] paate: - [Ryhmä 1.1, ke 08-10] - [Ryhmä 1.2, ke 08-10, {weeks: 37-50}] - [Ryhmä 1.3, ke 08-10, {weeks: 37-40}] - [Ryhmä 2.1, ke 10-12] - [Ryhmä 2.2, ke 10-12, {weeks: 37-50}] - [Ryhmä 2.3, ke 10-12, {weeks: 37-41}] - [Ryhmä 3.1, ke 12-14] - [Ryhmä 3.2, ke 12-14, {weeks: 37-50}] - [Ryhmä 3.3, ke 12-14, {weeks: 37-41}] - [Ryhmä 4.1, ke 08-10] - [Ryhmä 4.2, ke 08-10, {weeks: 37-50}] - [Ryhmä 5.1, to 10-12, {excepts: [{weeks: 43, time: 'to 08-09:30'}]}] - [Ryhmä 5.2, to 10-12, {weeks: 37-50, excepts: [{weeks: 43, time: 'to 08-09:30'}, {weeks: 48-49, time: pe 10-12}]}] - [Ryhmä 5.3, to 10-12, {weeks: 37-41}] - [Ryhmä 6.1, to 12-14, {excepts: [{weeks: 43, time: to 14-16}]}] - [Ryhmä 6.2, to 12-14, {weeks: 37-50, excepts: [{weeks: 43, time: to 14-16}, {weeks: 48-49, time: pe 12-14}]}] - [Ryhmä 7.1, to 14-16] - [Ryhmä 7.2, to 14-16, {weeks: 37-50, excepts: [{weeks: 48-49, time: pe 14-16}]}] - [Ryhmä 8.1, to 16-18] - [Ryhmä 9.1, pe 14-16] - [Ryhmä 9.2, pe 14-16, {weeks: 37-50}] - [Ryhmä 9.3, pe 14-16, {weeks: 37-41}] pp: - [PahastiPihalla 1, pe 10-14] - [PahastiPihalla 2, pe 10-14] - [PahastiPihalla 3, ke 16-18, excepts: [{weeks: 49-50, time: pe 16-18}]] htnaytto46: - [HT-näyttö 2, ke 10-12] - [HT-näyttö 6, to 12-14] - [HT-näyttö 7, to 14-16] - [HT-näyttö 9, pe 14-16] htnaytto47: - [HT-näyttö 2.2, ke 10-12] - [HT-näyttö 3, ke 12-14] - [HT-näyttö 6.2, to 12-14] - [HT-näyttö 7.2, to 14-16] - [HT-näyttö 10, pe 14-16] htnaytto48: - [HT-näyttö 1, 'ke 08:30-10'] - [HT-näyttö 2.3, ke 10-12] - [HT-näyttö 3.2, ke 12-14] - [HT-näyttö 4, ke 14-16] - [HT-näyttö 5, pe 10-12] - [HT-näyttö 6.3, pe 12-14] - [HT-näyttö 7.3, pe 14-16] htnaytto49: - [HT-näyttö 10.2, ti 10-12] - [HT-näyttö 11, ti 10-12] - [HT-näyttö 12, ti 12-14] - [HT-näyttö 13, ti 14-16] - [HT-näyttö 23, ke 10-12] - [HT-näyttö 24, ke 12-14] - [HT-näyttö 25, ke 14-16] - [HT-näyttö 26, ke 16-18] - [HT-näyttö 27, pe 14-16] htnaytto50: - [HT-näyttö 14, ti 10-12] - [HT-näyttö 15, ti 12-14] - [HT-näyttö 16, ti 14-16] - [HT-näyttö 17, ti 16-18] - [HT-näyttö 18, ma 14-16] - [HT-näyttö 28, ke 10-12] - [HT-näyttö 29, ke 10-12] - [HT-näyttö 30, ke 12-14] - [HT-näyttö 31, ke 14-16] - [HT-näyttö 32, to 10-12] - [HT-näyttö 33, to 12-14] - [HT-näyttö 34, to 14-16] - [HT-näyttö 35, to 16-18] - [HT-näyttö 36, pe 14-16] - [HT-näyttö 37, pe 12-14] htnaytto51: - [HT-näyttö 38, ti 10-12] - [HT-näyttö 39, ti 12-14] - [HT-näyttö 40, to 10-12] - [HT-näyttö 41, to 12-14] events: - [PP-luento, ti 16-18, {weeks: 43}] eventgroups: luento: weeks: 37-48 suggestAllInEventGroup: true demo: weeks: 38-48 suggestForEachWeek: true paate: weeks: 37-47 suggestForEachWeek: true max: 20 maxPerPerson: 1 pp: weeks: 39-50 max: 20 htnaytto*: min: 5 max: 15 htnaytto46: weeks: 46 htnaytto47: weeks: 47 htnaytto48: weeks: 48 htnaytto49: weeks: 49 htnaytto50: weeks: 50 htnaytto51: weeks: 51 ```

Onkos väliä, olisiko tunti/minuuttierottimena : sijaan .? Silloin ei tarviisi noita hipsuja mihinkään. Tuon startHourMinuteOffsetin ansiosta suurimmasta osasta voi jättää minuutit pois.

In GitLab by @Smibu on Oct 1, 2020, 15:56

Datapuolella ongelmaksi tulee se, että missä sanotaan ja miten että ketä ohjaajia näytetään "isossa kuvassa"? Ja entä jos ohjaajilla on erimittaisia aikoja, niin miten kalenteri pilkotaan...

No sen "ison" kalenterin markuppiin voisi ehkä laittaa jonkun

combine:  # tms nimi
 - ohjaaja1
 - ohjaaja2
 - ...

eli nuo viittaisivat muihin kalenteriplugineihin. Jos kukin ohjaaja laittaa omat aikansa omaan pluginiin, niin tuo yhdistävä plugin sitten vain hakisi ne ja näyttäisi kaikki yhdessä kalenterissa. Ja sitä voisi GUIssa toki suodattaa, että näyttää vain tietyt ohjaajat jne.

Saattaa olla, että ajanvarauksille voisi oma taulu kannassa olla kuitenkin parempi. Postgressissä on tstzrange-tietotyyppi tällaiselle use caselle, jolloin tietynlaisia hakuja voisi tehdä hyvin nopeasti.

In GitLab by @vesal on Oct 3, 2020, 10:57

Ohj1 esimerkkiin:

Miten jos kurssin tapahtumia jakautuu usealle vuodelle (niitä on 2. periodin alkaville kursseille)?
Entä tapahtuman paikka? Myös linkkinä, koska nyt Koronassa paikka on ohjaajan Zoom tai luennoissa kurssin Zoom.
käsin kirjoitettuna tuo htnaytto51 ja sen weeks on eri paikassa, on vähän työlästä ja virhealtista. Eventgroupsin tietojako ei voisi saada suoraan eventin yhteyteen halutessaan?
piste ja : voisivat molemmat olla käytössä ja jos kirjoittaa : niin sitten kirjoittaa "12:30"
sitten samalla tavalla kuin ohjaajien kalenterit, voisi olla että saa kirjoittaa kunkin eri tyylisen "kalenterin" (esim luento, demo jne) eri komponenttiin, mutta sitten voisi yhdistää nuo yhdeksi kalenteriksi tuollaisella combine ja siinä voisi sitten ruksia päälle pois mitä haluaa katsoa.

In GitLab by @Smibu on Oct 5, 2020, 11:16

Miten jos kurssin tapahtumia jakautuu usealle vuodelle (niitä on 2. periodin alkaville kursseille)?

Hmjoo, varmaan pitää voida eventti(grouppi)kohtaisesti säätää myös vuosi... hahmottelen tuohon jotakin.

Entä tapahtuman paikka? Myös linkkinä, koska nyt Koronassa paikka on ohjaajan Zoom tai luennoissa kurssin Zoom.

Lisään sille vaikka placen. Jos se alkaa http[s]://, niin sitten se tulkittakoon linkiksi.

käsin kirjoitettuna tuo htnaytto51 ja sen weeks on eri paikassa, on vähän työlästä ja virhealtista. Eventgroupsin tietojako ei voisi saada suoraan eventin yhteyteen halutessaan?

Saahan sen, mutta silloin joutuu vaan toistelemaan sitä weeksiä enemmän:

  - [HT-näyttö 2, ke 10-12, {weeks: 46}]
  - [HT-näyttö 6, to 12-14, {weeks: 46}]
  - [HT-näyttö 7, to 14-16, {weeks: 46}]
  - [HT-näyttö 9, pe 14-16, {weeks: 46}]
  - [HT-näyttö 2.2, ke 10-12, {weeks: 47}]
  - [HT-näyttö 3,   ke 12-14, {weeks: 47}]
  - [HT-näyttö 6.2, to 12-14, {weeks: 47}]
  - [HT-näyttö 7.2, to 14-16, {weeks: 47}]
  - [HT-näyttö 10,  pe 14-16, {weeks: 47}]

Mutta voihan tuohon lisätä sen option, jota jossain vaiheessa ehdotit, että se oletus vaihtuu lennossa, eli riittää toistaa weeks vain, jos se muuttuu edelliseen verrattuna. Mutta en sitä laittaisi oletuksena päälle, vaan se olisi joku dynamicDefaults: true tai usePreviousByDefault: true.

In GitLab by @vesal on Oct 5, 2020, 11:23

Mutta voihan tuohon lisätä sen option, jota jossain vaiheessa ehdotit, että se oletus vaihtuu lennossa, eli riittää toistaa weeks vain, jos se muuttuu edelliseen verrattuna. Mutta en sitä laittaisi oletuksena päälle, vaan se olisi joku dynamicDefaults: true tai usePreviousByDefault: true.

Tuon on ok mulle :-)

Mites voisiko kuitenkin weeksin kanssa vaihtoehtona olla date (tms) jolla saa antaa rehellisne pvm tyyliin

{date: 5.10.2020}

ja sitten saa ajonaikaisen virhene jos se ei täsmään viikonpäivän kanssa tai jopa viikonpäivää ei silloin tarvitse.

Voi olla joskus kätevämpi yksittäisissä tapahtumissa. Viikot ovat käteviä kun monistaa tulevalle vuodelle, niin pvm siirtyvät viikonpäivien ansiosta automaattisesti. Tosin ne ei-työpäivät sotkevat...

In GitLab by @Smibu on Oct 5, 2020, 14:07

Päivitetty Ohj1 s2018:

Avaa YAML

```yaml year: 2018 startHourMinuteOffset: 15 usePreviousByDefault: [weeks] weekevents: luento: - [Luento 1, ma 12-14] - [Luento 2, ti 14-16] demo: - [Demo 1, ma 14-16] - [Demo 2, ma 16.05-18, {excepts: [{weeks: 38, time: ma 16-18}]}] - [Demo vain netti, ma 11.00-11.05, {place: -}] paate: - [Ryhmä 1.1, ke 08-10, {weeks: 37-47, place: Ag B212.2, excepts: [{weeks: 42, place: Ag B213.1}]}] - [Ryhmä 1.2, ke 08-10, {weeks: 37-50, place: Ag B213.1, excepts: [{weeks: 42, place: Ag B212.2}]}] - [Ryhmä 1.3, ke 08-10, {weeks: 37-40, place: Ag B212.1}] - [Ryhmä 2.1, ke 10-12, {weeks: 37-47, place: Ag B212.2, excepts: [{weeks: 42, place: Ag B213.1}]}] - [Ryhmä 2.2, ke 10-12, {weeks: 37-50, place: Ag B213.1, excepts: [{weeks: 42, place: Ag B212.2}]}] - [Ryhmä 2.3, ke 10-12, {weeks: 37-41, place: Ag B212.1}] - [Ryhmä 3.1, ke 12-14, {weeks: 37-47, place: Ag B212.2}] - [Ryhmä 3.2, ke 12-14, {weeks: 37-50, place: Ag B213.1}] - [Ryhmä 3.3, ke 12-14, {weeks: 37-41, place: Ag B212.1}] - [Ryhmä 4.1, ke 08-10, {weeks: 37-47, place: Ag B212.2}] - [Ryhmä 4.2, ke 08-10, {weeks: 37-50, place: Ag B213.1}] - [Ryhmä 5.1, to 10-12, {weeks: 37-47, place: Ag B212.2, excepts: [{weeks: 39, place: Ag B213.1}, {weeks: 43, time: to 08-09.30}]}] - [Ryhmä 5.2, to 10-12, {weeks: 37-50, place: Ag B213.1, excepts: [{weeks: 39, place: Ag B212.2}, {weeks: 43, time: to 08-09.30}, {weeks: 48-49, time: pe 10-12, place: Ag B212.1}]}] - [Ryhmä 5.3, to 10-12, {weeks: 37-41, place: Ag B212.1}] - [Ryhmä 6.1, to 12-14, {weeks: 37-47, place: Ag B212.2, excepts: [{weeks: 43, time: to 14-16}]}] - [Ryhmä 6.2, to 12-14, {weeks: 37-50, place: Ag B213.1, excepts: [{weeks: 43, time: to 14-16}, {weeks: 48-49, time: pe 12-14, place: Ag B212.1}]}] - [Ryhmä 7.1, to 14-16, {weeks: 37-47, place: Ag B212.2, excepts: [{weeks: 39, place: Ag B213.1}]}] - [Ryhmä 7.2, to 14-16, {weeks: 37-50, place: Ag B213.1, excepts: [{weeks: 39, place: Ag B212.2}, {weeks: 48-49, time: pe 14-16, place: Ag B212.1}]}] - [Ryhmä 8.1, to 16-18, {weeks: 37-47, place: Ag B212.2}] - [Ryhmä 9.1, pe 14-16, {weeks: 37-47, place: Ag B211.1, excepts: [{weeks: 43, place: Ag B212.2}]}] - [Ryhmä 9.2, pe 14-16, {weeks: 37-50, place: Ag B212.1, excepts: [{weeks: 43, place: Ag B213.1}, {weeks: 49, place: Ag B212.2}]}] - [Ryhmä 9.3, pe 14-16, {weeks: 37-41, place: Ag B212.2}] pp: - [PahastiPihalla 1, pe 10-14, {place: Ag B212.2}] - [PahastiPihalla 2, pe 10-14, {place: Ag B213.1}] - [PahastiPihalla 3, ke 16-18, {place: Ag B212.2, excepts: [{weeks: 49-50, time: pe 16-18}]}] htnaytto: - [HT-näyttö 2, ke 10-12, {weeks: 46, place: Ag B212.1}] - [HT-näyttö 6, to 12-14, {place: Ag B113.1}] - [HT-näyttö 7, to 14-16, {place: Ag B113.1}] - [HT-näyttö 9, pe 14-16] - [HT-näyttö 2.2, ke 10-12, {weeks: 47, place: Ag B212.1}] - [HT-näyttö 3, ke 12-14] - [HT-näyttö 6.2, to 12-14, {place: Ag B113.1}] - [HT-näyttö 7.2, to 14-16] - [HT-näyttö 10, pe 14-16] - [HT-näyttö 1, ke 08.30-10, {weeks: 48}] - [HT-näyttö 2.3, ke 10-12] - [HT-näyttö 3.2, ke 12-14] - [HT-näyttö 4, ke 14-16] - [HT-näyttö 5, pe 10-12] - [HT-näyttö 6.3, pe 12-14] - [HT-näyttö 7.3, pe 14-16] - [HT-näyttö 10.2, ti 10-12, {weeks: 49}] - [HT-näyttö 11, ti 10-12] - [HT-näyttö 12, ti 12-14] - [HT-näyttö 13, ti 14-16] - [HT-näyttö 23, ke 10-12] - [HT-näyttö 24, ke 12-14] - [HT-näyttö 25, ke 14-16] - [HT-näyttö 26, ke 16-18] - [HT-näyttö 27, pe 14-16, {place: Ag B211.1}] - [HT-näyttö 14, ti 10-12, {weeks: 50, place: Ag C331.3}] - [HT-näyttö 15, ti 12-14] - [HT-näyttö 16, ti 14-16, {place: Ag C331.3}] - [HT-näyttö 17, ti 16-18] - [HT-näyttö 18, ma 14-16] - [HT-näyttö 28, ke 10-12] - [HT-näyttö 29, ke 10-12] - [HT-näyttö 30, ke 12-14] - [HT-näyttö 31, ke 14-16, {place: Ag B212.1}] - [HT-näyttö 32, to 10-12] - [HT-näyttö 33, to 12-14] - [HT-näyttö 34, to 14-16] - [HT-näyttö 35, to 16-18] - [HT-näyttö 36, pe 14-16] - [HT-näyttö 37, pe 12-14, {place: Ag B212.1}] - [HT-näyttö 38, ti 10-12, {weeks: 51}] - [HT-näyttö 39, ti 12-14] - [HT-näyttö 40, to 10-12] - [HT-näyttö 41, to 12-14] events: - [PP-luento, ti 16-18, {weeks: 43, place: Ag C221}] eventgroups: luento: weeks: 37-48 suggestAllInEventGroup: true place: Ag Auditorio 3 demo: weeks: 38-48 suggestForEachWeek: true place: Ag Auditorio 3 paate: weeks: 37-47 suggestForEachWeek: true max: 20 maxPerPerson: 1 pp: weeks: 39-50 max: 20 htnaytto: min: 5 max: 15 place: Ag B212.2 ```

Tuo "käytä oletuksena edellistä arvoa" varmaan kannattaa rajoittaa attribuuttikohtaisesti. Laitoin siihen vain weeks. Muuten tuosta tulee minusta sotkuisempi.

{date: 5.10.2020}

Joo on tarkoitus, että events-kohdassa voi antaa myös suoria päivämääriä.

In GitLab by @Smibu on Oct 5, 2020, 14:24

Hmjoo, varmaan pitää voida eventti(grouppi)kohtaisesti säätää myös vuosi... hahmottelen tuohon jotakin.

Tähän yksinkertaisin voisi olla:

year: 2018-2019
yearsplitweek: 38

yearsplitweek tarkoittaisi, että jos viikkonro on 38 tai suurempi, ollaan vuodessa 2018 ja jos pienempi, niin vuodessa 2019.

In GitLab by @vesal on Oct 5, 2020, 17:34

Tähän yksinkertaisin voisi olla:

year: 2018-2019 yearsplitweek: 38

yearsplitweek tarkoittaisi, että jos viikkonro on 38 tai suurempi, ollaan vuodessa 2018 ja jos pienempi, niin vuodessa 2019.

Onko tuossa edelleen riski siihen että joku juttu jatkuisi 2 vuotta, kuten esim Upsalan yliopistossa eiole Ohj1, Ohj2 jne vaan yksi jättikurssi jota tehdään toista vuotta. Ja sitten voi tulla kesälomia yms sekaan.

In GitLab by @Smibu on Oct 5, 2020, 18:59

Silloin vaan määrittää vuoden tapahtumakohtaisesti tai tapahtumaryhmäkohtaisesti. Se splitweek soveltuu alle 1v kestäviin.

In GitLab by @Smibu on Jun 30, 2021, 18:09

unassigned @Smibu

marked the task ruutua ei näytetä jos määrä ylittynyt (jos määrä >0 näytetään määrä tai vapaat kuitenkin, attribuutti) as completed

marked the task sähköpostia mikäli ruksi lähtee/tulee ruutuun tietyn ajanhetken jälkeen (attribuuttina sp) as completed

marked the task attribuutilla voi rajoittaa milloin saa "vastata" (taitaa jo ollakin), mutta voisi olla as completed

marked the task integrointi kalenteriin niin että omat ruksit näkyvät kalenterissa as completed

marked the task integrointi kalenteriin niin, että jos kalenterista poistaa tapahtuma, ruksi lähtee pois as completed

marked the task automaattinen muodostaminen päivät vaakaan tai pystyyn kun annetaan varausajan pituus (vrt Korppi) as completed

Kalenterit alustavasti toteutettu !394:ssa. Kaikki toteutamatta jääneet kohdat siirretty yhteiseen kalenterikomponentin jatkokehityskorttiin: #2646. Sen myötä laitan tämän kortin kiinni, niin kaikki uudet vaatimukset listataan uuteen korttiin.

TIM-JYU / TIM