Steps to reproduce the bug:
- Install Timesheet, Sales, Accounting
- Create a product P that creates a project when validated on a SO
- Create a SO with P and validate it
- Create an invoice with a downpayment of 10% and validate it
- On the SO, click on "Project(s) overview" smart button
Bug:
The invoiced amount on the overview was not updated with the downpayment invoiced.
When the SO was completely invoiced, the amount of the downpayment was counted in
"Other cost" (because an analityc line is created for the downpayment SO line)
opw:1969143
closesodoo/odoo#32962
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Long product descriptions were overflowing on mobile when the list
layout was used. Indeed in all other cases (non mobile or grid layout),
a max-height is set to prevent this problem. This commit sets a
max-height for the mobile list layout use case.
Note: the layout is still to be reviewed to handle these cases the right
way. A task is actually being developed in master to do that.
opw-1974989
closesodoo/odoo#33023
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the snippet was moved from the theme repository to the community
repository, some scss mixins were badly refactored, making the theme
specific styles not work anymore.
This commit removes the bg color which was added to latest posts
snippet's post elements as it made no sense, appeared broken and was
not possible to remove. It also adds some padding to the snippet by
default.
This commit also reviews the snippet options which seemed to allow post
color edition while it is in fact not possible.
opw-1964485
closesodoo/odoo#33016
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Facebook API does not accept float values for height and width
parameters anymore.
closesodoo/odoo#32970
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Forward Port 0c46c8a929 from v10.0
has dome flows, namely, the new feature of grouping the taxes by tax group was not supported
Now it is supported: when modifying an optional product's quantity, every field is updated with the new values
OPW 1974708
closesodoo/odoo#32980
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Install CRM (we need the "Hide Private Message" record rule defined by
that module), create a meeting as of today, set a reminder of one day,
invite another user (Demo) as attendee, save. Edit, go to the options,
change the "Show time as" to "free", save => access error due to the
said record rule.
Using a search instead of browse ensures record unavailable due to a
record rule are filtered.
Same as 54e970e
opw-1974599
closesodoo/odoo#32987
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
It is more logical to display the order date on the portal rather than
the create date. Indeed, all computations (e.g. currency conversion) are
performed with the order date, not the create date.
opw-1966040
closesodoo/odoo#32973
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
`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>
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>
Goffin Simon