While many crons will process some sort of queue and can either delete
or mark items as processed, others are more concerned with time ranges
and may not want (or be able to) write on the objects to mark them as
processed. In that case, crons maintaining a processed date range is
useful.
Task 1912648
When a user produces multiple finished products with SN/lots, he has to
save the wizard go back to the production order and click again on produce
button for the second SN/lot. It could be annoying with a huge number of
SN/lots to encode.
This commit adds a 'Continue' button that saves the wizard and directly
opens a new with the new lot/SN.
Purpose is to allow to use the 'use' tag allowed by _eval_xml (see convert.py
for more details). It allows to read a specific field instead of id when using
a search tag in xml. Feature is already supported; this commit just enables
it in order to use it in demo data notably.
This commit is linked to task ID 1907994 and PR #28533.
Check that it makes custom binary fields into attachment as that's the
main reason for the change: when users create binary fields via Studio,
they're necessarily db-stored (as the interface doesn't allow altering
the attachment attribute and it's unclear how we'd handle users
switching it on/off every time), which significantly bloats their
database (and burns storage & backup space), especially as the primary
use case for binary fields is adding images and documents to records.
* check that binary fields are properly created as attachment=True
* add attachment=False on fields where that seems relevant (most but not
all of the fields previously using the default)
* remove occurrences of attachment=True
closesodoo/odoo#29308
Because the JS cannot handle 1 or 0 being equivalent to true or false, the views should comply
Issues specifically arise in the kanban view when, instead of reloading every record with python,
the JS actually computes which record should be displayed by reinterpreting the domain
From a user point of view, on a fresh db with CRM installed, go to the app kanban view
Click on the contextual menu of the CRM kanban label, click uninstall
The modal opens, but click cancel. The kanban label of the kanban view has disappeared
This is due to commit 33ba61bfdb, which prevents reloading all the view
for performance purposes
This commit prevents the label from disappearing
OPW 1903534
closesodoo/odoo#28484
Before this commit, the SSF would only set up edition views on o2ms at
the toplevel. This usually isn't an issue, but in some cases involing
onchanges on o2ms which themselves contain o2m, odd results could
happen as the second level would try to list the sub-o2m's fields in
order to cleanup its (possible absence of) values (cf the `subfields`
local variable in _cleanup_onchange), which would blow up due to the
missing `"edition"` key.
Fix by recursively processing o2ms and setting up their edition view.
Also fix the fields iteration in fvg processing: don't recurse inside
fields. There still is no support for embedded views (I think?) but we
should not try to treat subview fields as view fields, that could have
very bad results.
closesodoo/odoo#28645
This reverts commit c42a130a98
and commit fb7ac56d65.
The runbot is using cross db logging and those commit were breaking the
mechanism. As a result, the master builds logs were empty.
If we update the runbot to use logging_type instead, the other versions
builds will be impacted hence this revert.
closesodoo/odoo#28512
PKG-INFO is generated during the setup phase and is not needed anymore.
Also this file contains outdated informations.
py2exe is not used anymore to build the windows installer.
closesodoo/odoo#28494
Odoo 12.0 does *not* officially support any python version below 3.5,
but no effort had been made to gracefully announce this to the end user
if they were to run Odoo in an unsupported python version.
This is done because Odoo 12.0 uses py3-only constructs which can
and will raise different errors if ran in python 2.
With this patch, Odoo will display an appropriate error message and won't
launch at all unless it is being run with python 3.5 or greater.
closesodoo/odoo#28502
When changing the field `image` on `res.users`, the `write_date` of the user is
not updated because the field is inherited from `res.partner`.
Related to Issue : 1839603
Due to the implementation of PEP-475[1] in Python 3.5, revision
e98e8e9b1b used the recommended technique
of wakeup file descriptors in order to detect interruption of sleep() and
select() by signals, when running in multi-process mode (workers > 0).
The technique works well, however the initial patch never bothered to
read the byte that is written to the wakeup pipe when a signal is
processed. This does not matter when the signal is meant to shut down
the server, but it matters when the signal is SIGQUIT: it simply prints
thread dumps, and continues operating normally.
As a consequence, that byte remains in the wakeup pipe forever, causing
all the subsequent select/sleep calls to return immediately because
the wakeup fd *is* already ready. The symptom was that worker
processes would start cycling their main run loop very fast after
receiving a SIGQUIT signal, eating 100% CPU.
This patch ensures we always empty the wakeup pipe after an interruptible
call, to avoid this effect. It also refactors another occurrence of the
"empty pipe" pattern, in the PreforkServer, and incidentally uses readable
aliases for the file descriptors bound to the ends of the wakeup pipe
(wakeup_fd_r / wakeup_fd_w).
[1] https://www.python.org/dev/peps/pep-0475closesodoo/odoo#28356
Consider a many2one field `foo_id` on model `bar`, with an inverse one2many
field `bar_ids` on model `foo`. During an onchange, the statement
bar.foo_id = foo
puts a special value in cache to add `bar` to the value of `foo.bar_ids`
without explicitly reading `foo.bar_ids`.
Executing the above statement a second time, the cache of `foo.bar_ids` is no
longer empty. This causes the actual value of `foo.bar_ids` to be read and
updated. The issue is that this can be slow for large values of `foo.bar_ids`.
Avoid reading the value of the one2many field by handling the case where the
cache contains the special value: simply update the special value to take into
account the second assignment.
closesodoo/odoo#28982
When creating a portal user from the User & Companies menu in the
Settings.
Before this commit, the created user had both groups' portal user and
internal user, which generated an error in the display of the user
accesses and rights. This also occurred if we manually add a portal
user to the internal user group.
Now, when creating a portal user, the user only has this group. Also,
if we manually add a portal user to the internal user group, an error
is raised to inform that only one user type is allowed.
OPW-1929367
closesodoo/odoo#30958
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
The SSF would properly mark its own records as deleted, but it would
not properly handle deletion requests coming from an onchange, and it
would not necessarily convert DELETE_ALL commands (5) into the proper
sequence of individual (2)s matching existing records.
closesodoo/odoo#31431
For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.
Before this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>" # lost English version
After this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>" # write had no effect
>>> record.arch
"<h1>Title</h1>"
When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.
To update translations, the supported way is to go to the list of translations
and update them there.
Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True
If a field is callable, it should also be ignored, the same way than
translate=True fields
opw-1887162
closesodoo/odoo#31330
This is necessary to get --dev=xml working on windows, because the xml
import uses normcase in file_open and the case normalized filename is
then used to find the addon path (which was not found before on windows)
With this fix arch_fs is now correctly filled in windows and --dev=xml
works.
closesodoo/odoo#28331
When there is a language and its base language translation files in a
module, in 12.0 an empty translation in the language translation file
will not fallback on the base language.
eg.
fr.po : {'one': 'un', 'seventy': 'soixante-dix'}
fr_BE.po: {'one': '', 'seventy': 'septante'}
=> the translation in fr_BE will be {'one': '', 'seventy': 'septante'}
but before 7288b477 it would have been {'one': 'un', 'seventy': 'septante'}
With this commit, an empty translation is no longer created so does not
override base language.
Also the intention of d84b795b0a that was also lost is restored by
upserting only noupdate==false translation, and inserting the other
ones.
opw-1904638
closes#28297
After 12744bc81ebdaa1671a953c14ba54c637d6a9255, x2m operations are
fully batched, and deletions are processed last when the operations are
flushed, regardless of the order in which they were specified by the
write() or create() call.
This carries a risk of violating (non-deferred) unique SQL constraints,
when the operations for deleting previous lines and re-creating new
ones are processed in the same batch.
This patch executes the deletions before other operations during a
flush, which should be safer with regard to SQL constraints.
An extra constraint is added in test_performance.line to simulate this
corner case, then covered by an extra unit test.
Another unrelated test had to be altered to avoid violating the
new constraint.
This can be reproduced easily by upgrading the `project` module in master,
due to the unique constraint[1] on `ir.actions.act_window.view`, that
gets violated when processing the batch write on this o2m[2].
[1] https://github.com/odoo/odoo/blob/ccc42f16/odoo/addons/base/models/ir_actions.py#L288-L289
[2] https://github.com/odoo/odoo/blob/ccc42f16/addons/project/views/project_views.xml#L394-L396closesodoo/odoo#28314
The ir.mail_server Model includes a sequence field, promising that the
lower sequence number have higher priority when multiple server
configurations are available.
The servers are already used based on that parameter since 00bd7274c4 but this
was not enforced at the _order level.
Make it coherent everywhere
closesodoo/odoo#28313
lul-odoo