Tuesday, September 29, 2015¶
Hamza could not reproduce #219 using my instructions, so I checked them for possible misunderstandings and try to formulate them again:
You can reproduce it easily in our Mio or in the public online demo of Noi at http://team.lino-framework.org as follows:
Log in e.g. as “jean” or “robin”
Open the list of tickets using the `[Tickets]` quick link
Click “Create” (“Insert a new record”) button and confirm the dialog window to create a new ticket
In the detail window, in the Workflow panel, click on Confirmed
Note that Lino seems to fail to update the state of your ticket (it remains at New).
Hit ESCAPE to close the window
You can see now that Lino has created your ticket twice instead of only once. The first ticket is Confirmed while the second tcket is New.
If you watch the network traffic using the web console of your browser, then you can see that the click on “Confirmed” caused a HTTP call with method POST. This is the problem. This POST should have been a GET.
This file has been generated by
more precisely by
js_render_custom_action() (I guess).
The link URL (i.e.
generated by Python code in
lino.core.model.Model.workflow_buttons which calls
lino.core.requests.BaseRequest.action_button() which calls
calls a myriad of rather chaotic methods like get_panel_btn_handler
and so on.
I make some js breakpoints and I following the tracelog until this function js_render_custom_action. I get a simple error. When I want to edit that function (or an other which deal with the js and extjs), this don’t work for me even when I used a new private chrome session to avoid cache problems.
How to manage movement clearing¶
This is the first time that
must import accounting data. So as expected there are some surprises.
I tidied up most test suites (except Renamed “Lino Faggio” to “Lino Voga” which can wait) and
checked in because I needed to think about how to import the
match field of
movements. This field was a CharField (similar to the approach used
in TIM) until some months ago. Why did I change it into a pointer to
The (current) Lino approach has some disadvantages compared to the TIM approach:
what happens when the user deletes or unregisters a cleared voucher
we need groupers (
lino_cosi.lib.finan.models.Grouper) in order to manage grouped payments
tim2lino will have hard work to convert clearings from TIM to Lino
But the new approach seems really better because