Wednesday, December 5, 2018

I am still working on our new cooperation directives.. Here is an example of the topics I need to consider.

Last Friday I did the final sprint for 18.11.1 (2018-11-30). Of course these changes caused a series of failures on travis. No problem, but this sprint had been several very intensive days for me, and it was clear that the dirty and less urgent work of adapting the test suite had to wait. Only now I find time to care for these failures. At least one of them (L4727) indicates that my change potentially introduced a changed behaviour in Lino Welfare. Why does lino_xl.lib.notes.NotesStaff cause a different result in The Lino Welfare Standard User Types?

But stop! Who is going to pay for this work? Who should pay for it? The work of adapting the test suites is less fun and the customer sees no immediate benefit, but it is required for maintaining the quality of the framework.

Because I made the work of repairing the test suite only after the release, the customer will have difficulties to pay me for this work. If I had done it before* the release, the release would have been done only now, the customer may grumble about my slowness but would (if they are of good will) accept that this work is needed.

But let’s work on this and later continue to think about our question.

So the user types 110, 120 and 420 in Lino Welfare now have the additional permission lino_xl.lib.notes.NotesStaff. This has to do with the fact that the new role NotesStaff was required for Lino Tera because a secretary in Tera should not see notes even though they are staff for other plugins. So it is normal that users 110, 120 and 420 in welfare (who were OfficeStaff before) now also need the NotesStaff role. Which confirms that I just need to adapt the test case.

Note that this failure was in welfare, another test suite than tera. IOW one customer asked for a change which caused an API change in the XL, and that API change caused work for another customer.

Other failures on Travis were in the test suite for tera. So they were caused by changes for which the customer asked me (indirectly). One of these changes was an optimization of the grid layout for lino_tera.lib.products.Products. Also here the customer might grumble and say “I didn’t ask for that concrete change”. Indeed it was my “intuitive” decision to remove the category from their product configuration. I removed it because the category is indeed not used anymore in Tera and it would cause misunderstandings and increased need for support to leave it there.

Another failure was because lino_xl.lib.cal.GuestRole now has a new field lino_tera.lib.cal.GuestRole.is_teacher. They need this because presences of a teacher must not get invoiced. I had to find back 394ab28c in order to remember this explanation.

Another change I did on Friday (ca51d871): courses.Course has two new fields: modified and tariff. Both changes were needed for a change the customer can understand: dossiers are now sorted by date of last modification.

And the new field tariff is caused by their invoicing rules. Note en passant that courses.Course already had a field named tariff which contained data imported from TIM. I renamed that field to partner_tariff. Also lino_tera.lib.courses.Enrolment has the new field tariff.

They now have two tariffs in they demo database: “every event” and “max. 10 events”. This is in order to explore and fix and cover a bug with lino_xl.lib.invoicing.Tariff.max_asset where I said min instead of max in the

I renamed prepayment_product to cash_daybook.

A side effect in Lino Così: the menu items for configuring Products and Product Categories* are no longer in the user menu but in the config menu. Since there are no production users of Lino Così I can decide that this is okay. And Lino Così must now explicitly set menu_group for products to sales, not products.

I changed the test dumps in lydia: removed 18.8.0 because it was now failing because of the new tariff field. Getting the import from 18.8.0 to pass would require me to write a migrator. But that would be overkill since I know that there is no production site of Tera 18.8.0 out there.

The above shows that the work of a developer during a sprint is very complex, and documenting it as detailed as I did now takes more time than actually doing it. Yes, documenting every change is important because only then can others participate in my decisions. The question is: do they want this? I am sure that neither Olivier nor Annabell want to dive into these questions as deeply. Gerd in the past sometimes did for fun and because he is curious. And he happened to give valuable commentsfeedback on such thoughts. But does Annabell want him to waste his time on such technical things? Rather not.

A customer does not want to see the gory details. They want to see how much time I needed per change request. They ask for explanations only if one of their request takes more time than hey think acceptable.

Another problem for which I cannot ask anybody to pay because it was caused by my decision to split the “Lino devclopers guide” from the “Lino manual”: build docs for patrols, logos, algus were failing because of changed intersphinx_mapping.

En passant, while fixing this problem I also fixed two more test failures which were a side effect of the changes made for Tera: Voga also must define its own ProductTypes and set the menu_group for products to sales.

Changements Welfare Chatelet

I had a meeting with Mathieu about #2687 and then started to work on it. Release notes Welfare FR Lino Welfare « Châtelet » 18.12.0 (2018-12-15).