Since the refactoring of forum, faq sanitize is set to False.
The editor of the faq can make what he want...
But disable sanitize will break the translation since fields.py has code:
```python
def _setup_attrs(self, model, name):
super(Html, self)._setup_attrs(model, name)
# Translated sanitized html fields must use html_translate or a callable.
if self.translate is True and self.sanitize:
self.translate = html_translate
```
Now we don't become html_translate magically, but we need to specify it
in the field definition direclty.
Courtesy of @mart-e
This commit closes opw-1978662
closesodoo/odoo#33112
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since media dialog and unsplash refactoring (1f847a1e2e, 78a30d44c) there was a
bug after adding credentials.
Indeed, when doing a search for the first time and no credentials are set, it
shows a form to add the missing credentials.
When saving those, it should automatically perform the initial search now that
the credentials are set.
But it was not the case anymore, it would keep reloading the credential form.
User would have to close and reopen media dialog.
closesodoo/odoo#32943
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this fix an extra line with the price without discount will be
printed even if there is no discount on the product.
After this fix the line will only be printed if there is a discount.
The error occured due to the use of t-else instead of t-elif.
closesodoo/odoo#32989
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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>
Instead of fil - fil_PH, it should have been fil_PH - fil.
The iso_code is used in URLs
The "code" value can not be changed in stable but iso-code can.
The code value will be changed in master as requires a migration script
closesodoo/odoo#32867
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Create an expense paid directly by the company, validate and post entries.
While the account move lines are correct, the payment is not: it is always null.
opw 1962500
closesodoo/odoo#32956
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Configure a route to be in 3 steps
make a PO, validate all three pickings
Go on the final picking, the one that has the destination to the Stock
Click on the smart button to access the traceability report
unfold as many lines as you can
Before this commit, the first picking of the whole tree (Vendors to Input)
appeared as a direct child of the final picking,
as well as a child of the intermediary picking (as it should)
- Quality > Stock
|
- Input > Quality
| |
| -Vendors > Input
- Vendors > Input
After this commit, the final picking contains only the intermediary
which in turn contains only the origin
- Quality > Stock
|
- Input > Quality
|
-Vendors > Input
OPW 1970286
closesodoo/odoo#32953
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The Traceability Report printing option is hidden since the report is
pretty much unusable.
opw-1973161
closesodoo/odoo#32939
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Pretty much the whole module is covered by the tests in this commit:
- standard comparison, from shop, from product page
- comparison with more complicated product configuration
- the comparison page itself
- the alternative products
task-1929151
closesodoo/odoo#32901
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Steps to reproduce the bug:
- Install MRP
- Uninstall MRP
- Install MRP
Bug:
An error was raised by sql constraint 'barcode_company_uniq' which ensures that
a barcode for a location is unique per company.
But when uninstalling MRP, some locations such as pbm_loc_id or sam_loc_id are set to
active = False and when re-installing MRP, the function _create_missing_locations tried
to re-create these locations and the sql constraint was raised.
opw:1967534
closesodoo/odoo#32882
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The goal of commit 2dbce5e was to handle the company
holiday type in onchange which was probably forgotten
when the company type was introduced.
However because the last `elif` was changed to `else`,
the `else` clause is executed in some situations where
it shouldn't.
e.g. If holiday type is `employee` and an employee is set,
the `else` clause is (obviously wrongly) executed.
This is particularly a problem if the employee is not
HR user nor manager. In that case, the field employee_id
is invisible and its value has been deleted by the onchange.
The allocation cannot be saved because it violates the
sql constraint (employee is null).
Also, the `mode_company_id` and `category_id` should be set
to `False` when the holiday type is not company/category.
1. Open form view to create a leave
2. Change the leave type to 'By department'
3. Choose the department of the current user
4. Save the leave
5. Approve the leave
=> ValidationError, cannot have two leaves at the same time.
In `@api.onchange('holiday_type')`, when choosing by department
it sets `employee_id`, `mode_company_id` and `category_id`
to `False` ONLY if the department is not already set.
But by default, the employee is set to the user's employee
and the department is set to the employee's department.
Therefore the employee is never set to `False` and the
department leave is linked to this employee.
When validating the 'department' leave, an 'employee'
leave is created for each employee in the department.
For the current user, it crashes because the deparment leave overlaps with
the 'employee' leave since the department leave is linked to
the employee.
Since it is possible to create an operation in the regular list view, it
should also be possible to do it in the kanban mobile view.
opw-1963527
closesodoo/odoo#32907
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 companies A & B
- For each company, create a website linked to a different URL and
activate 'Free sign up' and 'Specific User Account'.
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
The user is created in company A (the company of the user template)
instead of company B (the company of the website).
We set the company of the user based on the company of the website.
opw-1962197
closesodoo/odoo#32823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 companies A & B
- For each company, create a website linked to a specific URL
- As a public user, visit website of B
- Buy a product, register your address
The partner is in company A (the company of the superuser) instead of
company B (the company of the website).
opw-1962197
closesodoo/odoo#32822
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We remove the remaining comparisons to use the precision rounding of the UoM.
opw 1969888
closes#32707closes#32745closesodoo/odoo#32844
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- When changing the `holiday_type` of a leave allocation while having an
employee set and if this `holiday_type` has as its value `employee`
the field `employee_id` is set to False.
This is not the intended behavior. We want the field `employee_id`
to be filled if the `holiday_type` is set to `employee`.
closesodoo/odoo#32886
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
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>
Create a SO with two lines (sol_1, sol_2) selling a given service.
On the corresponding Project/Task, set the partner so that the sale_line_id
can be chosen to one of the lines.
Add an AAL with x hours, save.
This updates the delivered quantity (x) on sol_1.
Edit, change the sale_line_id to the second one:
it updates the delivered quantity on sol_2 (to x) but not on sol_1.
Has a result, the delivered quantity has been doubled.
The issue is that the quantities are only recomputed on the SOL that we write;
instead they should be recomputed on the old one and the new one.
We base ourselves on 371a92fb which solved a similar bug to add the recompute on
both lines.
opw 1959509
11.0-opw1959509-sltmsht-len
closesodoo/odoo#32820
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Fine tuning of ac31252d54
Do not pre-filter on canceled entries since they are used a few lines
below.
opw-1964459
closesodoo/odoo#32835
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a SO with a quotation template and some optional products set
Display it on the portal
On an optional product, click on the cart icon
to add it to the SO
Modify the quantity of the optional product
Before this commit, the feature was barely working:
- the total price of the optional product did not change
- negative quantities were allowed
- there was no reaction when directly putting a number in the input
- when decrementing the quantity, it crashed
- untaxed and tax amounts were not dynamic
After this commit:
- the total price of the optional product changes as a function of the quantity input
- negative quantities are not allowed
- it is not possible to manually input the quantity with a keyboard
only +/- buttons are used to change the quantity
- decrementing the quantity works
- untaxed and tax amounts are dynamic
OPW 1947769
closesodoo/odoo#32715
Signed-off-by: Lucas Perais (lpe) <lpe@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>
`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>
closesodoo/odoo#32805
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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>
Fine tuning of commit b9e3c153, for the same use-case.
The route may not be passed in values, in which case the bug is still present.
There are two ways to go around that.
We could add the stock.rule in values, which contains the route.
The solution we adopt here is to use the sale_line_id field on the purchase line
If it is present, it was added through _prepare_purchase_order_line,
and thus we want to keep track of the origin.
opw 1957701
closesodoo/odoo#32683
Signed-off-by: Nans Lefebvre (len) <len@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>
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 a consumable or storable final product A with invoicing policy
in "delivered quantity"
- Create two storable products B and C
- Create a BOM kit for A with 1 B and 1 C
- Create a SO with 5 qty of A and confirm it
- Deliver 3 B and 2 C and either on "No backorder" or "With backorder"
Bug:
The delivered_qty on the SO line is of course not automatically updated
(as in this case, a right value is not computable) but the delivered_qty
was not updatable manually and then it was possible to invoice the SO.
Co-authored-by: nim-odoo <nim@odoo.com>
opw:1966170
closesodoo/odoo#32733
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Jeremy Kersten