Monday, November 9, 2015

#38 continuing

Hamza and I had another shared session yesterday where we fixed about 6 of the remaining 10 failures. Hamza continued alone afterwards and committed our work to his fork. Now I merged his changes to Lino master.

There were still 2 failures in the Renamed “Lino Faggio” to “Lino Voga” test suite (due to one of our changes for #38)

Multiple products per ticket?

The following thoughts are mainly for #602. While my first reaction after my meeting with Oikos (Johannes) was to write a new application from scratch, I later got the idea that this project is possibly a case for Lino Noi.

The current database structure in Lino Noi has one product per ticket. I am considering to change this into a 1-to-N relation. That is, per ticket, instead of having a ForeignKey field which points to a product, we would have a list of “related products” per ticket. Another part of this change would be to add a list of “responsibilities” or “competences” per user. We could then add a filter to be used when assigning new tickets to a user: Lino would suggest only those users who have registered their compentence for the related products of the ticket.

Discussion:

  • alternatively don’t do this with the producs table but add a new table “competences” (“required competences” per ticket and “owned competences” per user).

  • alternatively just add a list of competences per user and leave the one product per ticket rule.

Should we differentiate between “products” and “competences”? Products are currently the things that a given Noi community is “producing”. IOW the software components or modules of the miscellaneous projects. What would be in our (the Lino team’s) list of “Competences” if it was separate?

Competence

Users

Local testing

Gerd, Mathieu

Configuration

Gerd, Mathieu, Luc

Analysis with customer

Gerd, Mathieu, Luc

Code changes

Luc, Hamza

Bugfix

Luc, Hamza

Enhancement

Luc, Hamza

Optimization

Luc, Hamza

Documentation

Luc

Offer

Luc

We can observe that this list is almost identical with our current “ticket types”.

We could rename this field to “Required action”.

Instead of having multiple required actions, we can leave it as it is and get used to the fact that this field may change during the lifecycle of a ticket.

This structure is very similar to what we have in lino_welfare.modlib.newcomers where the “products” or “ticket types” are called “faculties”.

Summary: #602 might be absolutely implementable with minimum effort:

  • add a new plugin lino_noi.lib.faculties with two models “Faculty” and “Competence” as in lino_welfare.modlib.newcomers. Also the tables are similar.

  • Change Ticket.detail_layout : remove the “Waiting for” field (a plain charfield) and replace it by “Faculty required” (a pointer to Faculty).

  • develop workflow and tables for managing the assignment of tickets to users. E.g. a view to help answering the question “Which tickets that are currently assigned to Luc (or to nobody) can be assigned to Hamza?”

  • release these changes to our production site. We will manually populate the faculties table with values as above.

  • Note that we leave the TicketType table unchanged. It might become more useful in the future, e.g. the ticket type might have an influence on price when invoicing.

These changes would be directly interesting for the Lino team.

And later, for Oikos we might need a way to classify these faculties into categories because there might be many of them. (But it’s too early to decide about this)

I created a new ticket #610 for these first changes because they are only a first step of the whole #602 project, and because I plan to leave this first step to Hamza.

#353 (Lino Così)

After my meeting with Danny last week I had a list of things to do for ticket #353. Finally I found some time to start working on these.

Some trivial changes:

  • Lieferart kann weg. We don’t need the ShippingMode, at least not in a basic version. Create a new plugin “delivery” which currently just contains the model and will later contains delivery notes.

  • No discount field per invoice (but only per item)

  • New fields ship_date and ship_ref. These are meant to be filled manually in case of grouped invoices. We decided to not add delivery notes to the database (at least not in a basic version).

This one was less trivial:

  • After selecting the payment term of an invoice, Lino should set the due_date

Thoughts about payment terms

The following are fragments of my thoughts…

We have two mixins PartnerRelated and Payable. Shouldn’t be Payable a subclass of PartnerRelated? Or rather PartnerRelated a subclass of Payable? Are there PartnerRelated models which are not Payable?

Should PaymentTerm work for any trade type? Or should it be reserved for sales? A: no, there are probably users who use it for registering purchase invoices.

There are vouchers which have a due_date and are payable (must get cleared by some other transaction), but their due_date is not computed automatically using a PaymentTerm

There are 3 Payable concrete models: VatAccountInvoice, VatProductInvoice and AccountInvoice.

All of these are also PartnerRelated, but they don’t inherit it directly:

  • VatDocument

    • VatAccountInvoice

    • SalesDocument

      • VatProductInvoice

      • Order

  • AccountInvoice

  • VoucherItem

An order is a VatDocument (and thereby a PartnerRelated), but not a Payable.

An order has a payment_term (as a sales invoice) but is not payable.

Changes

  • Payable now inherits from PartnerRelated

  • VatDocument is no longer PartnerRelated

  • Until now the payment_term field was injected by lino_xl.lib.vat.models, but now this is done by lino_xl.lib.accounting.models.

    A consequence of this is that now also in Lino Welfare all partners have this field. Which is indeed what we want (as far as I can see) : when they start to register purchase invoices, then they will possibly want to give a default payment term per provider. At least in TIM they had this possibility.

  • Moved orders from lino.modlib to lino_cosi.lib (but this plugin is not yet being used)

Changes en passant

tests.DumpTests (#38)

I fixed one of the remaining failures for #38 (an easy one):

$ python setup.py test -s tests.DumpTests
...
test_dump2py (tests.DumpTests) ... FAIL

======================================================================
FAIL: test_dump2py (tests.DumpTests)
----------------------------------------------------------------------
  File "/lino/modlib/lino_startup/management/commands/dump2py.py", line 187, in write_files
    if not getattr(f, '_lino_babel_field', False)])))
AttributeError: 'ManyToOneRel' object has no attribute 'attname'

The explanation was also here that Model.get_fields_with_model() contains also virtual and other special fields in Django 1.7+. There were two places in lino.modlib.lino_startup.management.commands.dump2py where we must remove these special fields:

if AFTER17:
    fields = [f for f in fields if f.concrete]