20130829 (Thursday, 29 August 2013)¶
Appointments and prompt events¶
Worked on the calendar and reception modules.
Integrative work for several user requests:
Some Lino Welfare users don’t want to see prompt events (“visits”)
in their MyEvents table of the welcome screen.
Some other’s won’t even use the reception module and don’t want to
know what a prompt event is.
How to remove in Renamed “Lino Faggio” to “Lino Voga” the useless
EntryStates.scheduled
?
In Events.parameters replaced the “unclear” checkbox by an observed_event combobox which classifies calendar events in either “pending” (i.e. in a state which is not fixed) or “okay” (i.e. in a state which is fixed). But afterwards I removed the MyUnclearEvents table because no user has ever asked for this.
Added new filter parameters calendar and show_appointments.
Moved the definition of EntryStates.scheduled to
lino_xl.lib.cal.workflows.welfare
.While we’re there I removed the EntryStates.rescheduled state. Because I think that this is not needed for Lino Welfare. When an appointment has to be rescheduled they either set it to cancelled and create a new one, or they even reset it and modify the original record.
How to represent “visits” (or better “prompt events”)? They are calendar events whose guest(s) must be received like the guest(s) of any appointment.
Until now I used a special EventState “visit” which was neither pending nor okay. I thought that this is okay because visits are created on the fly and do not participate in the standard calendar workflow. But then the scales fell from my eyes and I understood that they must “just” have their own calendar. And then a new BooleanField Calendar.is_appointment which is False for this calendar, meaning that this calendar’s events are “no real appointments”, iow concretely: that they are not displayed in MyEvents by default.
Renamed EntryStates.scheduled to EntryStates.published. And I believe that for Renamed “Lino Faggio” to “Lino Voga” we will then change our mind and want this state. Also renamed CourseStates.scheduled to CourseStates.published.
Lots of other little optimizations.
Permalink when session is not authenticated¶
Requesting a permalink when the session is not authenticated (e.g. because the server did an initdb_demo meanwhile) now causes the login window to pop up and to automatically reload the permalink upon successful login.
This is convenient in certain development phases, but also interesting for writing documentation with permalinks to the public online demos. For example I can write instructions like the following:
Open here and log in as demo user “robin” with password “1234”), then bla bla bla…
(or click
Code changes:
Added on_login parameter to Lino.show_login_window.
Removed one get_view_permission test in views.py which raised a PermissionDenied because that would redirect to the 404 template. We don’t want that yet here. If the login fails or the user has no right to see that table, then the permalink will simply render an empty screen.
Checkin and upgrade the Online demo sites to the newest development version.