Friday, September 20, 2019

Amici removes participants of my meeting

I continued working on #3210 (Amici removes participants of my meeting).

To reproduce the problem:

  • runserver in lino_amici.projects.herman and sign in as robin.

  • create calendar entry, leave it in draft mode

  • enter a guest. Lino accepts it.

  • Hit the Save button of the calendar entry. Poof the participant is gone!

This is because in other circumstances we want this behaviour: Lino should automatically keep the list of participants synchronized with the “suggested guests” for this meeting. For example in Lino Avanti when we have a course with participants (enrolments), and we have generated a series of calendar entries having their suggested guests filled already, and now one participant cancels their enrolment. We want Lino to update all participants of meetings that are still in draft state. The issue is that Lino doesn’t correctly differentiate between those two situations:

  • manually enter and manage the list of guests

  • fill guests automatically and keep it synchronized with the guests suggested by the entry generator.

Lino should no longer let me manually create a guest when the event is in “fill guests” mode.

The Event.update_guests action is always called in the Event.after_ui_save() method. That’s okay, but in our case the action obviously comes to the conclusion that we do want to update our guests. More precisely the event state obviously has EntryState.edit_guests set to False, and the entry type has fill_presences set to True. The solution is to simply set

Summary of changes:

  • New method Event.can_edit_guests_manually() which encapsulates this condition. That method is now also used to decide whether presences of a calendar entry can be manually created or deleted.

  • Changed “Edit participants” to “Fill guests” (in EntryStates)

  • Renamed EntryState.edit_guests to EntryState.fill_guests

  • Changed the EntryState.fill_guests for EntryStates.took_place from True to False. Not sure whether this is good. To be observed. Maybe this is application specific.

  • Changed the default value for EventType.fill_presences from True to False.

  • The demo2 fixture for lino_xl.lib.cal no longer relies on is_appointment and fill_presences to select the “Absences” entry type.

Note the difference between “guest” and “presence”. The model name is currently still cal.Guest, but this should be renamed to cal.Presence. Because the “guest” is actually the field of a presence which points to the person who is the guest.

Note that the transparence is meant for the responsible user (e.g. in Tera and Avanti). In Presto it should check for availability of the guests (who are actually workers), but this is currently not a requirement.

Note that “appointment” means that other people (external partners or colleagues) are involved and should be informed about schedule changes.

TODO: review the specs, use glossary terms, …

‘DueMovement’ object has no attribute ‘get_detail_action’

Wow, a rather impressing bug has been living under the hood for quite some time: #3211. That was because lino_xl.lib.accounting.DueMovement didn’t inherit from lino.core.fields.TableRow. Some time ago when I introduced TableRow, I thought that it is a reasonable requirement to say that table rows cannot be “just any object” but must inherit from TableRow. DueMovement was already written at that time, and I forgot to converrt it.

I fixed it and did an upgrade on the new demo server.

Changing choicelist values requires data migration

I also decided to pull the new version on prod.rumma. Oops, here I got an exception lino.core.exceptions.UnresolvedChoice: Unresolved value '200' (<class 'str'>) for products.ProductTypes (set Site.strict_choicelist_values to False to ignore this) when running make_snapshot.sh.

I guess that Hamza did not migrate the database when he made an upgrade, otherwise I don’t see how we got there. Fortunately lino.core.site.Site.strict_choicelist_values saved the situation: it accepted to make at least a snapshot. Of course, now when running restore.py, I get the errors Hamza should have gotten:

Abandoning with 5 unsaved instances:
- products.Product {'product_type': ['Value <ProductTypes:200> is not a valid choice.']} (5 object(s) with primary key 5, 6, 7, 8, 9)

To migrate the data correctly after having removed the ProductTypes.services, I have to deactivate the line saying kw.update(product_type=product_type) in the restore.py file:

def create_products_productcat(id, name, product_type, description):
    ...
    # kw.update(product_type=product_type)
    ...
    return products_Category(**kw)

Actually in two places: once in create_products_product() and a second time in create_products_productcat().

A checker to update preview fields

I pulled the newest versions to prod.freunde and verified that #3210 is fixed.

I opened a new #3213 (DataChecker to check/update body_preview). This problem started some days after the last upgrade. It is a side effect of #3110. Wondering why we didn’t see it in Jane.

To fix it, I wrote a new PreviewableChecker. En passant I moved the doctrings from lino.modlib.memo to memo : The memo parser.

Tests

When I run inv prep test in Developer Guide, I sometimes get the following error:

======================================================================
FAIL: test_01 (tests.test_misc.PackagesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/luc/work/book/tests/test_misc.py", line 25, in test_01
    self.run_packages_test(SETUP_INFO['packages'])
  File "/home/luc/work/atelier/atelier/test.py", line 108, in run_packages_test
    self.assertEqual(found_packages, declared_packages)
AssertionError: Lists differ: ['lin[3653 chars]migs.migrations.about', 'lino_book.projects.mi[4677 chars]ies'] != ['lin[3653 chars]migs.settings', 'lino_book.projects.migs.setti[2879 chars]ies']

First differing element 107:
'lino_book.projects.migs.migrations.about'
'lino_book.projects.migs.settings'

First list contains 39 additional elements.
First extra element 188:
'lino_book.projects.nomti'

Diff is 9067 characters long. Set self.maxDiff to None to see it.

It goes away when I run the clean.sh in Django migrations on a Lino site. Seems that the clean.sh sometimes fails to do its work. Strange. I added set -e to make sure that it stops when some error occurs, and I added a line of output in order to make even more sure that it finished.