Before this commit and since the huge JS refactoring, when you were editing
a blog post it wouldn't save your modifications if you touched the title or
subtitle of the blog.
This was due to title & subtitle getting considered as the cover itself
when saving (_saveElement) because they are inside the cover (in a HTML point
of view).
So if you had modified both the cover, the title and the subtiltle, it was:
1. Saving the cover
2. Saving the cover again
3. Saving the cover again
Now, _saveElement is called as it should, for the same case, it is:
1. Saving the cover
2. Saving the title
3. Saving the subtitle
Before this commit, website.page xml record were created in 2 steps:
1. Create an ir.ui.view record with <template> tag
2. Create a website.page record with <record model="website.page">
But this is useless since website.page inheritS ir.ui.view, you can create both
records just in one <record> tag.
Note: This is NOT TRUE in every case:
Odoo's ORM will suffix external_id of inherited records (in this case the
ir.ui.view created through the website.page record) with its model's name.
This can be a problem in some case (this is an example):
website_crm_template.xml create an ir.ui.view inheriting the
ir.ui.view 'website.contactus'.
But if we didn't keep website.page & ir.ui.view records split for that
specific case, the ir.ui.view would inherit a website.page record
causing an error. (website.contactus would be the id of the page record
while the ir.ui.view's id would be website.contactus_ir_ui_view)
In short: when migrating an ir.ui.view (<record> xml) to a website.page:
* If there is record inheriting the ir.ui.view ID, then split
website.page & ir.ui.view
* if not, you can create the website.page and its ir.ui.view both in one
record (<record model="website.page").
This commit also removed remaining page="True" from xml template since we
removed the 'page' attribute from ir.ui.view model overrided in website module.
Before this commit, website.page had a 'name' field which was useless because
website.page inheritS from ir.ui.view which has its own 'name field.
At the end, we were duplicating/synchronizing 'name' field between
website.page and its ir.ui.view for no reason because we were always using the
one from ir.ui.view.
Now, getting website.page's name will always retrieve the one from its
ir.ui.view and there is no redundant information.
Was only done when updating base.
The cost of scanning the addons path should small in comparison to the update
time itself.
Followup of #9133Closes#9140
These modifications are legit as the method is private and the user has the right to create a company.
This will create an internal project and a dedicated task.
When reading a one2many field, the inverse field of the retrieved lines may
already be assigned in cache to a new record. This can happen during an
onchange. In that case, the algorithm crashes. Let's clean it up!
Before this commit, a field handled with a widget url was given its value (href) as its text, fully displaying the url.
Moreover, the display was odd and did not match that of buttons
After this commit, if the field contains a text attribute, we use is as the text of the link.
The link also correctly displays and looks like a button (in a form view)
Of course, a test for this new field widget feature is implemented
closes#19587
With the old demo data there were 3 picking without initial
demand.
This commit modifies the picking to reflect 3 differents cases.
-One picking without quantity done
-A picking that need a back order
-A picking without qty done and initial demand that should raise
an error
Previsously picking batch done button automatically run backorder
for picking that need and set a quantity done for picking without it
This commit changes the function done for picking wave in order to
call the needed wizard(set qty_done automatically or asking for a
backorder). Also it override the immediate transfer wizard in order to
pass the picking to backorder found in done function through the process
action.
pick_to_backorder_ids is needed in immediate transfer since we need to
pass the backorders from the done function in stock_picking_batch
through the immediate transfer wizard.
The purpose of this commit is to allow future modules that need
immediate transfer and back order function on multiples picking
to do it.
This commit does not modify the behavior of single picking processing
Commit a7ac2cf9fbb57242c1f528c4d6604af0e1509dae attempted at introducing a python constraint to make the fiscal day fall within the month boundaries (eg. not to be able to set Feb 30th)
The constrain appeared to fail depending on the order of its dependencies' evaluation.
After this present commit, we force the out of bounds given date to be the last day of the month
Reading them as bytes would not crash but could fill the corresponding
field with pretty much garbage. Turns out Html fields inherit from
Text and XML content generally goes into text fields, so handling
these items as text makes much more sense than as binary data.
Commit 5d7e6dfad5 remove
split move line since it could be useless with merge
moves. However it could still usefull if the move don't
have a picking (mrp for example).
This commit fixes:
- an expected singleton in vacuum, as `_get_in_domain` should be called
on the move we are looping on, not the whole recordset
- some entries were posted for non valuated stock moves
- the depends for the stock value where not correct and the value was
not recomputed when it should
- there was a mismatch between `get_price_unit` and `_get_price_unit`,
we rename all these method into the private one
- the valuation fields were copied on copied move. this proved to be
problmatic when creating extra move
- in the `_fifo_vacuum` method, when looking for candidates, filter on
available ones
We also refactore the way the valuation is implemented. Indeed, before
this commit, the valuation of a product was the sum of all the sum
fields of the valuated stock moves associated to the given product. This
proved to be the wrong approach when dealing with done stock move
edition and negative stock. Let's say you sold 20 items you do not have,
we'll post an entry with the estimated price and later, when we correct
this entry after receiving new products, updating the value was
complicated. We moved out from this approach by never editing the value
(it is the value at which the stock move was initially valuated) but
updating the remaining value: a negative stock move has a negative
remaining value, every time we compensate it we increase the value. Once
the remaining quantity is null, we wipe the remaining value. We adapted
the code according to this new principle, especially the code posting
the correction entry (that should compensate the negative remaiing
value).
A mechanism was not correctly implemented: increasing the quantity of a
done out move should re-run the fifo lookup. We extract the `_run_fifo`
method into a model method and add to it an optional quantity argument.
This allows to run the method from the write on a done stock move.
We also raise a blocking error if the valuation is 0, it means that the
user has not correctly set its master data.
We add a bunch of tests for all these usecases and complete some older
ones to check the total of account entries.
Kind of switches the behavior for inventory and valuation report,
meaning allows the user to see the quantity at date and disallow him to
see the valuation at date.
Create a new module to directly find a source term on Transifex
This will not make translation easier but improve the collaboration and allow
easily to find a source term.
Following commit https://github.com/odoo/odoo/commit/dbb931976fd102a1eceea4ebf195efea7576f260:
The inherit_children field was not showing the proper order of
inheritance in form view, making debugging complex.
Note: this commit adds the code to show the proper order but revealed
a bug which will be fixed in another commit: the default_order of
x2m views only considers the first ordering field.
This branch aims to improve the UX of grouped Kanban views on
mobile devices. Only one column is now displayed, full width. The
columns' records are lazy-loaded. The user can swipe horizontally
to navigate through columns (thanks to the touchSwipe library).
This library is lazy-loaded (in mobile only, when the user reaches a
kanban view).
Task #31544
This commit refactors the JS and LESS of the new mobile version
of the grouped kanban views. It ensures that the touchSwipe
library is lazy-loaded (only in mobile, when entering a kanban
view).
This commit aims to improve the UX of grouped Kanban views on
mobile devices. Only one column is now displayed, full width. The
columns' records are lazy-loaded. The user can swipe horizontally
to navigate through columns (thanks to the touchSwipe library).
Currently, the view inheritance order is 'priority,name,id', the
default order for the 'ir.ui.view' model.
This commit changes the order to 'priority,id' while computing
inheritance. This make views chronologically ordered according to their
installation order, after the primary sorting on `priority`.
This helps to automatically solve some inheritance order bugs that would
have traditionally required explicit view priorities.
Considering this example: an app C depends on two others apps A and B.
We want the LESS files of C to come after the LESS files of A and B as
CSS rules order matter. The only solution to make sure of that with the
current implementation is to change priority field of C to be higher
than 16 (default of A and B). With a complex hierarchy, that will induce
errors. Ordering by 'priority,id' solves the problem, indeed views' ids
of apps A and B will be lower than views' ids of app C. The "name"
ordering is fine for list views display but not for views inheritance.
Closes#19658
Coercing the result of the compilation to text is easier and more
portable than P3-specific code for putting the Popen streams in text
mode.
Fixes#19659
This is an attempt at fixing the long timeout occurring on P3 when
trying to stop the server with Ctrl-C, both in multithreaded and
multi-process mode.
The root cause is the implementation of PEP-0475[1] as of Python 3.5,
which make system calls silently resume after an interrupt.
With this PEP, interrupting a syscall now requires the signal handler to
raise an exception, which get propagated in places where they did not
use to occur (e.g. time.sleep() used to return early when interrupted)
The solution handles 2 separate cases:
1. Multithreaded
In multithreaded mode, stopping the server requires interrupting
the main thread, while ensuring that all other threads are daemon ones.
The previous commit fixed the latter.
Interrupting the main thread is easy, because it simply sleeps until
it gets interrupted. And it already catches KeyboardInterrupt for
win32 quirks. All we need to do is thus to raise a KeyboardInterrupt
in the signal handler, as proposed in PEP 475 (Use Case 2)
2. Multi-process
In multi-process mode, stopping the server requires interrupting the
main thread of each process. The signal is already propagated to all
processes, so it should be as simple as for multithreaded mode.
Unfortunately, the main threads are far from idle in this case,
and raising a KeyboardInterrupt from the signal handler causes a
series of ugly tracebacks before stopping the server.
Effective, but frightening for the admin.
Instead of doing that, we can watch the wakeup file descriptor
(also suggested in PEP 475, Use Case 2) during the sleep() part of the
main loop of each worker. An interrupt signal won't therefore stop
the server immediately, but will wait until each worker is done with
their current request.. even better.
For select() syscalls, this is done with an extra pipe fd that is passed in
the "read fds", and used as wakeup fd.
And for sleep() syscalls, that don't support a wakeup fd, we can
replace them with an equivalent select() call on the wakeup fd, and
a timeout.
The combination of the above seems to restore a relatively fast
interrupt shutdown on both Python 2.7 and Python 3.5, in both
multithreaded and multi-process mode, with no surprising traceback.
[1] https://www.python.org/dev/peps/pep-0475/
P3 got rid of all __private attributes in the `threading` module,
via python/cpython@d06489945f.
Our old code for forcing the `daemon` attribute on an already started
thread used the mangled private name and does not work anymore on P3.
We need to use the new private attribute name (actually both,
to keep backwards-compatibility w/ P2)
This might have deserved a pycompat counterpart, but setting both
variants of the attribute works with no hassle. It should not be a very
frequent use case either.
By using the thread's repr() we get its type, name, daemon status and
ID, all at one time. No need to include them separately.
Fall back to the threadId in case the repr() is empty, which can
happen for exotic threads (the gevent main thread seems to be like that)