voko-utrecht / voko Goto Github PK

For the read only members admin page (Leden (read-only)) a hack was necessary:
https://github.com/rikva/voko/blob/7facf99bbd002ffc39004a8894c49786d26e6935/webapp/accounts/admin.py#L238-L259

Looks like the feature has been implemented though:
https://code.djangoproject.com/ticket/8936
django/django#6734

If I understand it correctly it was released with the 2.1 version of Django:
https://docs.djangoproject.com/en/2.2/releases/2.1/#model-view-permission

Ik begrijp van de mensen die de ledenadministratie doen en de documenten die online staan dat het organiseren van de info avonden een hoop werk kost. Ik wil kijken of we een groot deel van dit werk kunnen automatiseren.

Ik vermoed dat we ongeveer zoiets nodig hebben:

• Info avonden rooster kunnen bijhouden, met per avond:
  • Datum + tijd
  • Organisator (ik neem aan 1 persoon?)
  • Bezoekers
• Leden in de Promo en Ledenadministratie groepen moeten toegang hebben tot dit rooster.
• Leden van de Promo groep hebben aanmaak, bewerk en verwijder rechten want zij zijn waarschijnlijk verantwoordelijk voor het rooster.
• Verstuur de lijst met aankomende info avonden naar nieuwe leden die zich hebben aangemeld op de website.
• Verstuur elke maand de lijst met aankomende info avonden naar leden die nog niet zijn geweest (niet geactiveerde, niet slapende leden).
• Via deze mail moeten mensen zich kunnen aanmelden voor een specifieke info avond. Ze komen dan bij bezoekers te staan.
• Via deze mail moeten mensen zich ook kunnen uitschrijven van deze mails. Deze leden veranderen we dan naar slapende, anonieme leden?
• Stuur een herinneringsmail na de aanmeld deadline (24 uur van te voren) naar de info avond organisator.
• Mogelijk willen we dan ook een herinneringsmail sturen naar ingeschreven leden / bezoekers?

Open vragen:

1. Kunnen mensen zich voor meerdere info avonden aanmelden?
2. Als iemand een info avond mist wordt hij simpelweg niet geactiveerd neem ik aan?
3. Is er een minimaal aantal aanmeldingen voordat een avond doorgaat?
4. Wat als een info avond niet doorgaat (bijv door te weinig aanmeldingen)?

Ik zou het graag het graag mogelijk maken dat info avond organisatoren kunnen aangeven of een info avond doorgaat of niet, maar dit zou ik graag als volgende stap oppakken.

In sommige lijsten staan leden die geen hoofdletter in hun naam gebruiken onderaan. Bijv:
https://leden.vokoutrecht.nl/ordering/admin/round/142/product_orders/
https://leden.vokoutrecht.nl/ordering/admin/round/141/correction/

Op deze lijst staan ze wel goed gesorteerd:
https://leden.vokoutrecht.nl/ordering/admin/round/141/user_orders/

Daarnaast nog een andere wegsite-gerelateerde vraag: er zijn twee leden die hun namen niet met hoofdletters maar kleine letters hebben gespeld, die daardoor onderaan de lijst komen te staan, dat heeft afgelopen week geleid tot verwarring omdat Lara Sibbing onderaan een bestellijst stond, daardoor op pagina 2 van de geprinte pagina is komen te staan die over het hoofd is gezien en de uitdelers waren in de war omdat haar naam niet onder de L stond. Zou jij die twee namen kunnen aanpassen?
De spelling van namen met kleine letters gaat fout op de lijst ‘bestellingen per product’; https://leden.vokoutrecht.nl/ordering/admin/round/142/product_orders/
Daar zie je bijvoorbeeld bij Peren - Conference (Nieuw Slagmaat) dat Lara en Martine onderaan staan.

When starting, visiting and login in for the first time I get the following error:

RuntimeError at /accounts/overview/
Nog geen bestelronde aangemaakt!

Now that all members of the VOKO are expected to help out with Transport it's much more important to send out a informative reminder every 2 weeks. Currently this is done manually by the transport coordinators.
I'd like us to keep doing this manually, making sure we figure out how this should work, but in the future I'd like to automate this. Some thoughts on how this could be accomplished:
Because we need to send mails to whomever does the Transport that week, we'll need to do the Transport scheduling on leden.vokoutrecht.nl. I was thinking we could make a lists or rides, storing per ride:

• Date or link to order round
• Route: A / B / A+B
• Driver: Link to profile
• Co-driver: Link to profile

We'll need to create a new page for people to view the schedule. This is might be difficult if people haven't allowed sharing their contact information and if that means we can't show people's names.
Update: To limit contact information sharing we could only show members their rides and the contact information of the members relevant for those rides.

We need a way for Transport coordinators to edit the schedule. Not sure if we can/should use the /admin page for that.
Update: We'll try using the admin first.

We'll need to make sure Transport coordinators have schedule edit rights.

With this we should have enough information to, after the order round is closed automatically send out an email to all drivers and co-drivers of that round with information like:

• Some basics,
• Link to transport manual (http://vokoutrecht.nl/transport/)
• Contact information of drivers and co-drivers. I'm not sure if we can do this if people haven't allowed sharing their contact information.
• Contact information of relevant coordinators.
• Link to order lists of round
• I'm not sure how members should get access to contact information of our farmers / suppliers. See: #13. Currently we've shared a link to a google spreadsheet on https://leden.vokoutrecht.nl/docs/)

Open questions:

1. How should members get access to contact information of our farmers / suppliers? See: #13. Currently we've shared a link to a google spreadsheet on https://leden.vokoutrecht.nl/docs/)
2. What can we include in the emails if members didn't allow sharing their contact information?
3. Can we include names in the schedule if members didn't allow sharing their contact information?
4. Can we use the /admin pages for schedule editing or do we need to create pages for that?

Members with administrative functions need to be able to view user accounts and change user account roles. However because they have access to the user object in Django's admin, they can give themselves superuser access.

I've come to understand that the distribution (uitdeel) coordinators of specific rides also need access to contact information of drivers.

The simplest solution for now is probably to add a distribution coordinator field to Ride.

Currently per Ride (usually 1 or 2 per Order round) there can be multiple transport coordinators. We've come to the realization however that there is usually one coordinator in general.

I don't think we can simply use the account groups logic to determine the transport coordinator because they are also used to give people permissions. So in my opinion the best compromise is to define one transport coordinator per order round, just like the distribution coordinator. This means one less field to fill in and because there can be only one the field will be easier to use.
One benefit is that this works great when someone else takes over temporarily.

Wanneer we de correcties hebben ingevoerd sturen we een mail naar info@voko met een overzicht van wat niet geleverd is én een mail naar iedere boer waarvan producten niet geleverd zijn. Dit is best een tijdsintensief klusje. Zou het mogelijk zijn om dit te automatiseren? We voeren immers al alle correcties in het systeem in, wat er niet geleverd is is bekend, en de rest van de mail is altijd een standaard tekstje.

Op het moment zijn er een aantal taken waarvoor de leden administratie de informatie op de leden pagina met de hand selecteren, kopiëren en dan plakken in een excel sheet. Dit gaat snel fout, de wel/niet kolommen komen niet goed mee etc.

Mogelijk kunnen we een nieuw api endpoint toevoegen of mogelijk bestaat er iets in Django waarmee we die admin tabel makkelijk kunnen exporteren?

The csv files that the API creates are "broken", they don't consistently use the same columns. I assume because the data it uses doesn't always have all fields. Mostly because that makes sense for the JSON files.

In the code we refer to email templates by their id's which are generated when the templates are created. To make sure we can alter this without having to touch the code we'd like to move all of them to "constance".
This is used by https://github.com/jazzband/django-constance to make them editable from the admin settings.

In the past only the people responsible for the ordering administration would create OrderRounds. But with the recent changes also the Transport scheduler will need to be able to create them as well. I'm afraid this might get mixed up and we'll end up with Ride pages without orders information.

How should users be added?
When I use /admin/accounts/vokouser/add/ I always get a Herstel de fouten hieronder. error, sometimes without specific errors shown below. Even when I fill in all fields.

The page also mentions:

Vul allereerst een gebruikersnaam en wachtwoord in. Vervolgens kunt u de andere opties instellen.

Which are two fields I don't see in this form.

When members that are scheduled in for example the transport or distribution schedule quit the VOKO it would be great if we could automatically notify the relevant coordinators.

Currently on our public vokoutrecht website we have added an image that links to the registration form:
https://vokoutrecht.nl/meedoen/

UX wise I'd like to move this form to vokoutrecht.nl, but this requires sending a post request to leden.vokoutrecht.nl. But seeing that hidden csrfmiddlewaretoken in the registration form I'm afraid that won't be easy.
Right?

I'd like to see the form at least inlined, using an iframe.

Met het nieuwe transport systeem zien mensen op de rit pagina meteen al de relevante bestel informatie. Ze hebben daarom geen rechten meer nodig tot de volledige bestellijsten. Het zou goed zijn om hun rechten daarom te beperken.
@rikva Ik heb niet de rechten om te zien wat de rechten zijn van groepen of om deze te bewerken. Kun jij dit oppakken?

We don't yet check if the user that we send reminder mails to is still active / not sleeping / not anonymized. Apparently we recently send a mail to [email protected] which failed.

We send these mails from for example the transport and distribution schedules.

Op het moment moeten de mensen die de infoavonden organiseren contact opnemen met leden administratie om leden op een kunnen zichzelf activeren (can activate) stand te laten zetten.

Is dit iets dat we infoavonden organisatoren zelf kunnen laten doen?
Liefst met beperkte toegang tot de leden lijst.

Wanneer we #64 voltooit hebben hebben we een pagina per info avond. Via deze pagina zou ik het mogelijk willen maken om leden van het Promo team individuele bezoekers te activeren.

• Email reminder to drivers and codrivers when order round is closed (PR: #33)
• Email earlier reminder. Maybe before the preceding route reminding them to pick up key? (PR: #41)

These mails should include ride information and or link to the online ride page.

Update: we should send these from [email protected]

De versie van Django die we gebruiken heeft sinds deze maand geen support meer en security problemen worden niet meer (officieel) gefixt. Versie 2.2 wordt tot in 2022 onderhouden: https://www.djangoproject.com/download/

Van de nieuwste versie 3 is nog geen LTS versie beschikbaar. Het upgrade pad zal toch zijn 1.11 => 2.2 => 3.x, dus laten we eerst 2.2 doen.

Currently there are a few issues with the Ride admin page.

• The OrderRound is only displayed using a number, which probably has no significance to the Ride creator. I'd like to display them using the collect date (PR: #32)
• The users referencing fields (driver, codriver, coordinator) are not sorted alphabetically. (PR: #31)
• The users lists are quite large, if not to hard I'd love to add some kind of search / filter functionality. Ideally for the driver and codriver a dropdown with a filter.

@rikva do you have advice on this? I found the documentation a bit confusing on this. I think adding a custom form for Ride's would be more work, especially because then I'd also like to do that for the Route's etc.

De ledenadministratie kijkt na elke bestel ronde wie contributie heeft betaald en gebruikt die lijst om mensen te benaderen over een indeling in een team. Hierbij kijken ze naar de voorkeuren die ze bij het voltooien van hun account hebben ingevuld.
Kunnen we deze handeling makkelijker maken?

Op het moment gebruiken ze daarvoor bijv. de volgende bestellingen pagina waar ze dan zoeken op "Ledenbijdrage".
https://leden.vokoutrecht.nl/ordering/admin/round/117/user_orders/

Willen we dit perse per bestelronde inzien of kunnen we beter 1 pagina maken met leden die nog niet ingedeeld zijn (mogelijk verdeeld per bestel ronde)?

Mogelijk kunnen we hier een algemenere leden administratie pagina van maken waar ze makkelijk meer informatie kunnen inzien waarvoor ze de ledenlijsten naar excel exporteren?

Beside the Transport schedule the other piece of information that's currently shared using a Google spreadsheet (see link on https://leden.vokoutrecht.nl/docs/) is supplier information. Things like:

• Name
• Name contact person (sensitive)
• Phone number(s) (sensitive)
• Email (sensitive)
• Address
• Advice on how many crates to bring and whether to bring cooler
• Extra information (sensitive)

Currently suppliers are already included in leden.vokoutrecht.nl, but we'll need to add extra fields:

• Name contact person
• Phone number(s)
• Free form transport information field (I think advice on how many crates to bring etc could also be included in this)

We'll need a way for members to access this information, probably a new page.

If we have this information it could even be added automatically in the reminders (see #12).

Het aangeboden hoeveelheid producten wordt overschreden tijdens bestellen?

Goede avond,

Dank voor de bestelling. Ik hoop dat het gaat lukken met de
hoeveelheden. Van een aantal producten die besteld zijn heb ik minder
aangeboden dan dat jullie bestellen. Dat is niet de eerste keer dat
dit gebeurt. Zouden jullie daar op willen letten? Bijvoorbeeld de
tuinbonen, max 10 geef ik aan. En nu is er 11 x besteld, de doperwten
ook max 6 Ingevuld en 7 besteld.
Dat is toch bijzonder. Hebben jullie enig idee hoe dat kan en in het
vervolg voorkomen kan worden?

Hartelijke groet,

x
Food for good
Stichting de Wending

Probably caused by: #88
The field probably isn't optional.

For some automated mails it makes sense to send them from a different email address. For example the transport reminders could be send from [email protected] or [email protected]
This way replies automaticly reaches the right people.

Selecting an already used contact person group gives an error.

IntegrityError at /accounts/profile/
UNIQUE constraint failed: accounts_userprofile.contact_person_id

Probably has to do with OneToOneField logic.

Op de leden administratie pagina hebben we een Groups kolom met daarin, per lid, afkortingen van alle groepen waar zij in zitten.
Het lijkt er echter op dat Transport en Transportcoordinatoren allebei afgekort worden tot TRA. Hetzelfde doet zich voor bij Uitdeel en Uitdeelcoordinatoren wat afgekort wordt tot UIT.

Een eerste stap naar #106 is om het correcties overzicht te verbeteren.

Correctie pagina voor bestelronde #141:
https://leden.vokoutrecht.nl/ordering/admin/round/141/correction/

Verzoek:

Op zich is het al handig dat de pagina met correcties een overzicht geeft van alle correcties, maar wat ik er nog niet zo handig aan vind (voor het versturen van de mails althans) is dat de correcties niet worden gegroepeerd per boer en ook niet per product. Dus in het voorbeeld dat jij stuurt staat bijvoorbeeld Walnoten verspreid over de lijst. Het zien van namen van leden waarbij de correcties zijn doorgevoerd is handig voor tijdens het invoeren van correcties maar maakt voor het sturen van de mails dan weer niets uit. Dus eigenlijk zou ik dan een overzicht willen waar zou staan

Nieuw Slagmaat:
21x Walnoten

Geertjes Hoeve:
3x Chevron worstjes

Food4Good:
4x Winterpostelein (of dan zou het misschien 65% van 6x Winterpostelein zijn)

Ik besef me nu bij het maken van bovenstaande lijst dat we dus soms ook minder geleverd krijgen en dat leden een percentage van de bestelling krijgen en dus een deel van hun geld terug, maar dat niet altijd in de beschrijving staat hoeveel gram/kilo een portie is, dus dat dat voor jou moeilijk te programmeren is.

Leverancier belasten staat erin omdat het ook kan dat we bij uitdeel iets kapot maken/laten vallen en dan vergoedt VOKO het zelf en wordt de boer niet belast. Maar dat heb ik nog nooit meegemaakt.

Voorbeeld van een email:

Subject: VOKO ronde 141

Beste [contact persoon Geertjes hoeve],

De volgende producten zijn afgelopen ronde niet geleverd:

• 5x eieren 10 stuks
• Chevron worstjes
• Chevron saucijsjes

Klopt dit met jouw administratie?

vriendelijke groeten,
Florentine

Relevante template: https://github.com/rikva/voko/blob/master/webapp/templates/ordering/admin/correction.html
Relevante view: https://github.com/rikva/voko/blob/26ce27e38eab5431a85f45d2bd485f1d24ce0789/webapp/ordering/admin_views.py#L170-L211

Het zou goed zijn om ook het uitdeelrooster te automatiseren. Dit zou het leven van de coordinatoren makkelijker maken en de coordinator rol daarbij toegankelijker maken. Het kan hopelijk ook helpen om het uitdeel team van betere informatie te voorzien en de ervaring consistenter te maken.

Ik ben niet goed op de hoogte van hoe het uitdeel team werkt, maar ik kan me voorstellen dat we zoiets nodig hebben:

• Per bestel ronde zijn er meerdere diensten (shifts)
• Per dienst moeten er 1 of meer leden ingeroosterd worden.
• Ingeroosterde leden hebben toegang nodig tot de volgende informatie per ronde:
  • Contact informatie van:
    • Alle leden die die dag zijn ingeroosterd, op alle diensten. Dit maakt mogelijk dat ze met elkaar kunnen communiceren.
    • Uitdeel coordinator
    • Rijder + bijrijder die sleutels moeten ophalen
    • Leveranciers die producten hebben aangeboden (of gaat dit contact via boeren team?) (Florentine: hoogstens voor de uitdeelcoordinator)
  • Informatie van bestellingen of gebruiken ze daarvoor de uitgeprinte informatie? (Florentine: uitgeprinte informatie)
• Ingeroosterde leden krijgen een herinneringen per mail:
  1. Iets van 2 weken voor uitdeel dag?
  2. Een paar dagen voor uitdeel dag? (Eva: zondag) (Florentine: maandag). Update: De mail wordt nu gestuurd bij het openen van de bestel ronde, wat op het moment neerkomt op zondag 12:00.

Leden van het uitdeel team kunnen de dagen inzien dat zij zelf zijn ingeroosterd, de coordinatoren kunnen het hele rooster inzien en bewerken.

ToDo

• Data modellen #72
• Views #72
• Links #72
• Volgende bijrijders die sleutels moeten ophalen #72
• Toon informatie van leden van alle shifts voor die ronde #72
• Herinnerings email #72

Uit notulen ALV 2019:

Voorstel van admin:
Omdat we in het verleden hebben meegemaakt dat actieve leden niet meer op vragen van ons reageerden, willen we een voorstel doen voor een toevoeging aan het reglement. Dit om te voorkomen dat inactieve leden op onze lijsten blijven staan, alleen omdat ze niet meer reageren op onze vragen.
Voorgestelde toevoeging:

Wanneer een lid niet reageert op vragen vanuit VOKO die te maken hebben met het de werking van het collectief en/of het lidmaatschap (zoals over deelname aan een werkgroep of manier van uitschrijving) kan het betreffende lid worden uitgeschreven. Wanneer reageert iemand niet: wanneer er minimaal twee herinneringen gestuurd zijn en een laatste bericht waaruit duidelijk wordt dat er zonder tegenbericht wordt overgegaan op uitschrijving. Er wordt minimaal vier weken reageertijd gegeven per bericht. Wanneer we overgaan tot gedwongen uitschrijving wordt het betreffende lid definitief uitgeschreven en vervalt eventueel openstaand krediet.

Currently the Distribution coordinator field is required even though the team that creates the OrderRounds might not know of the distribution schedule. The field should be optional so that it can be filled in later on by the person responsible for the schedule.

One of the things that came up in the last ALV was that members sometimes lack contact info of coordinators.

We hebben in 2019 meer transport kosten gemaakt. Dit heeft waarschijnlijk te maken met dat nu meer mensen helpen met transport en leden vaker auto's huren.

Om het uitlenen van auto's binnen de VOKO te stimuleren willen we graag een lijst bijhouden van auto's die geleend kunnen worden. Omdat we hier waarschijnlijk contact gegevens bij moeten zetten is deze idealiter alleen toegankelijk voor leden.

Currently when I'm a codriver for transport I have to manually check the travel times and calculate when approximately we'll be at each supplier. I'd love to have this automated.
This requires:

• Start time.
• Time to collect products at each farmer (defaulting to 10 min).
• Travel time in between each supplier. Preferably pre-calculated?
• Using the defined Routes and the Orders to figure out which farmers need to be visited.

We might be able to use this in the future to email suppliers.

Pre-calculating travel times

I'm hoping we can create 2 dimensional array to store all travel times between each supplier. This is needed because we have to skip suppliers that don't have orders.
Hopefully we can use an API (from something like Google Maps) to fill in the data automatically.
We'd need to include the start and end points as well, which is probably always Cafe Averechts.

Currently the ordering page is build using a big table. This makes it basically impossible to properly scale on smaller devices like mobile phones. I don't think we should simply hide columns.

The only solution I see is rewriting this screen into something where we can layout the information differently. Maybe something like:

We could try doing this with the current DataTable system, by combining multiple pieces of information in one column. We could move the description behind a open button, like shown on: https://datatables.net/.
Otherwise we'll need to re-implement a lot of things like filters on category and pagination we got for free by using the existing DataTable plugin.

Let's figure out what we need to do to stay inside the GDPR.
I understand that a large part is describing specifically what information we need and what it is used for.
Things to improve:

• Include that we use contact information to organize Transport and how we use it.
• Include that we ask whether members have a drivers license and why we use this.
• Include these free form questions we ask new members?

  1. Geef in een top drie aan in welke werkgroepen je voorkeur hebben (1=leukst):

  • Administratie
  • Contact Boeren
  • Techniek (IT)
  • Transport (woensdag overdag)
  • Uitdeelgroep (woensdagavond)

  2. Op welke dagdelen ben je beschikbaar voor VOKO activiteiten?
  3. Beschik je over een auto(bus), bakfiets of ander voertuig waarmee producten kunnen worden opgehaald? Heb je talenten die van pas komen binnen VOKO? Of wil je nog iets kwijt?

We might need to be clearer on sleeping members.
Shouldn't we prevent these users from having access to the members site?
Shouldn't we remove their data after a while, maybe unless they have a open credit?

So when we clearly explain the goals having a public members list probably isn't an issue. When we implement Transport scheduling #12 we could limit this further, only showing contact information of people involved with the drives you have to make for example.
We could then also remove the list and make members available though search, this makes it harder for people to copy the complete list.

The printable order lists for the distribution team are designed to work in all modern browsers but it has never worked really well. As a result paper is wasted because orders don't always fit on one page. Additionally this is annoying for the distribution team.

I'd like to be able to get some more information out of the system so we can analyze how we're doing. Being able to answer for example:

• How many orders are made per round? Is it increasing or decreasing?
• How many active members do we have? Are we growing?
• How many sleeping members do we have?
• Of people registering an account, how many are activated and of those how many order? Is that improving? (Cohort analysis)
• What's the history of our markup?
• Are we doing many corrections per round? Is that changing?
• What's the trend in how many suppliers we have per round?
• What percentage of members is ordering?

This has to be done in a anonymous way. The data should also only be available to members.

I think we can get a lot of answers with some basic information on the order rounds history and anonymous members information.

ToDo:

• Create API
• Create basic dashboard
• Track can activate state (people who are accepted after info evening, but haven't finished account yet).
  • Can activate date?
• Handle members who leave properly (inform with member administration)
• Retrieve correct sleeping members information
  • is there a sleeping start date?
• Show information about teams
• Integrate dashboard into members site
• Retrieve and visualize data that farmers team is interested in

Not sure what is going on but something is going wrong with the new order round accounts info. It should list members who, during the specific order round have paid the members pee (which should give us a list of new members).

The current way to retrieve these new members is to search for "Ledenbijdrage bij eerste bestelling" on the user orders page. For example round 121:
https://leden.vokoutrecht.nl/ordering/admin/round/121/user_orders/
Gives one name, but the matching accounts info lists that user + some other users:
https://leden.vokoutrecht.nl/ordering/admin/round/121/accounts/

The following examples even list different people, while there where no new members.

• https://leden.vokoutrecht.nl/ordering/admin/round/122/accounts/ (compare with: user orders)
• https://leden.vokoutrecht.nl/ordering/admin/round/123/accounts/ (compare with: user orders)

PR that added this functionality: #79

Case: User "Jane" has filled in his/her last name as "Doe, van", containing a comma.
Mail server does not like this.

/var/log/mail.log.1:Jun 20 08:49:53 voko postfix/smtpd[6126]: NOQUEUE: reject: RCPT from localhost[::1]: 550 5.1.1 <=?utf-8?q?Jane?=>: Recipient address rejected: User unknown in local recipient table; from=<[email protected]> to=<=?utf-8?q?Jane?=> proto=ESMTP helo=<voko.colo.transip.net>

Bij de afgelopen ALV werdt duidelijk dat 1 van de irritante taken van uitdeel coördinators is dat de correcties doorgegeven moeten worden. We willen daarom proberen of de personen die de late dienst doen dit misschien kunnen overnemen.

• Is dat mogelijk?
• Wat voor rechten komen daarbij kijken?
• Is het handig om daarvoor een correctionsteam / distributionAdmin / ... rol te maken ?

Om coordinatoren te laten coordinatoren hebben ze vaak contact informatie van de leden in hun team nodig. Op het moment wordt dit soms gedaan via externe lijsten die handmatig bijgehouden moeten worden.
Ook wilt leden administratie aan coordinatoren kunnen vragen of de lijst nog steeds correct is of dat leden bijv. overgestapt zijn naar een ander team.
Mogelijk kunnen we coordinatoren de contact informatie laten zien van alle leden in hun team?
Mogelijk kan dit gebeuren op dezelfde pagina als: #60?

Het financiële team moet na elke transport ronde, wanneer rijders dit nog niet zelf hebben opgestuurd vragen naar de hoeveelheid km die ze hebben gereden. Hiervoor gebruikte ze tot voor kort de /admin/accounts/vokouser/ pagina.

Eigenlijk zou het handiger zijn als ze deze informatie direct uit het transport rooster zouden kunnen halen. Deze lijst is namelijk altijd up to date en zo worden ook de contact gegevens van minder leden beschikbaar gesteld.
Leden van het financiële team hebben de Admin rol, dus mogelijk kunnen we aan deze rol in het algemeen alle transport rondes beschikbaar maken.

Om de uitdeel coordinator te ontlasten willen we het mogelijk maken dat andere mensen in het uitdeel team ook de bestellingen kunnen bereiken en afdrukken.
Ik neem aan dat dit gaat om Ledenbestellingen (voorbeeld)

Wat stappen:

• De bestellijst per product en per lid ook toegankelijk maken voor mensen in het uitdeel team`.
• Een link toevoegen aan de uitdeel dienst info pagina.

Idealiter kunnen mensen alleen bij de bestellijsten die relevant voor hun dienst zijn, maar mensen zouden dan handmatig de juiste url moeten uitvinden.

While trying to use this project locally I keep running into this error when calling ./runtests.sh.

.../voko/webapp$ ./runtests.sh
Traceback (most recent call last):
  File "manage.py", line 8, in <module>
    from django.core.management import execute_from_command_line
ImportError: No module named django.core.management

I've gone though the steps mentioned in the readme.
I'm on elementary OS 5.0 Juno which is Built on Ubuntu 18.04 LTS.

What python version is required? Looking at the .travis.yml I'm guessing 3.5?
I've ran alias python=python3 to use python3 (source).

$ python
Python 3.6.7 (default, Oct 22 2018, 11:32:17) 

I've ran the pip3 install command mentioned in .travid.yml. For some reason this stops with a Segmentation fault, but this is after a cleanup step, so I think that's okay.

...
Successfully installed Django-1.10.5 Unipath-1.1 certifi-2018.11.29 chardet-3.0.4 django-bootstrap3-7.0.0 django-braces-1.8.1 django-common-helpers-0.9.2 django-compat-1.0.15 django-constance-2.0.0 django-cron-0.5.0 django-debug-toolbar-1.11 django-extensions-1.6.1 django-hijack-2.0.7 django-nose-1.4.4 django-picklefield-2.0 django-recaptcha-1.0.6 django-tinymce-2.3.0 factory-boy-2.7.0 fake-factory-0.7.4 html2text-2014.9.25 idna-2.7 jdcal-1.4 jsonfield-1.0.3 mock-1.0.1 mollie-api-python-1.4.2 nose-1.3.7 openpyxl-2.1.4 python-dateutil-2.7.5 pytz-2014.7 requests-2.20.1 simplejson-3.8.1 six-1.11.0 sqlparse-0.2.4 unicodecsv-0.14.1 urllib3-1.24.1
Cleaning up...
Segmentation fault

Django seems to be installed successfully:

$ python
Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print(django.get_version())
1.10.5
>>> 

Some tips would be appreciated.

For the VOKO a active member is an account that has payed at least one order, which also means they payed their contribution.

We have a few couples where we partly see them as one member, they payed one contribution, frequently one of them contributes, but they have 2 accounts.

This means one of them payed the contribution and performs orders, meaning we see this account as a real member, but we don't really see the other account as a valid member.

How could we properly handle this? Without asking people to pay the contribution twice?