20110914

Mails

Database change in lino.modlib.mails: there’s only one table Mail, not two separate tables OutMail and InMail.

Job Requests

Tilt! lino.modlib.jobs does not need a PersonsByOffer, but a RequestsByOffer. Entering a Job Offer now gives reasonable results in the “Candidate” slave grid. Added some sectors and functions in dsbe/demo fixture.

Sending Mails

Event instances now also have a “Create Mail” button.

There was a conceptual problem about the setup_report() model method: we cannot use super() in such a method because the ultimate base class of all models, Django’s models.Model class, doesn’t have this method. That’s why I wrote lino.utils.call_on_bases(). setup_report() methods should not call super(), but Lino will call automagically call the setup_report method of all base classes. This also means that you cannot avoid them being called (as would be possible if we could use super())

Deleting Mails

Lino refused to delete a Mail when it had Recipients. You had to delete the Recipients first.

To solve this, we added the magic allow_cascaded_delete() Model attribute.

This is now set to True in the following models:

lino.modlib.uploads.models.Upload

lino.modlib.mails.models.Recipient

lino.modlib.mails.models.Attachment

lino.modlib.links.models.Link

Deleting a row didn’t refresh the grid

The action’s after_success (set to the panel’s after_delete) was never called after a successful DELETE action because the response to DELETE has no response text.

As a result, when do_action now calls after_success, it now no longer passes the result as first parameter (a feature which wasn’t used anyway).

Translations

Upated German and French translation files.

classmethod objects have no im_func in Python 2.6

Mist, mein Trick mit lino.utils.call_on_bases() von heute morgen funktioniert nicht in Python 2.6.

Mal überlegen: was will ich eigentlich? Also ich will, dass man in Models optional eine Klassenmethode namens setup_report definieren kann, die dann von jedem Report mit diesem Model aufgerufen wird. Das ging zunächst ganz gut, aber wenn ich ein Model mit mehreren Basisklassen definiere von denen einige so eine Methode haben, dann musste ich dran denken, dort auch eine setup_report zu schreiben, die das dispatching macht. Z.B. in cal.Guest:

@classmethod
def setup_report(cls,rpt):
    mixins.CachedPrintable.setup_report(rpt)
    Mailable.setup_report(rpt)

super() kann ich nicht benutzen, weil django.db.models.Model keine Methode setup_report hat.

Ich habe noch mit einer lino.utils.call_optional_super() probiert, aber das klappt auch nicht.

Also weiterhin wie bisher: Vorsicht wenn ich ein Modell mit mehreren Mixins definiere: Falls mehr als eine der Basisklassen eine setup_report hat, muss ich auch selber eine setup_report definieren, die die setup_report der Basisklassen aufruft. Wenn ich das nicht mache, wird nur die erstbeste setup_report gerufen. Doof, aber so isses.