Backport of 7bc53ac30e.
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
closesodoo/odoo#32647
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Before this commit, when the PO was locked:
- the button create bill did not appear on the form view
- on the invoice form view, the field autocomplete did not mention the PO
After this commit, the button create bill is present, and the PO appears in
the auto-complete field of the Vendor bill
OPW 1970537
closesodoo/odoo#32794
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit 27d41ccb introduced record rules on resource.calendar.leaves.
However it gave no way to create, edit or delete a global rule.
We grant this right to the group_erp_manager, so that an admin can do it.
opw 1968376
closesodoo/odoo#32832
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
OPW-1967543 on non-trivial multi-level test BOM, MO creation goes from
30s to 13 on my system.
closesodoo/odoo#32819
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Install 'quality_mrp_workorder' without demo data
- Go to the General Settings
A warning is raised regarding the uninstallation of 'mrp_workorder'.
This is due to `_onchange_group_mrp_routings`, which assumes that the
installation of 'mrp_workorder' is only linked to the group
`group_mrp_routings`.
This is incorrect: `group_mrp_routings` might not be activated, but it
might be in the dependencies of another module. Therefore, we change the
logic: if we activate `group_mrp_routings`, we install 'mrp_workorder'.
If we deactivate `group_mrp_routings` we do not uninstall
'mrp_workorder' if it is already installed, since it might be required
by a dependancy.
opw-1970910
closesodoo/odoo#32811
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The base_setup.show_effect parameter is created at module installation (with
an external id) and is removed (and its external id) when the option
"Show Effect" is unchecked from the general setting.
When this option is checked again, the ir.config.parameter entry is recreated
but without an external id (as it is user-provided data, not from a data file).
When the module base_setup is updated, the record base_setup.show_effect is
recreated and the unicity constraint on ir.config.parameter is raised.
Set the record as forcecreate="False" to avoid recreating it when the module
is updated.
Anyway, if somebody uncheck the option, it is not expected to get it back when
the module is upgraded.
Fixesodoo/odoo#32806closesodoo/odoo#32808
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Set the company currency to USD, activate multi-currency
- Create a rate of 0.5 for EUR
- Create a purchase tax T:
Percentage: 10 %
Included in price
- Create a PO in EUR with the followind line
Quantity: 10.0
Price Unit: 1.0
Tax: T
- Validate the PO, receive the product
The journal entry is composed of 2 lines:
- debit: 18.18; amount currency: 10.0
- credit: 18.18; amount currency: -10.0
This is not correct: the amount currency should not include the tax.
In order to prevent this, we use the subtotal, and divide by the
normalized quantity (yeah, because it was also failing in case of multi
UoM, as one could have expected).
opw-1958287
closesodoo/odoo#32797
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create product A (type='product',tracking='lot')
- Create product B (type='product',tracking='lot')
- Create product Z(type='consu',tracking='none')
- Create BoM for product Z with product A as component and product B
as sub_product (i.e. By product) + create any routing (i.e. 1 operation).
- Create an MO for product z, plan it, process the given work order,
input the serial/lot for the components and byproducts...
Bug:
Two lines for product B were displayed in the finished_move_line_ids of the MO
This bug occured in enterprise because the function _create_checks defined on model
'mrp.workorder' creates the quality checks that create the finished_move_line_ids
for the by_product tracked by lot or by serial number (in fuction _update_active_move_line
defined on model 'mrp.workorder').
So the finished_move_line_ids were created two times with the ones created in fuction record_production
defined on model 'mrp.workorder' in community.
Co-authored-by: amoyaux <arm@odoo.com>
opw:1963163
closesodoo/odoo#32779
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit 52c89ade added a test in v11.
Commit 1e0a92c9 forward-ported that commit to v12, that already had a test.
As a result, the class TestDropship was defined twice.
It follows that the first test was not executed.
opw 1957701
closesodoo/odoo#32792
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Anglo-saxon Accounting entries are created always with the same Partner
id (the last one).
This commit is a fine tuning of the commit : 5ca0ef978f
opw-1961409
closesodoo/odoo#32672
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit 48018411 introduced a new ir.action.report type: qweb-text.
Commit 3425752 introduced an explicit check on the type, for html or pdf.
This removed the ability to support arbitrary reports through the call to the
generic render method, which dispatches to the correct one for a report_type.
We add support for the text format following the same logic.
The explicit error will be raised if the rendering fails,
e.g. in the case where the render method is not defined.
Thanks to @gdgellatly for reporting.
opw 1966208
closes#28513closes#30013closes#32532closesodoo/odoo#32773
Signed-off-by: Nans Lefebvre (len) <len@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>
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>
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>
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.
opw-1962297
closesodoo/odoo#32412
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- 2 Companies Parent A, and Child B
- Create a Stockable Product FIFO/automated,
- In A leave cost as 0, in B give cost of 10
- Create an SO for product in company B
- Logged into Parent A, validate the picking for Child B
Behavior before the fix:
An error was raised saying: Error cost of 0 (but the SO had been created in B, so the price had to be 10.)
Behavior after the fix:
Now the cost of the company B is taken.
closes#32329
opw:1966322
closesodoo/odoo#32615
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The method /web/binary/upload_attachment may be used (eg. it is the case
in enterprise documents module) without res_model (eg. if folder_id is
specified).
Thus we should make it work (that was not possible since a26496b6e).
opw-1964091
opw-1965832
opw-1967181
opw-1968063
closes#32692
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If we use a group by on the account dashboard, the kanban tiles have the
size of a normal kanban card so all graphs and so on are overlapping
which is a little ugly.
With this changeset, we have the same base width as in the non-grouped
view (which in the non grouped view may change with flex).
On {0,MD} screen size, we get in one column full width and ignore this.
opw-1964331
closes#32659
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
* Some accounts have wrong tax tag mapping
* Some fiscal positions don't work properly (mapping of taxes, right tax
keys, right accounts)
* Missing fiscal position "domestic partners" in order to allow
automatic selection of the right fiscal position if it is a doemstic
partner and to make it more clear for customers, otherwise they might
wonder why fiscal position field is empty for domestic partners.
* Issue with fiscal position "Geschäftspartner EU (ohne USt.-ID)" to
detect the right account, tax, tax tags if we sell to a customer / buy
from a supplier located in the EU without valid VAT-ID (for example
private people)
* Issue with fiscal position "Geschäftspartner Ausland" to detect the
right account, tax, tax tags if we sell to a customer / buy from a
supplier not located in the EU.
Closes#31389closesodoo/odoo#32673
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 10.0 that would be Debian 8
(jessie) and thus Jinja 2.7.3 (albeit with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32602
Signed-off-by: Christophe Simonis <chs@odoo.com>
When creating a delivery product from the delivery carrier form.
The delivery product should not be sealable or purchasable.
opw-1958029
closesodoo/odoo#32289
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In this way the description of the delivery method can be used on a SO
line. If the description wasn't set, the name of the delivery method
will be used.
opw-1958029
On the ticket 1961412, the custommer has more than 12 millions
of stock moves. Before this commit, the search request does
not take too much time to execute but fetching the fields on the
recordset takes a lot of time due to the 'in' in the where clause
of the associated SQL request.
This optimization permit to avoid this 'where clause' and decrease
the time to gather all the different fields. The time has been reduce
to less than one minutes where it takes approximately 20 minutes before.
closesodoo/odoo#32520
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 11.0 that would be Debian 9
(stretch) and thus Jinja 2.8 (with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32601
Signed-off-by: Christophe Simonis <chs@odoo.com>
This revision is similar to
605b94e64c
except that instead of an OperationalError
(e.g. a conccurent update),
this is an IntegrityError which is raised,
an sql constraint which is not met,
e.g. a unique or required constraint.
In the case of this opw,
this is the picking name unique constraint
which was not met,
the picking sequence number has somehow been re-used.
Both
`psycopg2.OperationalError`
and
`psycopg2.IntegrityError`
inherits from
`psycopg2.DatabaseError`
We therefore choose to use this Exception class,
to include all kind of psycopg2 exceptions that prevent
the transaction to be committed.
opw-1965679
closesodoo/odoo#32577
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.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>
In mass mailing access to partners when performing a mass mailing has been
done in batch to speedup computation [1]. Emails are put into a dictionary
allowing to find back the email based on partner_id.
However the matching between the partner and its emails is done using a
shortcut using the current document ID as partner ID. It works when performing
a mass mailing on partners but fails when performing a mass mailing on models
having message_get_default_recipients not returning only emails. Currently
in saas-14 main models return only emails (crm, event, mailing contacts) but
other models may encounter issues (applicants, tickets).
This commit fixes it by correctly matching partner id and its found email.
[1] See 65ed4553a5
Aaron Bohy