Steps :
Install Field Service and Contacts.
Create a FSM task > Customer : Demo.
Note that the displayed address is his Demo's current one.
Click Navigate To : it points this same address.
Go to Contacts > Demo > change the address and return to task.
Note that the displayed address is his Demo's new one. (Or else refresh)
Issue :
Click Navigate To : it points the OLD address.
Cause :
action_fsm_navigate calls partner.geo_localize
only if partner has no geocoordinates.
Yet he still have the old coordinates.
Fix :
Call when the address changes and not in action_fsm_navigate.
closesodoo/odoo#84753
Opw: 2743926
X-original-commit: 0c01f2a22485328e32ff1741a3ba98446b539318
Related: odoo/enterprise#24456
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
When printing a delivery slip, if the delivered product is a kit
composed with a subkit, the products of this subkit won't be listed
To reproduced the issue:
1. Create 5 consumable products: 'Compo 01', 'Compo 02', 'Compo 03',
'Sub Kit', 'Super Kit'
2. Create two phantom-type boms:
- Sub kit:
- 1 x Compo 02
- 1 x Compo 03
- Super Kit:
- 1 x Compo 01
- 1 x Sub Kit
3. Process a delivery with 1 x Super Kit (the picking must be done)
4. Print the delivery slip
Error: The report only contains two lines, i.e. the name of the kit
('Super Kit') and the name of the 'direct' component ('Compo 01)
The issue comes from the SML used to define `kit_move_lines` (XML side).
It uses `has_kits` which only contains the top level kits' SML:
https://github.com/odoo/odoo/blob/1b1067b0cf2a3de2773915ff8205084492b1bbe3/addons/mrp/report/report_deliveryslip.xml#L6-L9
This is the reason why the SML for Compo 02 and Compo 03 are not listed
OPW-2740247
closesodoo/odoo#84735
X-original-commit: 586f900433eb09ee04d0ed073acfdcfa0fc59d58
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When we are setting currency_id, if we delete it altogether,
we get a traceback.
Task - 2704297
closesodoo/odoo#84741
X-original-commit: 870577981e02fce4a3b1b1df200d2a81c814f5e8
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The rpm package failed recently on a file name containing a space.
This issue is fixed by protecting file names with double quotes in the
installed files list.
Also, during this fix, it was discovered that the bdist_rpm is
deprecated in setuptools [0].
For that reason, the rpm is now generated from the package.py script.
[0] https://github.com/pypa/setuptools/pull/2780closesodoo/odoo#84665
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since the refactoring done on ir.qweb at [1], directives are more
autonomous, so `t-att`, `t-options`, etc are no longer evaluated by
other directives. These directives are also ordered.
Before this commit, when directives such as `t-snippet`, `t-install`,
etc were called, the other attributes had already been consumed. Indeed,
at the end of the compilation, tags should no longer have attributes,
`t-att` removes all statics ones. So relying on the `string` attribute
in `t-install` was broken and so the snippet names for the snippets to
install from the editor panel in edit mode were gone.
This commit fixes that by evaluating those specific directives earlier.
[1]: https://github.com/odoo/odoo/commit/e830953570d5f28aee9bdcdf97af18d3e3246030
task-2762377
closesodoo/odoo#84752
X-original-commit: f40b9522f20d5fbfe62c3718566c1d92ccfad75b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, during edit mode, the user was able to interact with
form elements. In 13.0, it was somehow prevented by some JS code by
losing the focus immediatly but it was not enough: if typing quickly the
user was able to type text. But the real problem was the user seeing the
input focused for half a second then not anymore, making him think a bug
occured. Worse, the datepickers of the form snippet were able to be used
entirely during edit mode, making the user think it is possible to
configure a default value (which was not true in 13.0). In following
versions, the bug is indeed worse as it messes up with the default
values configuration. In 14.0, it is apparently possible to type
normally in all of those inputs... although still ignored on save. In
15.0... the 13.0 behavior of losing the focus immediatly is back though.
This commit fixes that via CSS, still allowing a click on the elements
to be considered as a click on the parent, but preventing to focus our
snippet inputs (this fix is limited to our own snippets as stable fix).
Note: the 13.0/15.0 JS code which prevents the focus right now was not
found (if it even exists...) but it would not be ok to remove it in
stable anyway. More investigation and review will be done once this
reaches master.
task-2523496
closesodoo/odoo#84717
X-original-commit: ab9fbfb43365fcd39cc782f94b74911155e3f73e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To reproduce the issue:
- create a cash basis tax, with different account and tags for invoice and refund
- make an customer invoice using this tax, post it, and register a full payment for it
- unreconcile the payment
=> Two cash basis moves have been generated: one for the initial reconciliation, and another one reverting it when the reconciliation got cancelled.
=> Bug: the reverse move uses the refund repartition, while the original one is using the invoice's one, so they don't sum up to zero. It's wrong: since the reconciliation got cancelled, we want the impact of the invoice on our tax report to be 0 again, just as if it was brand new.
closesodoo/odoo#84727
X-original-commit: b9e94def7dd84a6a02ddb76959400b8d8fbc5025
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
d22cd54 introduced the fact that when doing a full refund of an invoice, the same account was used as on the original invoice, instead of the one on the tax refund repartition lines, though the tags were still the refund ones. This is wrong.
Also, it restored an inconsistent data setup in a test, while the current version was actually correct.
X-original-commit: 031f017a5a696874065cb5873f2fecd5c4b177ed
Part-of: odoo/odoo#84727
Before the fix:
When we don't have enough credits for Bill Digitalization,
try to scan expense from expense app (or upload bill from billing).
Instead of getting 'Not enough credits for Bill Digitalization',
we are getting 'Odoo Client Error'.
That is because messageIsHtml is no more prop to component 'Notification'.
closesodoo/odoo#84701
Signed-off-by: Arnaud Joset <arj@odoo.com>
This commit makes it possible again to click on a pivot cell to check
where the data comes from.
TaskId-2760356
closesodoo/odoo#84252
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When performing a picking with a package, the source location of the
package level may become incorrect
To reproduce the issue:
(Use demo data)
1. In Settings, enable:
- Packages
- Storage Locations
2. In Operations Types, edit "Internal Transfers":
- Enable "Move Entire Packages"
3. Create a storable product P
4. Create a receipt R with for P
5. Put 10 P in pack and validate R
- Let be PK the package generated/used
6. Process an internal transfer with PK
- The destination location of the package level is WH/Stock/Shelf 1
Error: Once the picking is validated, the source location of the package
level is "WH/Stock/Shelf 1". This is not true, it should still be
"WH/Stock"
The compute method is incorrect. It uses the package location to define
the source location of the package level. However, once the picking is
processed, this package has moved so using its location to define the
source location doesn't make sense anymore.
OPW-2754179
closesodoo/odoo#84709
X-original-commit: 239898ed699d98ff185f6a18fc5a8529e126cecb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
decimal places while we compute stock_quants.
closesodoo/odoo#84708
X-original-commit: fba9c9f32cb3d53841946588a999998f6c936e26
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
*: account, purchase, sale
Aim of this commit :
Get multiple pdfs reports to be more easily read, such as :
- pro-forma invoice
- quotation/order
- purchase order
- request for quotation
- invoices
After this commit :
Spaces have been added in order to improve readability
closesodoo/odoo#82277
Taskid: 2712478
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When a quant is creating, for instance thanks to an internal transfer,
some of these computed fields will have an incorrect value
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update P's quantity: 100 P in WH/Stock
4. Process an internal transfer
- From: WH/Stock
- To: WH/Stock/Shelf 1
- Operations: 10 x P
5. Consult the on hand quantities of P
Error: There is a new line with 10 x P in WH/Stock/Shelf 1, which is
correct. However, the Counted Quantity field is defined and equal to 0,
and so does the Difference field with a value of -10. These two fields
should not be shown.
When validating the internal transfer, a new quant is created for the
location "Shelf 1". However, there isn't any value for the field
`inventory_quantity_set`. Therefore, at the end of the transfer
validation process, when the `flush` method is called, since
`inventory_quantity_set` is a computed field, its `compute` method is
called and define the value to `True`:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L134-L136
This explains why, on front-end, the Counted Quantity and Difference
fields are displayed.
OPW-2733937
closesodoo/odoo#84679
X-original-commit: c519e26adec85025f40f78c59a05b2385377fb5d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Add "Stress Days", days where employees are *not* allowed to request
a time off. Time Off officers are still allowed to request holidays on
those dates.
closesodoo/odoo#79280
Taskid: 2679873
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
By default, dialogs are hidden in tests, s.t. we don't see them
flicker when running the test suite. There is a css rule to hide
them, only if there's no "debug" classname on the body.
This commit toggles this classname when a test is run with
QUnit.debug.
closesodoo/odoo#84694
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When the current app doesn't provides menu-items (or the user doesn't
have the rights to access them), the mobile burger menu should fallback
to the user menu instead of an empty one (like on the App Switcher).
Steps to reproduce (on mobile):
- on a newly database, install only "notes" app
- connect as 'demo' user
- open the notes app
- open the burger menu
=> as there is no submenus, burger menu is empty.
task-2345001
closesodoo/odoo#84692
X-original-commit: odoo/enterprise@f8e85c39e6
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
I want to customize the value when creating the stock move but with the
old code I can't do it. So, I add you a hook method. Look it will be
more professional and good for developer
closesodoo/odoo#84255
X-original-commit: 682030f10da19e51ab28f8adcfa39de4b872fed3
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Documentation structure were modified to point out to a new subtree:
content/applications/general/email_communication/email_server
Related task:2619564
Documentation PR:1092
closesodoo/odoo#84617
X-original-commit: 10e3d3dc861d22938c92a2b4016be4f2862630c2
Signed-off-by: Vergote Baptiste (bve) <bve@odoo.com>
How to reproduce the bug:
- Install the mrp app
- Enable debug mode
- Go to Settings -> Groups
- Add Marc Demo to Administration/Settings group
- Log in to Marc Demo
- Click on the Settings App
Bug:
If, as a basic user, you are added to the Administration/Settings group,
you won't be able to open the Settings module. If you look closer at this group,
you will see that the MRP administration group is not inherited when you install the
module.
closesodoo/odoo#83118
Opw: 2697030
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Purpose
=======
Allows the user to easily import mailing contacts.
Specification
=============
Add a button "import" on the top of the mailing contact list view. This
button open the wizard <mailing.contact.import>.
So the user can select the mailing list and import his contacts with a
text field, one line for each contact.
Task-2703521
closesodoo/odoo#82333
Related: odoo/enterprise#23263
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
Since 576556d846 we merged the list
coming from the context key default_list_ids and the list given by the
user in subscription_list_ids. It worked well because the 2 fields
"list_ids" and "subscription_list_ids" were not in the same view at the
same time.
But if we want to create from the backend <mailing.contact> by giving
a value in "list_ids", the context key "default_list_ids" must be
ignored (like standard Odoo fields).
Task-2703521
Part-of: odoo/odoo#82333
Current behaviour:
- Time in pivot view of report in attendance is in decimal hours
(e.g. 90 minutes is noted as 1.5 instead of 1:30)
Behaviour after PR:
- Time is noted in proper time manner
opw-2752651
closesodoo/odoo#84682
X-original-commit: 6f6a4b1a04a3ab83056f3cb58417eae53acebab5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since [1] the product search from website did not match the content of
the product internal note anymore.
After this commit the product search from website also matches products
if the terms appear in the product's internal note.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
opw-2715647
closesodoo/odoo#84675
X-original-commit: 0f40c3754bfa9dc14e1e15a137b7c2bdf6230a9c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Based on the po/pot files generated from odoo,
reorder the translations + remove the unused one.
closesodoo/odoo#84677
X-original-commit: 08c7503c7a0d25e00f26ec1fc0b6eede23fe71dd
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Set a language which use ',' (comma) as
decimal separator (eg French)
- Make a Vendor Bill for any product at any price.
If the partner's language use '.' (period) as
decimal separator (eg English), the field
amount_by_group is formated whit period, while others
are formated with comma. They should all be formated
with comma.
- Now print the Vendor Bill
The same issue is occuring.
With Customer Invoices, the issue is the same on
the form view, but not on the printing, where all
the fields are formated with period, as set in the
partner's language.
After this commit, we format all the fields
regarding the environment's language on the view form,
either in Vendor Bills and Customer Invoices,
and we formating the printed bill/invoice regarding
the partner's language
opw-2735698
closesodoo/odoo#84666
X-original-commit: bb029a476a04b7d41ea1f585274d24f581b4003d
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Before this commit, if we try to merge crm leads and few of the
details are not available, traceback was thrown. For ex-
- When lead does not have a company or the company does not have
currency set
- When the visitor name is not set
This commit fixes both of the tracebacks and thus allows users
to merge the leads in these cases.
taskID-2745017
closesodoo/odoo#84656
X-original-commit: eda3f43dde8122aa5f572f57bf2c3c0d94abe1f2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit lighten payment onboarding form in order to take advantage
of the Stripe Connect Onboarding Flow. It integrates the Stripe
Onboarding using the IAP proxy.
Purpose
=======
Help users easily onboard with Stripe by using the Stripe Connect API.
Specifications
==============
During the payment onboarding, if the user selects Stripe, they will
start the Stripe Onboarding. (NB: The process uses a proxy that handles
the Stripe Onboarding calls and signs them with the Stripe Connect key)
1) A call is made through the proxy to get the Stripe account token;
2) A call is made through the proxy to get the Stripe account link which
contains the URL of the Onboarding;
3) The user is redirected to the Stripe Onboarding;
4) The user completes the Stripe Onboarding;
5) The user comes back to the acquirer form of Stripe and is able to get
their keys.
6) The user can directly create their webhook after having copied/pasted
their API keys.
During the website sale onboarding, the user doesn't go through the
onboarding wizard but is directly prompted to activate their account.
Note that the Onboarding status isn't stored in the database so there is
no call to Stripe API to validate the account status.
API Documentation :
- Connect Onboarding: https://stripe.com/docs/connect/standard-accounts
- Webhook creation: https://stripe.com/docs/api/webhook_endpoints/create
task-2685160
task-2691213
closesodoo/odoo#84639
X-original-commit: 085f4af4e57c43127413585a8df5b3aa47843339
Related: odoo/enterprise#24376
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
This commit adds payment icon sequence to display the icon in a more
famous-more visible order.
task-2685160
X-original-commit: d11ff9eda43c390f584a148a956f7bc505007765
Part-of: odoo/odoo#84639
When the snailmail API-call timed out, the SnailmailLetter.state and SnailmailLetter.error_code were not changed, which resulted in an infinite loop of retries via the "Snailmail: process letters queue" cron job.
This commit changes this behavior: On a timeout the SnailmailLetter.error_code is changed such that no retry happens. Following stable policy, no timeout error is added, but 'unknown error' will be used. Preventing retries on timeout is mandatory as timed-out request are indeed processed by IAP and customer credited.
closesodoo/odoo#84263
X-original-commit: b3c46e8050e9405e69cfbe9c49706a22007e10ba
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Zians Dominik (dozi) <dozi@odoo.com>
PURPOSE
When we made the b2b on Time Off, we designed the allocation settings to be like this :
1. Allow Allocation : NO (stop here)
2. If YES
Can the Employee requests Allocation himself ?
2.1. NO (stop here, cause the HR will create the allocation and it will be automatically accepted)
2.2. If YES
Who will approve the Allocation made by the Employee ?
2.2.1. Nobody, it's directly approved
2.2.2. The time off officer must approve
2.2.3. It's SET by the time off officer.
In the day to day live, the case 2.2.3. never happen. It's the same settings as 2.1. "the employee will not make an allocaiton request, it will be the HR officer"
In fact, nobody understand what is behind that settings and the technical code behind it seems obsolete.
SPECIFICATION
1. Remove the "set by time off officer"
2. If Employee Requests is set on "Not Allowed", don't display Approval : https://tinyurl.com/yxwwql83 if an allocation is created, it will be done by the HR officer and automatically approved.
task-2705150
closesodoo/odoo#81914
Related: odoo/upgrade#3247
Related: odoo/enterprise#23105
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Observed behavior
When logged in as another employee than Mitchell Admin (or equivalent
employee who has an ID of 1 in the database), the number of days
allocated and displayed in the time off type name when creating a time
off from the dashboard is by default the one of Mitchell Admin.
Expected behavior
The allocation in the time off type should reflect the allocation of the
employee
Steps to reproduce
1) Create a new user and an employee for this user
2) With the credentials of this user, create a new time off from the
dashboard calendar
3) The default time off type has the allocations of Mitchell Admin (or
equivalent employee who has an ID of 1 in the database)
task-2712193
closesodoo/odoo#81213
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To reproduce the issue:
(Need purchase,sale_management)
1. Create a product category PC:
- Costing Method: FIFO
2. Create a product P
- Type: Storable
- Category: PC
3. Create a PO with 1 x P @ 10 + Receive P
4. Create a PO with 1 x P @ 0 + Receive P
5. Create a SO with 1 x P + Deliver P
6. Create a SO with 1 x P + Deliver P
7. Process a return for sold P at step 6
8. Open the valuation of the return
Error: The value is 10, should be 0
In `_get_price_unit`, `price_unit` is defined with the correct value
(i.e., `0`), but the if-condition of the `return` is not respected, so
another value is used
OPW-2735502
closesodoo/odoo#84649
X-original-commit: 3ad98f7da027829c563fb9ebc86e8299721743db
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
For the moment we cannot groupby an inherited field (which is therefore related) in a graph view, so it is counted as being non-stored.
Because in the `_normalize` function we do not process fields that are not stored, whereas like here
https://github.com/odoo/odoo/blob/d679cd0d8ba9a2420e81a42a698763e9be2327e1/addons/web/static/src/legacy/js /control_panel/groupby_menu.js#L45-L49.
Typically when a field has store=False but sortable=True it is inherited from a stored field, so it can be sortable
So we have to use `sortable` instead of `sort` to make it consistent.
opw-2733133
closesodoo/odoo#84612
X-original-commit: ce2a538e2988aef572171f783891cd6ee644ad14
Related: odoo/enterprise#24351
Signed-off-by: Achraf <abz@odoo.com>
export_icon_to_png sometimes failed because PIL's getbbox returned None.
This fixes it by not using a default color of (0, 0, 0, 0) when creating
the image but using the actual color of the image instead.
Also, the size of the image was wrong because of using the default size
when width and height are defined.
task-2761098
closesodoo/odoo#84638
X-original-commit: efcb432f4c459b2d2d819c3aed7d63d53fc93809
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
Bug
===
If we
1. Open a lead with an email but without partner
2. Set a partner without email on the lead
3. The warning "The email will be propagated" is visible
4. When saving the form, the email is not propagated even if the
warning message was visible
Solution
========
The reason is that, as the email was not changed, the inverse method
of this field was not called and so the email was not propagated.
The best solution would be to use "force_save" on those fields. But
this feature only works on readonly fields.
So, we simulate a real "force_save" on the email / phone, directly in
JS. That way the inverse will be called, and if necessary, the email /
phone will be propagated.
Task-2704904
closesodoo/odoo#84618
X-original-commit: 1d548c7eadcd25b97856c4769759358f86e00640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: flch-odoo <flch@odoo.com>
Previous implementation was generating an unoptimised query which
lead to unacceptable loading time on large databases.
task-2764954
closesodoo/odoo#84611
X-original-commit: aec71f39a7a7919c15d3ba49eabe6e5bf74d757f
Signed-off-by: Xavier <xbo@odoo.com>
Audric Onockx (auon)