svip / dikurevymeets Goto Github PK

Ved afkrydsning af det der ser ud til at være 'skjult?' forsvinder eventet helt fra listen. Eksisterer dette stadig eller skal det oprettes igen?

Jeg har lagt mærke til nogle fejl ved opførelsen omkring lukning af måltider og tilmeldinger for betaling.

Når et program ændrer sig nu, så optræder nogle brugere bagefter som tilmeldt til f.eks. et nyt måltid eller møde, men ikke alle. Men ingen skal optræde som tilmeldt (eller ikke tilmeldt) til en begivenhed de ikke selv har haft mulighed til at indberette omkring.

Det skal nemlig være let for bosserne at se om en revyt har indberettet om en begivenhed.

Grunden ligger nok i at når man udfører ændringer til en begivenhed, så sender man faktisk også data for hver bruger til den begivenhed. Disse to ting bør separeres.

Man kan også overveje muligheden for om brugere der har ?-spørgsmålstegn ved deres indberetninger skal have en »advarsel« på toppen af hver side indtil de får indberettet omkring disse begivenheder. Og måske sågar elektropost til dem hvis vi har adgang til deres elektroadresser.

Det skal være muligt at redigere teksten for påmindelsesmailen i backenden (gerne også hvornår det sendes ud m.m.) Umiddelbare tekstfelter det vil være rart at kunne rette:
Emnefelt (nuværende: 'De tre næste måneders revymøder') - skal under alle omstændigheder ændres til 'Kommende begivenheder for DIKUrevy'
Headertekst (nuværende: ikke eksisterende)
Tekst før månedens begivenheder (nuværende: 'Denne måneds revymøder:')
Tekst før resterende begivenheder (nuværende: 'De efterfølgende to måneder:')

Ikkebrugere mister deres navne når der bliver ændret mødedata fra adminen.

begivenheder for denne måned spytter også næste måneds begivenheder ud, dvs. den printer ud for 2 måneder. Samtidig bliver der hentet begivenheder 4 måneder frem i stedet for kun tre.

Optimalt ville være hvis man kunne indstille i backenden hvor mange måneder frem der vises med de 2 forskellige visninger.

Er der ikke en kapløbssituation i database.php for funktionaliteten, der gemmer databasen til en fil? Hvad forhindrer to samtidige forespørgsler i at kollidere med hinanden?

Selvom at alle skal kunne lukke for madtilmeldingen, så bør kun madherre kunne åbne for madtilmeldingen (udover administratorer).

Lige nu optræder underbegivenheder (altså programmet) i flerdagsbegivenheder kun for den første dag i kalenderen. En ny syntaks bør gøre det muligt at tilføje begivenheder til de efterfølgende dage.

Første dags (dag 0) syntaks bør forblive som den er, så vi ikke behøver at ændre på de gamle begivenheder.

Anden dagen og frem (dag n > 0) bør blive skrevet som dag tid, f.eks. '1 12:00' for anden dag (dag 1), klokken 12:00. Vi nul-indekserer, selvfølgelig. '0 12:00' er selvfølgelig også en tilladt syntaks.

Overstiger antallet af dage længden af flerdagsbegivenheder, bliver de indsat på den sidste dag i begivenheden.

Sluttidspunkter skal følge samme syntaks. Som altid, hvis et sluttidspunkt er før startstidpunktet er det en fejl, og systemet vil derfor anskrive det som en time.

Den nupper Munter!

Under 'PR-møder' blev selve event-tilmeldingen ikke vist - kun tilmelding til spisning.

Har en begivenhed ikke tilmelding, så henvises der ikke til den fra forsiden. Derfor skal sådanne begivenheder heller ikke optræder i top-navigationen.

Det skal være tilladt at bruge revymøderkalenderen som et sted hvor man melder fra, før en begivenhed bliver lukket. Nogle gange bliver begivenhederne bare ikke lukket manuelt (faktisk stort set alle gangene), og så er de åbne lige indtil dagen derpå.

Det kan i nogle tilfælde være et problem. Tag en hyttetur: En har valgt at tilmelde sig, men vælger - 24 timer forinden - at melde fra. Det er derfor muligt at det er inden for et tidsrum, hvor bosserne ikke vil se denne ændring.

Derfor bør der være en mulighed for at bede et møde om at informere hver gang en bruger ændre sin status. Hvilken mail-adresse dette bliver sendt til skal kunne ændres i en generisk indstillingsgrænseflade.

Derudover, kan man også overveje muligheden for at sende alle der har tilmeldt sig et særligt møde om at få en mail dagen før, om at de er tilmeldt. Dette skal igen være en indstilling som er per møde og ikke per bruger. Deres mail-adresser kan hentes fra Drupal-systemet.

Når man ændre starttidspunktet på et eksisterende måltid forsvinder det helt. Det bør ikke ske.

Det bør være MatStatDatrevyMøder.

Hvis en madtilmeldingen er lukket, og man er tilmeldt mad, men vil f.eks. ændrer sin kommentar (eller ting der ikke har med maden at gøre), så bliver man frameldt maden, selvom man er tilmeldt.

Hvis en dato er overstået skal den låses og fjernes fra oversigten (dette vil ikke ske med det nuværende system, desværre; det opdager I nok den sjette).

Lige nu kan madnegre ikke lukke for madtilmeldingen, det vil give god mening hvis de kunne.

Derudover skal knappen optræde reelt disabled når de er (lige nu optræder de bare med den almindelige farve efter mit CSS-hack).

Når man klikker »endnu et måltid« svarer Fejlkonsolen:

Fejl: kids[i].getAttribute("for") is null
Kildefil: http://moeder.dikurevy.dk/media/admin.js
Linje: 43

Det ville være lækkert hvis man kunne navigere mellem møderne med 'næste' og 'forrige'-knapper når man besøger et møde, således kan man nemlig hurtigere gennemgå alle møderne og pålægge dem ens tilmeldelse eller ej.

Hvad gør jeg galt, Munter!?

Tillad en person at tilmelde personer der ikke er tilmeldt revyen og forbind disse tilmeldinger til tilmelderens konto.

Det giver et bedre overblik hvis spisning og møder optræder seperat i ical feedet.
ical feedet bør være en korrekt representation af dagsplanen, så ledes at man kan benytte ical feedet til at gennemskue tidsplanen ved at synkronisere sin kalender i stedet for at skulle besøge hjemmesiden.

Dertil vil opsplitningen give yderlige relevante informationer, da man da vil kunne vise deltagerantal seperat for spisninger og møder, hvilket igen kan være en hjælp til at se status på sin mobilenhed direkte i stedet for at skulle besøge hjemmesiden.

Selvom at folks opdateringer af deres tilmeldinger og lukning for madtilmeldning er forholdsvis logget, så er ændringerne administratorerne foretager ikke. Hvis #35 skal implementeres, så bliver man nød til at have dette, således at man se hvem der misbruger systemet.

Når man vedligeholder et møde fra admin-grænsefladen og vil ændre folks tilmeldinger, så ændrer den også personen som har lukket for madtilmeldingen til Systemet. Dette er en fejl.

Nuværende er det kronologisk, hvilket betyder en masse gamle begivenheder ligger i toppen. Det er ikke hensigtsmæssigt.

Strukturforslag:

[liste af åbne begivenheder]
[form til ny begivenhed]
[liste af gamle begivenheder]

Skal det være per ical-definition eller en hel ny variabel?

Inspireret af #32, så burde det være en idé med mulighed for at madherre kan styre deres regnskab efter et måltid hvem der reelt spiste med og hvem der ikke spiste med.

Følgende informationer føler jeg er relevante for brugere af ical feedet:

• Link til tilmelding
• Beskrivelse som givet på tilmeldingssiden
• I fald tilmeldingssiden ikke er bag et login, listen over tilmeldte.

Jeg foreslår at alle tilføjes til DESCRIPTION i hvert individuelt VEVENT

Det kniber lidt for lange navne i tilmeldingsformularen. Det bør der gøres noget ved.

Det ville være en rar feature at man kunne tildele tags til møderne og bruge dem til at filtrere ical feedet. F.eks. et tag der hedder 'revyer' hvor andre revyers datoer bliver tildelt eller 'møder' hvor det kun er møderne der bliver vist. På den måde kan man vælge præcis hvilke events man gerne vil have ud.

man kunne gøre det til en + separeret liste i urladressen på ical feedet. f.eks.

http://møder.dikurevy.dk/?do=ical&tags=moeder+revyer

Tillad flerdagsbegivenheder.

Skal der være mulighed for at kunne tilmelde sig delene enkeltvis eller skal sådan en feature overhovedet ikke være tilgængelig? Selvfølgelig, hvis det var muligt, ville det ikke være standard, men tillade enkelpersoner at notere at de måske ikke kan deltage i hele begivenheden.

Jeg froeslår at SUMMARY for det enkelte VEVENT bør være titlen på eventet, samt antallet af deltagere tilmeldt til eventet.

Eksempel: "Forfattermøde: n deltagere".

Det er anonymiseret, men giver relevant information.

DTSTAMP for det enkelte VEVENT bør i dette tilfælde være datoen for sidste modificering af en tilmelding i stedet for starttidspunktet for eventet.

Det bør være muligt for folk der ikke er medlem til at tilmelde sig møder selvom de ikke er medlem.

Men det skal være muligt at begrænse om hvorvidt ikke-medlemmer må tilmelde sig. F.eks. bør man kræve at man er medlem (eller tilmeldt af et medlem[1]) for at man kan tilmelde sig en hyttetur.

Det begrænses på punkt-niveau, således at f.eks. madlavning vil kræve man er medlem men selve mødet kræver det ikke.

Når et ikke-medlem er tilmeldt, vil deres række i listen over tilmeldte folk optræde med en anden nuance, således at man kan se de ikke er medlemmer.[2] Selv hvis de kan tilmelde sig madlavning, så kan de ikke lukke for madtilmeldingen.[3]

Desuden skal ikke-medlemmer indtaste en simpel captcha før de kan tilmeldes.

[1] Funktionen med at tilmelde ekstra personer vil selvfølgelig forblive.
[2] Medlemmer tilmeldt af andre medlemmer vil forsat optræde som nu.
[3] Måske man bør overveje om de overhovedet kan tilmelde sig til madlavningen, og måske blot at de kun kan tilmelde sig til at spise med. Eller måske blot som madhjælpere? Tre flag virker bare lidt i overkanten.

Jeg har lagt mærke til at hytteturen ikke indgår i den nuværende kalender. Jeg skal have set på dette problem. Desværre har jeg ikke mulighed for at fikse det før på onsdag. Så jeg laver lige denne rapport for at minde mig om det.

En simpel implementering af #35, vil nok betyde en simpel adgang til administratorgrænsefladen (dog begrænset for den dag de er madherre), men der er potentielt mulighed for at nogle brugere kunne tænke sig at misbruge denne funktionalitet (tilmeld sig som madherre, luk madtilmeldingen, skriv noget dumt i administratorgrænsefladen), så udfra loggen (#36) kan man se hvem der har gjort det og derefter blokere dem (denne adgang vil de jo ikke have).

På en tilmeldingsside findes teksten "Tilmeld en extra person". På dansk er "ks" da at foretrække frem for "x", ikke?

Det var faktisk meningen de automatisk skulle forsvinde, men det virker åbenbart ikke. Jeg ser på det senere. Har lige fikset to markante fejl.