Moglege løysingar:

• setja som dífålt at utmelde medlemer er luka bort
• leggja inn sperre mot utmelde medlemer i t.d. "enkel medlemsliste"
• på andre vis køyra det klassiske windowsspørsmålet ER DU HEILT SIKKER når nokon har gjer eit utval som inkluderer nokon som er utmelde

Eller noko anna.

Whenever innbetalt_belop changes so that it matches (or exceeds?) belop, set status to finished.

Or do it client-side with javascript. To detangle status a bit from innbetalt_belop.

The problem at least is that the manual setting to status finished is a hassle.

Eg har vore ganske schizofren på språkval, fordi eg aldri tok eit heilt klart. Eg tykkjer det bør vera norsk nynorsk og ikkje engelsk iom. at det berre rettar seg mot norske brukarar / organisasjonar.

Likevel, det er rart å skriva norsk i kode, so eg starta so vidt å kalla ting ved engelske namn for ei stund sidan. Det vert for schizofrent, so eg er attende på sida om å berre ha alt på norsk.

Men eg er altso frykteleg usikker.

OI eg kom borti CAPS LOCK. Men me treng det litt raskt :S :S :S :S

Karl Peder:

eg treng ei liste eg kan få ut som inneheld
Namn, adresse, telefon, fødeår, epost, KID
Eg finn berre lister som har KID, men ikkje telefon, og adresse men ikkje KID osf.

Eskil sa:

Når me skal ta ut revisorliste i år treng me ein kolonne der kommentaren til
betalinga er med i ei eiga kolonne sånn at me veit om dei er betalt med eller
utan KID. Men det er ikkje superhast. Me skal ikkje til revisor med det aller
første.

So the csv export of revisor list (giro) needs giro comment.

Currently we do not track our communications with the members. It would be nice to log the email messages we send, just as we send them (all merged together and with the real data).

Communication is not only email, but also printed letters, handled by pdf.

I revisorlista hadde det vore superknall om det vart markert automatisk kven som har vorte registrerte med OCR-køyring. Pr. no ser alle som har betalt til medlemspengekonto heilt like ut – dvs. at det vil ta lengre tid å sjekka medlemslistene til revisor enn det gjorde før KID-tida ...

Kva lisens vil passa best?

Eg har mest lyst til å bruka AGPL, som seier at alle som har skikkeleg tilgang til programvara og er brukarar av ho, skal få tilgang til kjeldekoden (med endringar) dersom dei vil.

Det vernar om fridomen til enkeltindivida. Einaste ulempa er dersom det fører til noko ekstra administrasjon. Eit REST API vil elles hjelpa til med å gjera registeret enkelt utvidbart for folk som ikkje vil frigje koden sin til medlemar.

Funksjonen: Digital utfylling av ...

... årsmeldingsskjema (namn, kommune-/fylkestilhøyrsle og kontaktinfo til laget; namn og adresse til betalande tillitsvalde pr. 31.12; datoen desse vart valde og kva periode dei er valde for; diverse felt for rekneskap og aktivitet elles)

... årsmøteskjema (namn, årsmøtedato, kontaktinfo til laget; namn, adresse og tlf til tillitsvalde; andre vedtak)

... skipingsmøteskjema (som årsmøteskjema, berre med ekstra felt for kommune-/fylkestilhøyrsle)

... Frifondssøknadsskjema (namn på lag, søknadstekst, budsjett)

... Frifondrapportskjema (namn på lag, rapporttekst, rekneskap)

(rekkjefylgja er prioritert ...)

Krav frå styresmaktene:

• «en betryggende metode for å autentisere avsender og innholdet av rapporten» ( = lokallagsleiarar må kunna skaffa seg passord automatisk (dvs. utan manuell innblanding frå SST), og SST kan ikkje ha tilgang på lokallagsleiaren sin brukar. Trur eg)

Litt hastverk: me har ein del problem ved utskrift av giroar til nye medlemer (velkomstpakkar), fordi me ikkje har nokon enkel måte å sortera ut dei som skal få utskrift av giroen sin på. Kan me sortera giroane etter innmeldingsdato for medlemen giroen er knytt til?

Ynskt funksjon: Skriv ut adresselappar for avkryssa medlemer (rullegardinmenyval à la "enkel medlemsliste")

Format: 3x7 lappar pr A4-ark
Marg venstre og høgre: 7mm på kvar side
Marg oppe og nede: 15mm på kvar side
Mellomrom mellom dei tre kolonnane: ca 2,67mm
Mellomrom mellom radene: 0
Format på kvar lapp: ca 63,55 x 38,14

After asking the question in #2, all of the ones who answered (grand total of two) is in favour of AGPL.

So let's do it. Open for patches.

Når nokon vert utmeld, står giroen framleis ubetalt, og kjem opp i girosøket. Truleg ei uheldig kjelde til feilsending av giro til folk som har meldt seg ut. Hadde vore supert om ubetalte giroar vart sletta når nokon vert utmeldt.

The current way we define membership is very restrictive, and not very good. Every member is expected to have a membership in some way, and they are expected to be the same. The user of the system is expected to filter the members and create custom giros for each of them. Basically membership management is manual.

It would be nice to a) connect the membership to the user in a more clear way b) allow for automating (letting the member figure out herself what type she'll probably be).

There's some issues though, how to mark that a membership exists (is "open" I guess) and how to mark it is valid? It has a start and end-date. That's how we mark it as open. But if it's paid it will be not only be open but also valid. The giros are connected to the membership, and thus you can look at the giro for say 2014 and see that it is paid, hence the membership for 2014 will be valid.

However, there's a slight disconnect between membership and giro. Because a giro can also be paid for two years (common for barne og ungdoms-organisasjonar). 100kr paid in 2013 should also count as valid for 2014.

It could be possible to mark giros with not only gjeldande_aar but maybe rather valid_from and valid_to date markers? An issue is that code will be more complex, but it would allow to have non-yearly memberships. Or in the vein of simplicity, maybe rename gjeldande_aar to valid_from_year and have an integer valid_years which will be 1 in most cases, but in the 100kr (50kr + 50kr two-year membership) it will be 2.

Also, memberships is highly different between organisations, so it needs to be replaceable. It should probably be the first actual use of behaviours.

Other assignments I've worked on could just have the settings files as part of the project. Only taking out the secret keys etc. -- However, this is meant to be generally useful for third-parties, and I don't think we all should have our configs in this project.

Also, it's eaiser when it's just one django app, and you don't expect to give any project at all. But this is in-between those. It's no single pluggable app, it's meant to be used as a project, but django does not always make that super easy.

It's worth looking into what other projects do here.