Friday, February 5, 2016¶
They have some fields on
which are definitively limited to their concrete case.
lino_xl.lib.coursesdefines the Enrolment model with fields like course, pupil, request_date, state, …
lino_voga.lib.coursesdoes not change anything on the Enrolment model
lino_voga.projects.roger.lib.coursesextends the Enrolment model with (currently) one field.
I “activate” this plugin using the following definition on the
def get_apps_modifiers(self, **kw): kw = super(Site, self).get_apps_modifiers(**kw) kw.update(courses='lino_voga.projects.roger.lib.courses') return kw
But now I get the following runtime error:
RuntimeError: Conflicting 'enrolment' models in application 'courses': <class 'lino_xl.lib.courses.models.Enrolment'> and <class 'lino_voga.projects.roger.lib.courses.models.Enrolment'>.
Both model definitions correctly have defined the following Meta class:
class Meta: app_label = 'courses' abstract = dd.is_abstract_model(__name__, 'Enrolment')
Where app_label is required by recent Django versions for some reason which don’t yet fully understand.
is_abstract_model returns False for both
Enrolment models. But the one in
be abstract. That was a bug in Lino, more precisely in the logic
responsible for automatically filling
override_modlib_models at startup. Fixed.
Importing participants to Lino Voga¶
we have now an admin command
eiche2lino which can run as
often as we want.