Protactively checking exists() seems unnecessary, it's likely that the
widget would be called on an empty recordset but seems very unlikely
that it'll be called on a missing record. The commit which added the
exists() call performs significant refactoring/rewrite and doesn't
explain why this exists() call would be useful.
Since exists is not cached and qweb field converters are not batched,
saves a large number of queries when formatting a series of addresses
e.g. with 99 hr.job, /jobs goes from ~170 queries and ~100ms spent in
SQL to ~70 queries and ~60ms spent in SQL.
Though the total performance improvement is very limited as even with
odoo/odoo#32985 the endpoint takes ~700ms (with the aforementioned 99
hr.job visible to the current user).
closesodoo/odoo#32986
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Commit 1da63f0ab0 removed the
uninstall_hook defined in sale/__init__.py but forgot to remove it from
the __manifest__.py, resulting in a traceback when uninstalling the
`sale` module.
closesodoo/odoo#32804
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Currently in some screen sizes and themes, layout for author card
is broken (see iPad Pro for example).
This commit fixes the issue by improving the card layout, making
it uniform for all devices.
task-1938637
closesodoo/odoo#32753
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Have a fieldHTML as:
```
<p>
Some text
<br>
<br>
More text
</p>
```
In the Html field widget, place your cursor before the "M"
press Enter to insert a newline
Before this commit "Some text" and the subsequent `<br>` were deleted
This was because the code:
- split the original `<p>` into two
( i.e. it became
```
<p>
Some text
<br>
<br>
</p>
<p>
More text
</p>
```
)
- took the last child of the first p, which is a text then fell back to the first p
- replaced the whole p with <br>
After this commit, the original p is still split, but we append the br to it instead of replacing it
closesodoo/odoo#32777
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
`reserved_availability` is a computed field of a move depending on its
move lines. We access this field at each iteration of the loop over the
moves to assign and then we create a new move line for it. This triggers
an invalidation of this field, The next iteration will again access this
field and prefetch it for all the next records.
We read the field out of the loop and don't access it again to prevent
these prefetch/invalidation issues.
Confirmation of a PO of ~800 lines goes from 5 minutes to 1 minute.
opw-1953398
closesodoo/odoo#32774
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create two fiscal postions fp1 and fp2
- Create a customer C with fp1
- Create a SO for C and set fp2
- Create an invoice for the SO
BUG:
The fiscal position of the SO was set to False.
Now the fiscal position of the SO is kept when creating an invoice
from a SO.
opw:1963910
closesodoo/odoo#32713
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit 240d191ba3 introduced the field
company_id on model stock.move.line and a python constraint that check
if the company is the same on the move line and on the related move.
In order to avoid performance issue, this commit replace the constraint
by a 'related' parameter on the company field.
As the company_id is not editable we suppose this change will not introduced
unwanted errors
Task : 1970012
closesodoo/odoo#32738
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If there is no rating for user, it will throw error while publishing channel.
This commit check if there is any rating for particular user or not.
Introduced by ce20c29f82
opw-1966384
closesodoo/odoo#32553
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, a domain that had been written in order to be
JSON parsable, would trigger a JS crash when activated in the UI
It happens when adding custom filters through the edition of the search view with studio
This was because, Odoo developers write, in the XML of a search view
domains python style: `[('field', '=', 'value')]`
When parsing the view in JS, this doesn't get altered by `xml_to_json`
Then, the search view code evaluates it python style
This commit considers that behavior fortunate, but not really clear or conceptually correct
But, when customizing a search view with studio, the domain is written by the code, in JS
JSON parsable format `[["field", "=", "value"]]`
This should be supported too, as so many customizations may have been done before hand
After this commit, both expressions are supported by the filters menu
OPW 1957297, 1960732, 1965649 (at least)
closesodoo/odoo#32690
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create a calendar meeting using Mark Demo. In the options of the event,
set the meeting as "Show Time as" = "Free". Using the admin user, send a
digest (KPI Digest module, technical > emails > digest email > send
now). It raises an User Error because the template cannot be rendered.
The problem is due to the way the "Show Time as" is implemented, the
"Free" option is used to not show the meeting in the different calendar
views. The events are hidden thanks to a record rule "Hide Private
Meetings".
Each digest is sent using the context of each subscripted user and not
the SuperUser ID 1. The call to `search_count` on `mail.message` calls
the dedicated `_search` of `mail.message` and ultimately end up in the
overriden `_find_allowed_model_wise` method of message in calendar.
That method does a browse of all the record ids containing new
messages in their chatter, but fail with an access error due to the
above record rule. Because it fails, the `kpi_mail_message_total_value`
compute fails and the field is missing when rendering the template.
Using `search` instead of `browse` ensures records unavailable due to a
record rule are filtered out.
opw-1966664
closesodoo/odoo#32735
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Avoid pathological SQL queries with extremely long list of ids in a
WHERE clause. The strong relation between these models make an auto_join
a no brainer.
closesodoo/odoo#32645
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The user can delete teams created during the installation of the Sale
Team module, both CRM and Sale modify those teams but the way they
modify the teams doesn't take their deletion into account.
This reverts commit 30a848bffb to replace
post_init_hooks by `forcecreate=False` in the datas.
closesodoo/odoo#32742
Signed-off-by: Christophe Simonis <chs@odoo.com>
Steps to reproduce the bug:
- Define two pricelists P1(€) the default one and P2($) with discount_policy = 'without_discount'
- Activate P1 and P2 on the website
- Go on the shop and select P2
Bug:
An error was raised from function _get_conversion_rate because the arguments date and company_id were not defined
because the function _get_real_price_currency was called from _website_product_id_change with
the model "self.env['sale.order.line'] and not with a recordset. So the fields self.company_id and self.order_id.date_order
were not defined.
opw:1969849
closesodoo/odoo#32726
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, the standard mail templates for calendar
did not have a language
After this commit, we set it to the the partner's language
OPW 1946686
closesodoo/odoo#32717
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The available_carriers must be computed according to the shipping address.
opw:1967445
closesodoo/odoo#32693
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
the group by key in action context can be a single string
containing the name of a single field or a list of string
reprenting a list of field names
Before this commit, the board did not take this into account
After this commit, it does and supports both expressions
OPW 1956130
closesodoo/odoo#32471
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Usecase to reproduce
- Create a BoM with finished product A and Comp C
- Create a RR on product A with min qty 10
- Product A is tracked by serial number and have route manufacture
- Run the scheduler twice.
The finished tabs in the manufacturing order created from the order
point contains 10 move lines with 1 qty reserved and 0 quantity done.
The first run created the MO. The second run, assign the finished moves
and thus created the move lines for finished product A.
However those move line are not used by mrp because the workorder and
the produce wizard will only create new lines instead of using existing
lines with reservation. Also action_assign on MO only trigger
_action_assign on raw moves.
This commit add a hook on scheduler in order to modify the domain that
will be used in order to search moves to assign. Use the hook in order
to avoid move with the production_id many2one set.
closesodoo/odoo#32597
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Open a quotation from the portal using IE11. The sidebar is rendered as
it did not have any width.
What we are trying to achieve on large screens is to create a sidebar
with a fix width the size of its children and to let the rest of the
content (right to the sidebar) expands. On small screens we want to
invert the direction from left-to-right to up-to-bottom.
The classes `col-12`, `col-lg` and `flex-lg-grow-0` are used to fulfill
that purpose.
The problem is due to the rule `flex-grow: 0 !important` applied by the
selector `.flex-lg-grow-0` on the sidebar. On Chrome/Firefox the dom
element takes the width of his children as minimal width, the
`flex-grow: 0` does not shrink the element below that minimal width.
IE11 does not set a minimal width based on the child elements of the
node, the width is equal to 0 and the `flex-grow: 0` forbid it from
growing.
The solution is to replace the said classes by the `col-lg-auto` class
that does exactly what we want and is cross-browser.
opw-1944188
opw-1935087
closesodoo/odoo#32484
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Several cases:
- on a dashboard viewtype, put a group by on the chart
- on a list viewtype, apply a group by and an ordered by
In both cases the parameters were not taken into account when
rendering the view in the board app
ref: 40dd121938
This was because, when saving an action for the board app
we tried to fill the "action's context" with only the contexts of:
- the search query (where context is just one of attributes)
- the ownQueryParams of the controller
Doing that, some other vital attributes, like group_by and orderedBy
where forgotten in the process. "C'est ballot!".
Also, the "real context" of those attributes was saved
as a context within the context.
But (!), the action's context will behave as a "real context" when spawning
views and controllers down the line.
After this commit, we flatten as much as possible all those nested
contexts at the time of saving the view
OPW 1944857
Fine-tuning of 0a4e67c609.
Due to some confusion, has_group had been replaced by user_has_groups
on the corresponding PR.
However the latter is not a higher-level version of the former,
since it checks the groups on the self.env.user, not on self.
As a result, the filtering was completely False, since it checked that the env
user was in group_user which was always True.
closesodoo/odoo#32653
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
As authenticated user, join the website livechat. As a portal user,
start a livechat. Close it, it asks you to review the chat but all
messages are displayed in english.
opw-1958819
closesodoo/odoo#32629
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Usecase:
- Go on a BoM with a routing. Go on the first operation and set
the next operation(batch field) as 'Once a minimum number of products is
processed'.
- Set the batch size (minimum operation) to 0.
- Create a MO and plan it.
- The second work order has state 'pending' instead of 'ready'
It happens because the system automatically set the first wo as
'ready' and the following as 'pending' and don't check the batch
and batch_size.
closesodoo/odoo#32628
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The validation error introduced in 552da8dc can pop up in contexts where
it is not expected;
e.g. not in editing user rights but while upgrading a module.
Therefore we make it more explicit, giving the user a way to resolve the error.
closesodoo/odoo#32623
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
From an onchange, at this point, (4) doesn't mean "no change" it means
"reset to database values". Through the interplay of client and server
reverse-engineering one another at this point the client (is supposed
to) assume the o2m results are "complete" and a diff from the
current *in-database* values rather than the in-client (sent to the
server) ones.
So a (1) should completely replace all existing values, and a (4)
should just remove all of them (but keep the record linked).
closesodoo/odoo#32617
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce the bug:
- Create a SO with no salesperson
- Add a SO line with 2 storable product
- Confirm the SO and deliver only one product
- Click on "No backorder"
Bug:
A error was raised because the function "_log_activity"(called by _log_less_quantities_than_expected) requires a responsible
Partial Backport: https://github.com/odoo/odoo/commit/e1f9499d2672fb0a346f8ac74552f038f5204a64
opw:1950968
closesodoo/odoo#32592
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Set a product P to average valuation, real time
- Create a PO for 1 unit @ 100, validate the picking
- Create a PO for 1 unit @ 0 (e.g. you receive a free product)
You cannot validate the picking because of the message 'The cost of P is
currently equal to 0...'
This error message is historical, to prevent users from an incorrect
configuration.
Since we still want to prevent misconfiguration, but support the
mentioned use case, we introduce an `ir._config_parameter` for people
who 'know what they are doing'.
opw-1962249
closesodoo/odoo#32550
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This reverts commit abc45b1
Since by default the ondelete attribute of a many2one is `set null`,
this was completely unnecessary to begin with.
Bug caused by this commit:
Unlink a record that has some attachments.
The unlink first removes the record, then its related attachments.
It calls remove_as_main_attachment, which reads the attachment res_model and
res_id. This triggers a check that the related record can be read.
However the related record has already been removed, an exception is raised.
It is thus impossible to unlink a record.
Closes#32563closesodoo/odoo#32572
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In multicurrency
Do an invoice with cash basis lines in the foreign currency
Make a payment for almost all the invoice
"almost" refers to the point where virtually all taxes will be paid
i.e., paying 90 over 100, that contains a tax of 5%
The tax paid will be an amount almost equal (to a few cents) to the
total amount of the tax
It is not negligible, but if the currency rates are in the right configuration
(i.e. 0.005888)
Before this commit: the Cash Basis reconciliation will be considered as full and will trigger
the creation of the Exchange Diff Entry.
In turn, paying the rest of the invoice will pop up an error saying that some entries are already reconciled
(with the Exchange Diff entry)
It is not *that* that an exchange rate entry has been created the first time
after all, a percentage sufficiently close to 100 has been paid
But it blocks subsequent reconciliation, hence this fix
After this commit, if the cash basis entry doesn't match at least 100% of the paid move
then, we force to not check for full reconciliation
OPW 1953027
closes#31168closesodoo/odoo#32023
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, test reconciliation was inherited by
test reconciliation widget.
It made the actual test_xx functions of the former
being executed twice
After this commit, we create an intermediary test class for setUp and helpers
And the tests for each class execute only once
Before this commit, when reverting a move
that will be subjected to the creation of a cash basis move
the process failed saying that some entries were already reconciled
That was because the process tried to create the cash basis move during
the revert.
This is wrong, because no real cash is dealt with.
After this fix, the move lines of the original entry are reconciled
only with their revert counterpart
OPW 1938809
closes#30972
When an error occurred in the longpolling, we used to resend a new
request immediately. This resulted in thousands of request in a few
seconds when we lost connection to the box.
closesodoo/odoo#32544
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The protocol is hardcoded to `http` in the url for the longpolling
request (/point_of_sale/get_serialized_order). It should match the
same protocol as the page was loaded in to avoid Mixed Content errors.
closesodoo/odoo#32528
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The search on products is quite a slow sql query and it's run different times.
We avoid that repetition by storing it in a variable.
opw 1941352
closesodoo/odoo#32626
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a timesheet uom per Day
Have a language with a different number format than English
Click on grid cell to change its value
Before this commit, the value was stuck on the highest value in range
This was because the parsing of the value into float was not taking into account
the real format of the float
After this commit, it works in all languages
OPW 1964657
closesodoo/odoo#32581
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>