Basics | Plugins | Howtos | Applications

Automatic calendar entries¶

A Lino application can generate automatic calendar entries when it has one or several event generators.

Recurrent events.
A course, workshop or activity as used in Lino Welfare, Lino Voga, Lino Tera or Lino Avanti.
A room reservation as used in Lino Voga.
A coaching contract with a client as used in Lino Welfare.

The main difference between automatic calendar entries and other calendar entries is that they have a “controller”, i.e. their field “Controlled by” points to an event generator and that they have a number (the Event.auto_type field).

Configuring your event generators¶

Configure the calendar entry type to use for the generated events.
A start date. This is also the start date of the first generated event.
Optionally an end date if the generated events span more than one day
Optionally a start and end time unless the generated events should be all-day
A date limit and/or a number of events. Lino stops generating events when either the date limit or the number of events is reached.
Recurrency parameters

Guests of generated events¶

An event generator can also control the guests of each generate event.

You must configure the default guest role to use for the presences of generated events.
You must check the fill_guests checkbox.
You must decide whether you want force_guest_state to be on or off.

Lino synchronizes the guest lists of every generated event.

Usage example: In Lino Avanti: create a course with 2 enrolments. Have it generate some lessons. Check that the enrolments have become guests. Manually edit the guest list in one event: add an extra guest. Add one new enrolment and remove one enrolment from the course. Run update_guests on the course. Check whether the guests of the first event have remained unchanged while the second event has received the new guest.

As soon as you edit something in the guest list of a generated event (remove or add guests, or modify something), Lino will stop synchronizing the guest list with the list of enrolments.

Recurrency parameters¶

Concepts¶

event generator¶

A database object that can generate a series of automatic calendar entries.

automatic calendar entry¶

A calendar entry that has been generated by an event generator. See Automatic calendar entries.

recurrent event¶

Something that happens recurrently according to some recurrency rule. For example legal holidays.

You configure them in Configure ‣ Calendar ‣ Recurrent events.

Note that the recurrent events themselves aren’t calendar entries but event generators. The rows in this table are not visible in the calendar, but each of them potentially generates multiple calendar entries.

recurrency rule¶

A rule that specifies how Lino should generate a set of automatic calendar entries.

recurrency policy¶

A database object that represents a named recurrency rule.

relative to Easter¶

A recurrency rule that generates yearly calendar entries that don’t have a fixed day of the year but move together with the Easter day. They are also known as moveable feasts.

Positions¶

The RecurrenceSet.positions field allows to specify rules like “every last Friday of the month”.

If given, it must be a space-separated list of positive or negative integers. Each given integer N means the Nth occurrence inside the frequency period.

The positions field makes sense only when frequency (RecurrenceSet.every_unit) is yearly, monthly, weekly or daily. It is silently ignored with other frequencies. When this field is set, the value of RecurrenceSet.every is ignored.

Rules for generating automatic calendar entries¶

Every event generator has a button, which asks Lino update the calendar entries generated by his generator.
An automatic calendar entry has a controller (the event generator) and a sequence number, which is managed automatically by Lino.
When an automatic calendar entry is to be moved to another date, e.g. because it falls into a vacation period, then you simply change its date. Lino will automatically align all subsequent entries with the new rhythm when you click the button.
When an event has been manually moved to another date, all subsequent events align to the new rhythm, except those which have themselves been manually modified.
When you mark an automatically generated event as “Cancelled”, the cancelled event remains linked to the activity, but no longer participates in the sequencing of generated events because its auto_type is empty. The summary field becomes editable. It behaves like a manually created event that occupies this date. Don’t delete it, otherwise Lino will generate a new event at the same date. More precisely, you may delete it when the following event has been manually edited. Because in that case Lino considers the following event as manually moved and adapts to the new rhythm.
You can manually change the auto_type of a generated calendar entry. When the auto_type of a generated event is empty, the summary field becomes editable and the event remains linked to its activity, but no longer participates in the sequencing.

User stories¶

As an activity manager I have a long-running weekly activity that started years ago. Until now I didn’t use my Lino very much, most meetings are in state suggested, only some of the meetings are actually confirmed (i.e. state is took_place). The weekday of the activity recently changed from Tuesday to Monday. Now I’d like to start recording these meetings more thoroughly: whether they happened and who was there, i.e. the state and presences . I’d like Lino to forget all the old suggestions and to keep only those occasional old meetings for which I happened to record presences. And to generate a new series. I changed the activity’s start_date to 2021-06-28 and the weekday from Tue to Mon, then hit the button. Events are now on Monday, yes, but they start already in December 2020. I said start_date 2021-06-28.

Explanation: when Lino finds a manually modified event, then it takes this event as the start date and ignores the activity’s start_date. This is because when an activity is planned to start on a given date, and the first meeting actually took place later than planned and is manually modified, all following meetings should align after this first meeting.

Change: but above rule –from now on– only applies when the first confirmed lesson is after the start date of the activity.