This commit make timesheet page of tasks related to time off types readonly
so user can not create,update or delete timesheets create by leaves
task-2888607
closesodoo/odoo#96359
Related: odoo/enterprise#29678
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
_* = project_timesheet_holidays
Currently, if the timesheet is associated with timeoff and it is deleted, a
user error occurs.
In this commit, RedirectWarning will appear instead of user error, so it can be
redirected to the timeoff linked to the timesheet.
task-2888607
Part-of: odoo/odoo#96359
I do not see a good reason why height, width, length are integers.
It has been introduced in 2015 here: 2ff3749064https://github.com/odoo/odoo/pull/9994
Having float is better : it's allow more expressiveness and is less prone to errors for our users.
closesodoo/odoo#85268
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Prior to this commit, some scss selectors where duplicated
(`.select2-results`) and where not targeting the right element.
This commit also changes the css variables name based on the right
structure : --component__childItem-property--state
task-2710677
closesodoo/odoo#105118
X-original-commit: 25a7ca929b4342fe7b2941f941a001e0dd0370e9
Related: odoo/enterprise#33689
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
*: test_website, website, website_blog, website_event, website_forum,
website_sale, website_slides
Reverts this refactoring because it breaks multi-tenancy: if several
databases run on the same server and different modules are installed
in each database, the global variable becomes wrongly populated.
Steps to reproduce:
On runbot:
- Go to the `-base` URL or simply select the `base` DB
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model
On Odoo.com saas DB:
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model (unless you installed
each and every module related to the search snippet)
Locally:
- odoo-bin -d first -i website --stop-after-init
- odoo-bin -d second -i website_blog --stop-after-init
- odoo-bin -d first,second
- Try to use a search bar on "first" database (using "Search in
Everything") => it tries to access the blog models.
Revert of PR: #98423
opw-3045092
closesodoo/odoo#105077
X-original-commit: 5806f71af1b6f44aac063f7e504be736300f699d
Related: odoo/enterprise#33669
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The scheduled end date of a work order is not consistent with its
scheduled start date when starting the work order
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Create a manufacturing order for any product, with any component and
a work order
4. Confirm and plan the MO
5. Edit the scheduled start date of the work order to the next working
day and save
6. Start the work order
7. The scheduled start date changes but the scheduled end date doesn't
Solution:
When starting a work order, change the `date_planned_finished` according
to the new `date_planned_start`
opw-3005767
closesodoo/odoo#105055
X-original-commit: 0edeed2ff07693933aaf1a17958b5c5fc9a65c35
Related: odoo/enterprise#33661
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
`action_view_pos_orders` is unused and it is incorrect
because it generates a wrong domain (`('id', 'in', pos_order_ids)` where
`pos_order_ids` is a list of tuple(<id>, <display_name>))
Part-of: odoo/odoo#104838
Reading only 'id' with `search_read` is equivalent to use `search` but
complexify the result usage. Fix all these bad usages.
Part-of: odoo/odoo#104838
Co-authored-by: Julien Castiaux <juc@odoo.com>
Change isolation link unit tests to cover both deleteBackward methods :
- deleteBackward via direct contenteditable command
- deletebackward via input event ( mobile )
task-3054245
closesodoo/odoo#105066
X-original-commit: 123051fc8b61e27fc8e39f0fed02a58186fca7e3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sometimes the link isolation was broken when
the editor rollbacked some browser behavior :
the content editable was reset on the all editable.
And thus the cursor was able to get out of the
isolated link creating issues.
task-2957000
X-original-commit: 0a04ef6c2617741b90c151c367c1731ed180ad70
Part-of: odoo/odoo#105066
We avoid listening to mutation during test selection "[]" rendering.
Those rendering would be registered by the editor and sometimes wrongly
put the editor in rollback mode.
X-original-commit: cb9348e3f7a95d787337b5c3c8fbba5cf6c9e7c4
Part-of: odoo/odoo#105066
Paste a url in the editor from the URL bar of the browser. If you then
select it all and paste another URL in its stead, the zws inserted by
the sanitizer when deleting the selection ends up in the URL.
This is because the sanitizer moves downward into the DOM tree,
therefore change the link URL before removing the zws in its text child
node. To make sure this can't ever happen, we now remove zws from URLs
when parsing them from the link's text content.
task-3054233
closesodoo/odoo#105045
X-original-commit: c4c9627297c0e3e3977cbfd51129227f8ec1ce3c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Accounting app > Customers > Invoices
- Create invoice with customer and a couple of products
- In the terms & conditions tab at the bottom, add 20-30 empty lines
and then a heading (/h1-3) with some text. This insures that the printed
report will have more than 1 page.
- Go back to the Invoices list view
- Select the invoice + another random one > Print > Invoices
A traceback appears in _render_qweb_pdf: `KeyError: 'attachment'`
When printing more PDF files at once, several condition have to be
respected in order to also save them as attachments. If the conditions
fail, the PDFs are not saved as attachments and a default dict is
returned, containing the undivided content stream.
The traceback is raised because later we check if an attachment already
exists, even if the files were not saved.
Bug introduced in https://github.com/odoo/odoo/pull/97050.
Solution:
If the conditions fail, add {'attachment': None} to the return dictionary.
opw-2882507
closesodoo/odoo#104916
X-original-commit: 8e3db19f881e3fb72d8a31f56d7cea8876dc57a4
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Steps to reproduce :
In a Manufacturing Order, update quantity (product_qty)
Expected behavior :
In the "Components" tab, "To Consume" column should update without Save
Actual behavior :
Due to "mrp_should_consume" widget not being reactive, should_consume_qty is not updated in the view until it's saved.
closesodoo/odoo#104364
Task: 2985735
X-original-commit: b3ec31d89eb635b555f77b3eb9ecaac4c65981e6
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, if a user creates a bill from a PO and confirms it.
A stock valuation layer is created. if the user sets the bill to drafts and changes
the product price. a new layer corrects the difference. if the user does
it again, the new layer ignores the previous correction layers, resulting in
wrong valuation.
This commit hides the 'Reset to Draft' button when there are correction layers
found.
closesodoo/odoo#103347
X-original-commit: d3d41c7679f9068a7b986925b15d0d7670233bfc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the issue:
- Create a product P
- Enable packaging on Purchase
- Create a packaging PA such as 1 PA of P = 70 P
- Create a PO with P and set a quantity of 250 with PA as packaging
Bug:
A Warning was raised saying that we should purchase 280, PA was removed and a
quantity of 249.9 was set.
PS: PA was removed because the quantity was changed and function _onchange_suggest_packaging was triggered
opw:3007165
closesodoo/odoo#105065
X-original-commit: a9514d69006c8a389b64550dbcbf30b19160c300
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In c989ff339d, odoo module errors now
block the interface with an error message. Currenltly, in order to
support lazy-loading scenarios, the way that scss compilation errors are
displayed to the user is by attempting to import a module that may or
may not be present, and doing nothing when it's not present.
This commit fixes that by instead, writing the compilation error message
to a global variable, logging it in the console, and creating a service
that will display that error on start.
closesodoo/odoo#104671
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce the issue:
1. In Settings, enable UoM
2. Edit the UoM 'Dozens':
- Rounding: 1.0
3. Create two products P_finished, P_compo:
- P_finished:
- UoM: Dozens
4. Create a BoM:
- Product: P_finished
- Qty: 1 x Dozens
- Compo: 1 x P_compo
5. Create and confirm a MO for 1 x P_finished
6. Edit the MO:
- Set the producing qty to 1
- Set the 'to consume' quantity of P_compo to 1.23
Error: the consumed quantity of P_compo is still 1.0 (it should be
1.23). If the user tries to set the quantity to 1.56, the consumed
quantity will become 2 (also incorrect, should be 1.56)
The UoM used to round the new consumed quantity of the component is
incorrect. Considering its definition:
https://github.com/odoo/odoo/blob/0fdd35cfb5c7145b3a7a855956004e38de7c6e2a/addons/mrp/models/stock_move.py#L164-L170
the UoM of `unit_factor` is `UoM_sm / UoM_mo`. Therefore, in
`_update_quantity_done` (see diff), when we compute `new_qty`, we have
(in terms of UoM) `(UoM_mo - UoM_mo) * UoM_sm / UoM_mo`. So, the value
is already in the correct UoM (`UoM_sm`) and we just have to round it
based on that UoM
OPW-3016837
closesodoo/odoo#105059
X-original-commit: 90c245a3785a22c9fcbe7dcc2d06ae4205b4fdc9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- go to Project app;
- go to the 'Project Updates' view of a project.
(project must have task with milestone which has a quantity delivered when the goal is reached)
Issue:
For some quantity percentages, the display of the number of decimals is not correct.
Example: 55, 58, 57, 56, etc. (but not 59, 54, etc.)
Solution:
Use the possibilities of the QWEB to perform a rounding.
Remark:
Widget percentage doesn't work in this case (not a field tag).
`t-options='{"widget": "float", "precision": 2}'` also not working.
`round()` method doesn't work too.
The method toFixed(n) rounds the number to n digits after the point and returns a string representation of the result. (https://javascript.info/number)
opw-3041813
closesodoo/odoo#105056
X-original-commit: fb3052787adf07d0db8e24e7977d0fd88518d0d7
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Previously, when gracefully stopping the server, incoming requests got
queued in the socket's backlog until the workers all finished their
requests, then the socket closes and backlogged requests get their
error response.
This would leave the system administrator with the awkward choice
between giving existing requests time to finish and not creating too
big a downtime for new incoming requests before forcefully shutting the
server down.
As the workers will stop accepting new connections on the graceful stop
call, we can close the socket so the binded address is freed as well.
This allows a cleaner graceful restart of the service as we can
gracefully quit the Odoo server, start a new server on the same address
and let the old service finish its requests for as long as we want.
closesodoo/odoo#104952
X-original-commit: 006a5fa1499dc44be9f2e285637dd0b6a771be16
Signed-off-by: Olivier Dony <odo@odoo.com>
Why traceback occurred:
When we open the task from the milestone dialog, the milestone dialog does not close,
but the component gets destroyed. And when we manually close the milestone dialog,
it tries to load the props. so the traceback occurred.
In this commit:
When the task is opened from the milestone dialog, the milestone dialog will be closed, and
before loading the pros checked whether the component is mounted or not.
Steps:
- Install the project app
- Active Milestones in setting
- Open the Project Updates
- Open any Milestones
- Click on the task stat button
task-3010877
closesodoo/odoo#105027
X-original-commit: 3f08ff262e2943f870e906e06ec90807f581183c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Commit [1] added a regular expression that looks behind to ensure a `-`
is present without capturing it. Unfortunately, the Positive Look Behind
regex (?<=...) is unsupported by Safari as of now (16.1, see [2]).
This commit replaces the regex by removing the '-' after capturing it.
Steps to reproduce:
- Use Safari
- Install website_event
- Try to edit any page with website
- "Invalid group specifier name" error appears
[1]: https://github.com/odoo/odoo/commit/5f1f082dbe268522f8fc7e63ad5f564b25020a22
[2]: https://caniuse.com/js-regexp-lookbehind
opw-3049537
opw-3023128
opw-3023329
closesodoo/odoo#105076
X-original-commit: 08413daa7b62539f86110575f1835d6db271ea10
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Increase code readabilty by replacing "if else" by ternary expression recommanded by python in this uses cases
closesodoo/odoo#104293
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit fixes the formatting of the note field in project
sharing wizard.
The formatting of the wizard broke after the merge of 16.0.
task-3010435
closesodoo/odoo#105054
X-original-commit: e64bb62173578f52efe9251675f17bb78fd6de29
Related: odoo/enterprise#33659
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
This commit introduces component hook useMessagingContainer,
which allow to lazily use messaging component in template.
This allow simplifing some code in container, and more notably
in child messaging components, as they can now define their
template in models.
Task-3055886
Part-of: odoo/odoo#105099
*: hr_holidays, im_livechat, snailmail, website_livechat
Clean template of discuss component templates, so that they
are more appropriately compact, which makes it easier to
read the layout at a glance.
Task-3055780
Part-of: odoo/odoo#105099
This commit simplifies discuss template by putting record accessors
in the context of template.
*: calendar, hr_holidays, im_livechat, sms, snailmail,
website_livechat
Task-3055022
Part-of: odoo/odoo#105099
Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore. Note that [1] was
actually not forward-ported here in 16.0 but now is via this fix.
E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).
Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working). This flow was
also not broken in 16.0 as the code was rewritten differently.
The work done at [1] actually needed some more rework than that to
handle two other potential usecases:
- If the confirm dialog handlers' promises are rejected, the dialog is
not closed (rightfully, like for example allowing to fill an empty
required input)... but [1] prevented to click on the button again
forever. With the same example as above, it can be reproduced: if the
RPC to clone the page fails, I cannot retry.
- If not both confirm_callback and cancel_callback were given, [1] only
prevented to multi-click on the related button (e.g. if you click on
"Ok", a RPC which takes 10 seconds is made, you click on cancel
immediately afterwards -> the dialog is closed while it should be
prevented (and would be if cancel_callback was given, following [1])).
That may not be entirely stable to make this change though but it
seems to make sense and be better (just keeping what [1] wanted here).
Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).
[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b
Closes https://github.com/odoo/odoo/pull/103712
opw-3033878
opw-3043224
opw-3046485
opw-3042542
closesodoo/odoo#105081
X-original-commit: 90b280c221f3c0819cb0b291e102f161fc47507a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the default order used in the project list/kanban
view is only `sequence` but if all projects have the same sequence.
This commit changes the default order to sort by `sequence`, `name` and
`id` as it is defined in the python model.
closesodoo/odoo#104986
X-original-commit: 25efb87f960380dac8093e018a3766bd5041cd0f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when we create a new task in project gantt
view, the default current user is assigned to the task instead of
corresponding user.
So in this commit, assign the default user along with current user.
task-2920824
closesodoo/odoo#104967
X-original-commit: ab0e072fda7c2dff4ee7916496edfb6da11019ff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
o_mail_notification should only be hidden when seen from the chatter.
At the moment, the notification is hidden everywhere in odoo and
after this PR the notification are only hidden in the chatter
opw-2720840
closesodoo/odoo#105075
X-original-commit: abddcf8bd4b0ba3d8d45ed1ba4e26c3e112b8edb
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce:
- on Ecommerce website Add an item to your cart.
- Billing/Shipping info > Stop on Payment page.
- Duplicate tab, On the duplicate, add more products to your cart.
- Go back to the original tab (Payment page) > Check out with Stripe.
- Stripe acquirer page does not reflect the updated cart amount.
- Complete payment > Website will say order is confirmed.
- Go to this SO in backend
Bug:
SO is not confirmed and Stripe status says there is a mismatch
because it did not take updated amount.
Fix:
double check the ammount before processing payment
opw-2978244
closesodoo/odoo#105060
X-original-commit: be9d2a57c4628fc867aefc932aaf8c503e76b60f
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Have the following taxes:
- Tax A: 15%, included in price
- Tax B: 21%, included in price
Create a product P with list price 115 and tax A
Have a fiscal positions FPOS configured with:
- Detect Automatically checked
- Country: Belgium
- Map tax on product: A -> B
Open a web shop session as guest, add P to cart
Go to checkout: Price total will be 115
Fill address details with Belgium address
Go to confirmation page
Error:
Price total will be 100. In the application of fiscal position the wrong
unit price is used
opw-2973879
closesodoo/odoo#105061
X-original-commit: 0a8394055221e48c610ad51eef21eb1a16f1e9f9
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Name field can return False, which is not compatible with a replace. We
therefore fallback on a void string, as already done in various other
report names.
Related to Task-2868153 (Mail: Allow multi-reports mail templates)
closesodoo/odoo#105042
X-original-commit: 1e223619e466792c9b073b302ebc9d68cabb9aac
Related: odoo/enterprise#33652
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Following recent changes in stable deleting/archiving product variants forbidden by
attributes exclusions, installing some modules after the sale app failed because
the product `product_product_4d` specified in `product` was deleted by the attributes
exclusions of the `sale` module.
This has been fixed in stable by removing all references to this xml_id.
Nevertheless, this bug showed us that the definition of attributes exclusion
for a product in another module than the one creating it is a bad idea, as it
modifies what's allowed or not with that product, leading to potential database inconsistencies.
This commit moves the exclusions targeting products from the `product`
module to the `product` module, to reduce the risks of other modules using/referencing
the deleted/modified products in a way conflicting with the exclusions.
opw-3040916
closesodoo/odoo#104020
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this patch, when doing an SMTP connectivity check, Odoo always checked if the current user with their current email address could connect.
That was inaccurate because:
1. If the `ir.mail_server` were configured with an email address as `from_filter`, that's going to be the address used to connect with the server always; never your user email.
2. If it were configured with a domain as `from_filter` and your user had an email from another domain, your outgoing emails are going to get wrapped into that domain (SRS-like). Again, the connectivity check wouldn't be imitating real world connections.
After the patch, both situations are taken into account when deciding the outgoing address that's going to be used for testing the connection. This will reduce false negatives when testing connectivity.
@moduon MT-1064 OPW-2942814
closesodoo/odoo#105033
X-original-commit: f1e5e8ca42fbab77649b95fd0b2d09c46f6878fc
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Fixes parsing error that happened when formulas of reports contained indentation (white space, end of line, tabs).
The formula was then not computed correctly and an unclear error message was thrown.
closesodoo/odoo#105028
X-original-commit: 631c1292042083a566072462aa788c6fc410925a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Fixes the problem that some syntactic sugar formulas were not updated correctly when changed in the xml of reports.
In particular, during upgrade of modules changes were not taken into account.
Concerned syntactic sugar formulas:
- <field name="account_codes_formula">
- <field name="aggregation_formula">
- <field name="domain_formula">
X-original-commit: de9bd10f6e49c529de0d9c835e7185ecb2e699e5
Part-of: odoo/odoo#105028
Kartik Chavda