(Many undocumented changes during the last weeks.)
Instantiatornow supports many-to-many fields. Content of a many-to-many field can now be specified as a string containing a space-separated list of primary keys. Or, if you want to use another field than the primary key for specifying related objects, m2m_field:lookup_field syntax. Examples for both usages are in src/lino/django/songs/fixtures/demo.dpy.
mysites.demo.makedemonow finds the list of installed apps automatically. So I no longer need to change
Row.field_as_readonly()now supports when a value is a
Manager(which is the case when you specify a ManyToManyField).
Classes :class`Singer` and :class`Author` are now subclasses of :class`Person`.
Started Common models
updated my copy of Django from 10618 to 10736
Language and :class`Country` are a first example of
models being used by several applications. They are now defined in
The order of applications in
lino_setup() is called in that order.
- This way of doing has unresolved issues:
cannot make a common class become abstract
cannot remove a menu item or change order of menu items
Added Collection and Places to songs.models. Added sample data in songs/fixtures/demo.dpy.
Instantiator now supports a lookup_field for ForeignKey.
Worked on /lino/modlib/igen/fixtures/demo.dpy.
I noticed that Django’s DateField does no validation and no conversion from string to date.
lino.utils.instantiator.DateConverterHow to parse a datetime.date from a string? The standard Python module has now support at all, even not to parse a simple iso-formatted date. PEP 321 was exactly what I’d need now, but it has been withdrawn… I also read http://mail.python.org/pipermail/python-dev/2004-April/044181.html and http://mail.python.org/pipermail/python-list/2003-November/236842.html
Conclusion: I started by writing a parse_date() myself, then I understood that I also need other things from python-dateutil, so I threw it away and added dateutils to
preparing for field-specific default width in Layouts
removed null=True from string fields after reading http://docs.djangoproject.com/en/dev/ref/models/fields/#null
GRID_CELLto render more than one field in a single grid cell.
igen.models.MakeInvoicesDialog. A Dialog is an enhanced django.forms.Form that can be installed as a menu action. In Module
render: started to split new class ElementServer out of Row because Dialog will need only the ElementServer part of Row.
Order. A contract is just a cyclic Order.
Order.make_invoice(). make_invoice() will have to know when the next billing will occur. And whether a service must be paid for before or afterwards the period. For the moment we simplify by saying that the billing happens once per month.
Pro-rata : the covered period in a generated invoice may be longer or shorter than normal in certain cases.
For example assume that invoices are sent only once a month, for example on the first working day of each month. What should we do if a monthly service order starts at the 28th of a month? Or at the 5th of the month?
Ordershould get a new field, called maybe “Pro-rata”. Definition of “Pro-rata”: see http://en.wikipedia.org/wiki/Pro-rata. For the moment we simplify by saying that the covered period never adapts automatically to the billing cycle.
The new class attributes
reports.Report.excluderefer to the corresponding Django methods to limit a queryset.
Report extensively uses sime class attribut overriding in subclasses. That’s what I want, but it has one disadvantage: typo’s are not detected.
Report.__init__()now tries to detect them. This can be switched off by setting
lino.django.utils.permswith some shortcuts
perms.never(). Trying this on Invoices.can_view = is_staff, Orders.can_view = is_authenticated and InvoicesToSend.can_add = never.
Why did I try to write my own permissions system? because I don’t like the system suggested by
django.contrib.auth. “but it’s not currently possible to say “Mary may change news stories, but only the ones she created herself” or “Mary may only change news stories that have a certain status, publication date or ID.” The latter functionality is something Django developers are currently discussing.” (http://docs.djangoproject.com/en/dev/topics/auth/#permissions)
Some trace of the discussion is here: http://code.djangoproject.com/ticket/3011
My conclusion: don’t insist for the moment on permissions and user management. Make my perms module minimal but usable and use it temporarily until Django has a good solution.
worked on ticket http://code.active.ee:3000/issues/show/337 - added DocItem.discount - added an example in demo
new DecimalConverter in Instantiator. DecimalFields were stored as strings in the database. And Django didn’t complain (maybe simply because I use the sqlite backend which allows such things).
Committed revision 683.
bug in demo.dpy
DocItem.before_save()now always sets
DocItem.total(except when unitPrice or qty is None).
DocItem.total_incl()no longer necessary.
Committed revision 684.
PaymentPerm.months and PaymentTerm.days. It’s not yet clear how igen should decide which type of invoice to generate (normal or proforma).