Mercurial > hg > 7vtr
changeset 15:27cd1a94580f default tip
old notes.txt with design for building an app
author | Henry S. Thompson <ht@inf.ed.ac.uk> |
---|---|
date | Mon, 15 Feb 2021 18:48:50 +0000 |
parents | 05f22e97c660 |
children | |
files | app_notes.txt |
diffstat | 1 files changed, 60 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/app_notes.txt Mon Feb 15 18:48:50 2021 +0000 @@ -0,0 +1,60 @@ +Trial of odoo now running at + http://markup.co.uk:8069/event + +website menu field is for individual event page... + +No obvious support for a recurring event + +Edit this + /usr/lib/python3/dist-packages/odoo/addons/website_event/views/event_templates.xml +to e.g. change 'Register' to 'Request place(s)' + +Hmm. Message goes to registrant, but not to admin... + +Need to find sources... +What would it take to do a priority-to-newcomers queuing system for +7vt MfW? + 1) Database with tables + a) adult, with id, name, email (key), household (fk), headOfHousehold (bool) + b) household, with id, num adults, num children + c) child, with id, name (key1), parent1 (fk), parent2 (fk), household (key2) + d) meeting, with id, date, start, end + e) roomUse, with id, event (fk), room, numAvail (int), numHeldBack (int) + f) request, with id, event (fk), household (fk), numAdults, allOrNone (bool), numChildren, timestamp + g) booking, with id, request (fk), room (fk), accepted (int), turnedUp (int) + 2) Actions/forms + a) Register a household + b) Edit a household + c) Request a booking + d) Show requests/bookings (with expected status for requests, + e.g. currently nth of m for room + e) Cancel a request/booking + f) Make bookings and notify head of household for all requests, + including position on waiting list if not accepted w/o + qualification + g) Notify new winner(s), new waiting list positions, on cancellation + +Doesn't as proposed allow for different categories of children, +i.e. this really only works for meeting room use for All Age, not +breakout rooms yet. + +Do we want to require an acknowledgement? + +Waiting list are allowed to turn up, possibly be admitted at 10 past +to empty places from heldBack and no-shows. + +Priority based on + 1) inverse number of previous attendances + a) with no-shows counting double? + b) with some relief depending on how long ago? + 2) time of request + +I.e. compute a score based on previous attendance, then sort by that +score, lowest first, and within requests with the same scores, by +request time, fill room(s) from the top down. If adding a +larger-than-one household won't fit, if no children and not allOrNone, +accept as many adults as possible. If there's another room, move +remnant if any there, otherwise move to waiting list, along with +everyone thereafter, in order. + +No groups including children on waiting list?