Tuesday, March 1, 2016

Deleting a starred object left the stars with broken GFK “owner”

I had yet another occurence of a problem which I now reported and fixed as #805:

Traceback (most recent call last):
  ...
  File "/lino/lino/core/site.py", line 2935, in get_welcome_messages
    for msg in h(ar):
  File "/lino/lino/modlib/stars/models.py", line 149, in welcome_messages
    for obj in qs])
  File "/lino/lino/core/requests.py", line 711, in obj2html
    return self.renderer.obj2html(self, *args, **kwargs)
  File "/lino/lino/modlib/extjs/ext_renderer.py", line 369, in obj2html
    h = self.instance_handler(ar, obj)
  File "/lino/lino/modlib/extjs/ext_renderer.py", line 357, in instance_handler
    a = obj.get_detail_action(ar)
AttributeError: 'NoneType' object has no attribute 'get_detail_action'

This was disturbing because it caused a blocking Internal Server Error in the welcome page.

I wrote a test case (in lino_noi.projects.team) to reproduce this. The problem was because the controller_is_optional model attribute was being ignored. I created new model method update_controller instead. This feature was used only by lino_xl.lib.stars so far.

Lino now (by default) refuses to delete a starred object.

Vocabulary in Lino Welfare

“Payment instruction” (“Zahlungsanweisung”) becomes “Disbursement order” (“Ausgabeanweisung”)

I started to analyze the different use cases for these documents in TIM.

  • Two new fields item_account and item_remark.

  • Currently we use narration for what they call “Internal reference” (interne Referenz), and remark for their “External reference”.

I removed an assertion in lino.core.inject.update_field() because it seems to be no longer useful after Django 1.8 (and because it gave a false positive) when I try to override the verbose_name for these fields.

invalid literal for int() with base 10: ‘fdpkvcnrfdybhur’

It seems that somebody installed some robot which does a request like this every now and then:

Such requests now just raise a SuspiciousOperation “Invalid value for limit or offset” instead of causing an Internal Server Error.

Which still causes Lino to send me an email each time. For the moment it’s just annoying.

Why do people install such robots? What is their motivation?

Übersicht Journale und Dokumentarten

Ich habe mir mal eine Übersichtstabelle der bestehenden Journalgruppen und Dokumentarten gemacht, wobei ich meine Aufmerksamkeit auf folgende Felder lenke (in Klammern die Feldbezeichnungen in Lino):

  • A = Haushaltsartikel (account)

  • NB1 = Gegenstand (narration)

  • NB2 = Externe Referenz (your_ref)

  • P1 = Partner. Der Sozialhilfeempfänger, um den es geht. (project)

  • P2 = Empfänger. Optionaler Zahlungsempfänger falls Zahlung an einen Dritten geht. (partner)

Was mich interessiert, ist, wie diese Felder verteilt sind zwischen “oben” (IMP) und “unten” (IML), was seinerseits in TIM durch die Bildschirmansicht (View) definiert ist.

Außerdem die Attribute P (“Partner auswählen beim Erstellen”) und B (“HH-Artikel auswählen beim Erstellen”).

Journalgruppe

P

B

View

Felder IMP

Felder IML

Lino database model

Bestellung

P

BST

P1, P2, NB1, NB2

A, NB1

vatless.ProjectInvoice

Rechnungseingang

P

REG

P1, P2, NB1, NB2

A, NB1

vatless.ProjectInvoice

Forderungen

FFO

P1, P2, NB1, NB2

A, NB1

Anweisungen

B

AAW

A, NB1, NB2

P1, P2, NB1, NB2

finan.DisbursementOrder

Zahlungsaufträge

ZAU

NB1, NB2

P1, P2

finan.PaymentOrder

Tresoreriejournale

KAS

P1, P2, NB1, NB2

finan.BankStatement

Haushalt

P

HHB

NB1

A, NB1

finan.JournalEntry

Bemerkungen

  • Bestellungen und Forderungen werden weiter in TIM gemacht (sind keine Sozialhilfeausgaben).

  • Haushalt, Zahlungsaufträge und Tresoreriejournale sind soweit okay

  • bzgl. Rechnungseingang hat Lino zwei Varianten:

    • ProjectInvoicesByJournal (klassische REG) - Der Klient wird im oberen Teil erfasst (maximal ein Klient pro Rechnung).

    • InvoicesByJournal (Sammelrechnungen) : Der Klient wird im unteren Teil (pro Zeile) erfasst