Tuesday, April 21, 2020

(Continued from Monday, April 20, 2020)

That worked, but it didn’t fix my original problem: MarkEventTookPlace now complained that there is no guest state “invited”.

So I leave the default guest state at “invited”, but that’s only the internal name, the verbose name is “Planned” or “Present”. In Presto they want to use something quite similar to the voga workflow, but they really don’t want to have to mark their workers as present or not before marking an entry as “took place”. Marking an entry as took place, in Presto, means that all workers who were planned where present.

We want to inherit from Voga workflows, but we want to remove the MarkEventTookPlace transition. But it’s not possible to undo an add_transition() because the transition action immediately gets quite installed into the system.

To fix this, I added an attribute transition to the lino.core.workflows.State class. This has a side effect: Lino no longer allows to define several transitions for the same target state. If you try this, you get an exception “Tried to add another transition to <state name>”.

There were about 3 cases where this side effect occurred, and I could convert them into normalized transitions.

I removed several workflow modules from the autosummary directives, i.e. they are no longer included in the autodoc API docs. Indeed they are like the models.py modules and choicelists.py modules of a plugin: thy import lino.api.dd at module level and therefore might Django to raise a django.core.exceptions.AppRegistryNotReady exception Apps aren't loaded yet. I just don’t understand why it worked until now.

About ticket dependencies

I have been working now many hours on #3599. We needed this for #3477.

  • #3599 : Develop and install a next version of their software according to their 20 page specifications

  • #3477 : A seemingly minor problem that occurred while working on #3599. I decided that this is an interesting case for the Calendar plugin and maybe even for Lino in general.

Of course this would be difficult to explain to the customer. Of course there are always two basic attitudes when working on a customer request:

  1. fix it using a quick hack, get rid of the problem, do just what they asked, don’t overkill the bug, don’t worry more than needed.

  2. analyze the problem and learn from it, improve the framework or the xl in order to have less work in the future with similar topics.

The normal capitalistic attitude of a customer wants me to prefer (1) in most cases. That’s why it is better to sell software development services with a flat rate price, not with an hourly tariff.

It can be difficult to estimate how much time I had spent on this issue if my goal was just a “quick hack”. A quick hack can take more time than a thorough analysis.

The customer actually is not interested in the details, they just want to have something that shows them that my price is not simple fantasy.

But independently of the sales work we want to know at least internally how things are related, why a given change has been done, how much time it took, etc.

The customer (and we) would like to see in their service report that I also have been working on a #3477 for which they didn’t ask directly but which was indirectly needed for their general request.

I see two possible directions:

  • We might differentiate between “wishes” (customer requests) and “tickets” (tasks to do). During data migration every ticket with a non-empty end_user field would become a wish. A working session would have an additional pointer “wish”. And ticket would become nullable.

  • Or we don’t use a separate Wish model but review the user interface for managing ticket dependencies.

To be meditated.