Thursday, May 19, 2016

About duplicate tickets

I knew that #904 is a duplicate of some previously entered ticket. Now I did found it: #100. So I set the duplicate_of field #904 to #100.

What about the state field? #100 is Sleeping and #904 is ToDo. Shouldn’t the state of a duplicate become automatically that of the duplicated ticket? At least in this case I prefer to leave their states separate. Because some long time ago, with Mathieu, we agreed that this ticket can go to Sleeping. But the fact that Aurélie reported it again means that we should talk about it. And even before talking with her, I’d like to have a look at the code in order to estimate whether it is difficult or not.

Wouldn’t it be preferrable to replace the duplicate_of field by a LinkType “Dduplicated/Duplicated by”? No. We had this before and preferred the field because a field is at least one click less, and because we want users to define a clear hiearchy with a clear root ticket. You can have a group of tickets which are all direct or indirect duplicates of this “root of all other problems”.

A new ticket state

I added a new ticket state testing. During the last weeks I had several situations where this state would have been useful.

Lino Voga

After a two hours voice meeting with Alexa I did half a dozen of rather subtle changes for Lino Voga:

  • cancelled calendar events should not cause a conflict

  • Invoices generated by an invoicing.Plan were missingthe author.

  • item_descrption no longer shows planned events earlier than start_date

  • Insert the word “Renewal” (Verlängerung) for renewal invoices.

  • get_enrolment_info for lino_voga.projects.voga2 wasn’t shown

Some optimizations around checkdata

When I run checkdata with the --list open, I get a traceback ending as follows:

File "lino/modlib/plausibility/management/commands/checkdata.py", line 86, in handle
    Checkers.show()
AttributeError: type object 'Checkers' has no attribute 'show'

New tested documents Checking for data problems in Lino Voga and Checking for data problems in Lino Welfare

I changed the way a Checkker defines its internal name: just app_label.ClassName, not the full Python name. Consequence is that all applications must skip the checkdata.Message table when migrating existing data.