* l10n_ae, l10n_ar, l10n_at, l10n_au, l10n_bg, l10n_br, l10n_ch,
l10n_cl, l10n_dk, l10n_es, l10n_hu, l10n_in, l10n_mn, l10n_nl, l10n_no,
l10n_pt, l10n_sa, l10n_se, l10n_sg, l10n_si, l10n_uk
Some localizations do not have any default account for tax closing.
This leads to the opening of a RedirectWarning when trying to do a tax
closing.
task-3082332
closesodoo/odoo#124003
X-original-commit: 14abe7acb11d522fb2b4a274ac0eb06d41e637ed
Related: odoo/enterprise#42071
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Prior this commit:
While sending mail through CRM, the mail body doesn't show message content
in the mass_mailing module.
After this commit:
User will be able to see the message content inside Mail Body.
Task-3245572
closesodoo/odoo#123963
X-original-commit: a4549981790a6aa85ff59ea5ec6157c3ec3cfda6
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
-------------------
- create two employees (A and B);
- create a user;
- add the user in Related User of employee A;
- remove the user;
- add the user in Related User of employee B;
- change the Work Email of the employee B.
Issue:
------
The Work Email of the employee A is also updated.
Cause:
------
When we add a `user_id` to an employee,
we update the `work_contact_id` field.
Fields `mobile_phone` and `work_email` are inverse fields.
When we modify them, the `_inverse_work_contact_details`
method is called.
We update the `work_contact_id` linked to the employee.
When we delete an employee's `user_id`,
we don't update the `work_contact_id`.
Therefore, when we update an employee's `work_contact_id`,
we call the `_compute_work_contact_details` method
method for all employees who have the same `work_contact_id`.
The result is that we modify the `mobile_phone` and `ẁork_email`
fields for all employees linked to the `work_contact_id`.
Solution:
---------
Differentiate the case where the `user_id` is `False` (>< `None`)
when it is modified and does not contain
a value to "synchronise" the `work_contact_id`.
opw-3338188
closesodoo/odoo#123965
X-original-commit: 85ab51c7cf7c8ee011a903a9460e2aff1296f215
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Since commit [1], the custom filter for website was disabled.
This commit restores the filter and adapts it for "Milk" redesign.
Steps to reproduce:
* Open the Website app
* Select the menu "Site" -> "Pages"
* Open the "Dropdown" in the SearchBar
=> Bug there is no filter for website
[1]: odoo/odoo@caef16ee4eclosesodoo/odoo#124042
X-original-commit: 9237ca777fb9c5e9bda03c2d0dbe0deed8e1b2e5
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Apply the same solution used in other tests with "test:hashchange":
```js
await testUtils.nextTick();
await legacyExtraNextTick();
```
closesodoo/odoo#124041
X-original-commit: 8bd9809bc4700637ffb26bbcfbd00c62b0dbd220
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In this commit
https://github.com/odoo/odoo/pull/121354/commits/7d1092ba0e970170ce66e77e6ddc4cab0e09563d
the forward-port automatically moved the test to `stock_delivery` but
the code change remained in `delivery`. Since it handles `stock.picking`
on a `sale.order`, and that `delivery` does not depend on `stock`
anymore, it should move to `stock_delivery` as well.
closesodoo/odoo#123993
X-original-commit: d5b64650d043f94f8e244c993eff36ed26a93a32
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Current behavior:
When creating a credit note from a PoS order, the credit note is not
linked to the invoice of the orginal order.
Steps to reproduce:
- Make an order in the PoS, validate it and invoice it
- Make a refund of this order and invoice it too.
- Go to the credit note, the original invoice is not mentionned in the
reference field.
opw-3150637
closesodoo/odoo#123976
X-original-commit: d3ff97f498e0fcc97ec32194988268a7e2afc631
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
The tooltip for the VIES vat check option on the res_config settings is
no longer relevant or accurate. This commit adds a new tooltip and a
translation term for it in the pot file.
task-3218194
closesodoo/odoo#123928
X-original-commit: 83810d56765f7bc8d8e4ddfce10acc0462a317a4
Signed-off-by: William André (wan) <wan@odoo.com>
This commit is avoiding the creation of the upselling
activity on the compute not yet saved,
on upselling a service product (increasing the qty_delivered)
and clicking outside of the list view containing the SOL(s)
on a SO, on a SO create before the install of sale_timesheet.
Steps to reproduce in 16.0:
1. Install sale_management,
2. Create product.template of type Service,
3. Sale & Invoice it,
4. Install sale_timesheet,
5. Come back on previous SO and modify
the qty_delivered of the SO of the product (increase it).
That will set the invoice_status of the SO to 'upselling'
and generating a next activity for the salesperson.
6. Clicking outside the SOL will pop a Warning saying:
"Activities have to be linked to records with a not null res_id"
Every SO pre-install of sale_timesheet that are in state Sale Order
allow the modification of the qty_delivered field due to the field
"qty_delivered_method" being set to "manual" instead of "timesheet".
Which is not the case in the SO created post-install of the
sale_timesheet module.
After the fix, the next activity will only be trigger when clicking
on the SAVE button of the SO.
PS: the steps and install of module make the test impossible.
opw-3293686
closesodoo/odoo#123877
X-original-commit: 448a261d21d0d8e12477d8efa2ba0dfbf29c4a56
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
**Summary :**
When using a great decimal precision, forecast_widget shows red
neverthless the available quantity is sufficient.
**Steps to reproduce :**
- In Settings >> Technical >> Database Structure >> Decimal Accuracy
- For usage __Product Unit of Measure__, set __Digits__ to **__6__**
- Create products of type storable :
- __Test Component__ with a __Qty on hand__ of **__76.6__** Units
- __Test Product__
- Create a BoM for __Test Product__, with Quantity set to **__1__** Units
- Add component __Test Component__ with Quantity set to **__15.32__** Units
- Create a MO for BoM __Test Product__ with a Quantity set to **__5__** Units
- Confirm the MO.
**Before :**
Neverthless the __To Consume__ qty is set to 76.6, which is equal to the
__Qty on hand__ of the component, the forecast widget shows red as if
there's an insufficient quantity of the component
**After :**
With help of the Odoo's __formatFloat__ method, we round the data used
in the comparison defining the __willBeFulfilled__.
The forecast_widget now display properly, taking into account the digit
precision setup in the database.
opw-3281588
closesodoo/odoo#123388
X-original-commit: 0d4b95e9d9d2218d6d9165f082e9f59d5025262d
Signed-off-by: Tiffany Chang <tic@odoo.com>
The aim of this commit is to make `TestAccountComposerPerformance` more robust.
Context:
In `TestAccountComposerPerformance` (account module), we are writing
on the field `checkbox_ubl_cii_xml`.
This field is instantiate by the `account_edi_ubl_cii` module which
might not be present.
This module get installed when `account` and `base_vat` are installed but
`base_vat` is conditionally installed.
(see `account/__init__.py` for the details)
We used this opportunity to also remove the call to `Form` as it wasn't
usefull.
Before the commit:
`TestAccountComposerPerformance` could fail in "weird" circumstance.
After the commit:
`TestAccountComposerPerformance` is safer
closesodoo/odoo#123218
Task-id: None
Signed-off-by: Laurent Smet <las@odoo.com>
before this commit, subject field in
email form view was short
and user has to scroll through
the field to see the full subject
after this commit, subject field is long
enough to see the content without
scrolling
closesodoo/odoo#123909
X-original-commit: 7b1732f1e13239191fcc3b9c467d6d1c343aa6bc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
=======
When you start a new trial of an app without demo data, you
want to have everything perfect and ready for your own configuration
closesodoo/odoo#122308
Taskid: 3328654
Related: odoo/enterprise#41423
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
before this commit, if tries to delete a user group
which is linked with a field in settings, ie, via
implied_groups in res.config.settings or used in the
field group, there is no restriction and user group
will get deleted.
and then if user tries to access any settings page
the traceback will be shown to user.
after this commit, on deleting any user group
which is linked with a field in res.config.settings,
a validation message will be shown to the user that
the group cannot be deleted as it is linked with
a settings field.
closesodoo/odoo#123905
X-original-commit: ef3dfd02012e16c88789137f5eb0ec49b22f4df8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
- Configuration -> Settings -> Activate multi-locations.
- Configuration -> Warehouses -> Three-step delivery.
- Generate a three-step delivery (like through a sale order).
- Select either PICK or PACK pickings.
- Print the delivery slip.
- There is a "warehouse address" field with the customer's adress in it.
It makes little sense to display the current warehouse for internal
transfers, as they keep being in the same warehouse after all.
This doesn't impact inter-warehouse transit as in this case, an outgoing
picking is done from one warehouse to the transit location and an
incoming picking is done from the transit location to the other
warehouse.
In both cases the addresses are correctly displayed and didn't use this
'warehouse address'.
opw-3335185
closesodoo/odoo#123903
X-original-commit: 4c5b08e89e7c623dbd34498739f52e3258d807f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Since https://github.com/odoo/odoo/commit/926c4d4769db1846d94e2ab5a3e9b02308b0b160
planning by workcenter no longer takes into account unavailabilities of
less than 1 day in month mode, leading to erroneous accumulations
because some calendar unavailabilities (for example from day 5:00 p.m.
to day+1 8:00 a.m.) are missing.
We return to the previous behavior by transmitting all the unavailabilities.
The planning by production no longer displays the unavailability of workcenters.
closesodoo/odoo#123898
Task: 3305266
X-original-commit: d7a803cfbed7aa28d0835f9db974802d4b6f77d1
Related: odoo/enterprise#42017
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Jean-Francois Aubert (ajf) <ajf@odoo.com>
- remove context injection added 6 years ago
(2dab340717) but apparently never
used, if it's needed in the future it would be much cleaner to
extract the context(s) into a method and allow overriding that
- filter taxes just once, rather than filter then re-add
- also keeps recordset order which is probably useless but can't hurt
closesodoo/odoo#123651
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Let's consider an analytic account AA linked to customer invoices
- Open AA and click on the smart button Customer Invoies
Bug:
The field customer was not displayed in the account.move list view (same for Vendor Bills)
opw:3179200
closesodoo/odoo#123382
X-original-commit: 8ab9798269513a8bedee7874d1305b1a71b29052
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This PR adds several UX improvements :
- Timesheet smartbutton : Get weekly view instead of daily
- Attestation (N) : Fix displayed year
- Remove demo profile picture for Marc Demo to allow the new one
- Employee tree view : Allow more flexibility in terms of what you can show and hide on the tree view
task - 3299145
closesodoo/odoo#120659
Related: odoo/enterprise#40766
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this pr the label and the field were way too close, by adding a padding
start the setting become way more readable.
closesodoo/odoo#123887
Task-id: 3338500
X-original-commit: 33d2cf77434c27f3ac382dc45888f7824dbb6bb5
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this PR, it wasn't possible to add a custom margin bottom into specific paperformat args.
closesodoo/odoo#123872
Task-id: 3171683
X-original-commit: 0ea1af531ce8887434893f670b1c1e9f075e88c3
Related: odoo/enterprise#42004
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
So that we can in the future harmonize more easily the discount
computation between sale, point_of_sale, e-commerce, ...
closesodoo/odoo#123849
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this PR, there was a button in the onboarding dashboard to do a bank
synchronisation. But this step in the onboarding is not useful in invoicing app.
It is only relevant for enterprise accounting.
So this PR remove the step from the onboarding panel
closesodoo/odoo#120678
Task-id: 3302325
Signed-off-by: William André (wan) <wan@odoo.com>
if a recordset containing more 1 record calls _l10n_th_get_branch_name, it will proudce an error
closesodoo/odoo#123857
X-original-commit: 73adf34a1a7cc9c9fdde9303f5462ead4ec1cc7f
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Currently, on a multi-company environment with different website domains set, the terms and
conditions web page, which should be company-specific, are not correctly "pulled" if you check a SO
This was due to the website override that searched for a current_website, even if none was set on a
SO, thus setting the website url instead of the company one.
opw-3239061
closesodoo/odoo#123855
X-original-commit: ac5c042d3b1e0774ad430a66142437fc8db2fded
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Before this commit, after a save, we didn't remove the changes in
x2many fields (StaticList). As a consequence, if save was called
twice on a record with changes in a x2many, those changes were
sent twice to the server. In particular, if those changes involved
a command 0 (create), the record was created twice.
To reproduce the issue, go to a sale order, add a line, select a
product, click out to validate the row, then click several times
on the product. As you clicked several times, several doAction are
asked to the action service. For each of them, the form view is
asked to save its changes, and thus the same row is created multiple
times.
After this fix, the changes in x2manys are cleared after the first
save, so there's no change the save for the subsequent calls.
opw-3268947
opw-3324848
closesodoo/odoo#123851
X-original-commit: 9073304660ee64c7051b7ed86f8fa3513fe6ba7a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The web client expects the selection key to be at least an empty array.
(never false), like for a normal selection field, and so if the selection
has been created without an option, it crashes in the list view.
For consistency, we also set an array when there are no tags.
Task-3340671
closesodoo/odoo#123844
X-original-commit: 2e38397c2cfe0e4ed501d4ce7b98f0c47fe6c344
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Following https://github.com/odoo/odoo/pull/123266 that removes
some vertical spacing between messages.
The date text on squashed messages was increasing size of messages
that fits on a single line.
This commit fixes the issue by slightly reducing the size of date
text in sidebar, so that when hovering messages it doesn't affect
the size of messages.
closesodoo/odoo#123799
X-original-commit: 454d250e6c88b09d616d4d3404204d57addf8b28
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when hr was installed and Demo clicks on avatar
of Mitchell Admin, open chat failed due to access right exception.
This happens because open chat works only with internal users, and
when we don't know whether the partner has an internal user, we have
to check whether there's a user linked to this partner.
Doing `searchRead()` without passing any field triggers this missing
access right for some reasons.
Only the knowledge of an existing `userId` is enough, so we
can actually just make a `search()` to get the user id. This won't
trigger the access right exception while giving the user id of
the partner if this exists, thus proceeding with open chat request.
closesodoo/odoo#123796
X-original-commit: 2f6dc5f4222d380cf77c6660ccce8b7381e0e64a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
before this commit, if user search with full group
name in the search view of res.groups, currently
it returns no results.
* open groups menu
* search for Sales / Administrator
* will return no result
after this commit, searching a user group with
full name with return the corresponding user
group.
closesodoo/odoo#123723
X-original-commit: 6ef080a4818dd0bb85aa4ef257900522d9e9fbd6
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This will remove the necessity to patch component, and remove
duplciation between discuss and chat window.
Part of task-3265211
closesodoo/odoo#123454
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Run `odoo-bin help`, you'll notice that some descriptions are missing,
this commit fixes that.
Run `odoo-bin shell --help`, you'll notice that the `usage:` line says
`odoo-bin [options]` instead of `odoo-bin shell [options]`. Other
commands that depend on the server cli are broken too. Fix those too.
closesodoo/odoo#121085
X-original-commit: 9c6bac741ff437564e7dbe4d0aa8dbd307b71f8d
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When a portal user asks a question (e.g. on the Help demo forum) and
go back to the forum's home page while their post is to be validated
before they can post again, they're hit with a traceback (because the
offset argument type is incorrect).
Probably coming from switching bootstrap version.
Task-3347773
closesodoo/odoo#123831
X-original-commit: b14edd74d00c0b0054827563f032f2c384503360
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce
==================
- Have at least two warehouses
- Go to products -> Acoustic Bloc Screens -> Forecast
- Switch warehouses
- Refresh the page
Cause of the issue
==================
When reloading the page, the action is restored from the router state
(the URL). This means that the context isn't restored. In that case,
`originalContextAction.active_model` won't be defined. We then try to
use `originalContextAction` as if it was a string. But in this case,
it's an object `{active_id: ...}`.
opw-3301164
closesodoo/odoo#123812
X-original-commit: 6205a3b85b6551393c9ed33d0213cff9bc693ba3
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
An error is thrown when displaying the invoice analysis with a group by
on payment status when there is at least one invoice partially paid
Steps to reproduce:
1. Install Invoicing
2. Open Invoicing and partially pay any invoice
3. Go to Invoicing > Reporting > Invoice Analysis
4. Group by custom field: payment status
Solution:
Use all the possible payment_state values of account_move for
account_invoice_report
opw-3213576
closesodoo/odoo#123777
X-original-commit: 0e063bc142f13456935263caa07e6d840c1852f9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Since [1], the `mail.record/insert` notification is not
sent to the livechat visitor.
Since [2], this notification is not listened by the
notification handler either.
This PR fixes those issues in order to make message update
instantaneous on the public livechat.
1: https://github.com/odoo/odoo/pull/120018
2: https://github.com/odoo/odoo/pull/120893
task-3349454
closesodoo/odoo#123728
X-original-commit: 6f456e3b591ebc86502e4be65768042cc223c3db
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Debondt Didier (did) <did@odoo.com>
When _get_rule does not find any rule, it returns False. This
could create some tracebacks as we mostly expect a stock.rule.
It will give:
if False in <recordset>:
Hence a traceback:
TypeError: unsupported operand types in: False in stock.rule()
By applying these changes will resolve this issue.
Sentry-4206998573
closesodoo/odoo#123194
X-original-commit: d6a0b9810ffc7fad68ebf7b13902747d43024455
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
With MX edi company setup
Create an invoice, validate cfdi
Register payment, validate cfdi
Action > Send receipt by email
Issue: payment xml is missing from email composer
opw-3289582
closesodoo/odoo#123168
X-original-commit: ed6c3c3a4a6c5c685e709734c536a5e4252b4eb8
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Incorporate Luis Manuel (LuisMzz) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#123804
X-original-commit: 5f040ad7a7eb98c572f847d7e936d1577d70942f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this pr, it was not possible to do a search on the description of the
taxes. I've added the search filter for the tree view.
Also correcting a forgotten "or" in another search view and a missing uppercase.
closesodoo/odoo#123773
Task-id: 3332762
X-original-commit: 5e2e52f10131f0de19638c47347dbcc445a8c531
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose:
When the applicant is unarchived, they are automatically set back to
first stage. This is done automatically. In case there is automated
message post configured for that stage change, it will send the mail to
the applicant. We want to avoid this.
After this commit, the automated message related to the stage change
will not be posted in case the applicant has been just unarchived,
even if it is configured for the stage.
task - 3267915
closesodoo/odoo#120506
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The translation of input "default values" is allowed only when
`type="text"`. However, email field values are translatable because of
strange behaviour:
- Go to website (Edit mode) > Add a form block.
- Select the existing email field > Change label position > The input
is transformed into a `type="text"`.
Each time a "non-custom" field is re-rendered, The `_getActiveField()`
method is obtaining field related data from the database, including its
type, which changes it back to the original value ("char").
The goal of this commit is to fix this behaviour using `_getFieldType()`
to set the right field type instead of the default one.
task-3247520
closesodoo/odoo#123819
X-original-commit: caf6183c2a46ee1843b4df902fe0a96dfe3740d0
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Current behaviour:
If in 1 SO we have 2 service lines, each making their own project (for
ex: 1 with a template project, the other without), these 2 lines are
present in both project profitability report, skewing the margins,
as costs calculated on a per-project basis, while sol are aggregated.
Expected behaviour:
Don't include services that have their have another project than the
current one in the profitability report. (Project profitability `A`
shouldn't show services that are linked to project `B`).
Steps to reproduce:
- Install Sales, Project, Accounting, Timesheets
- Activate Analytic Accounts in Settings
- Create a project template
- Create 2 service products, both create a Project when confirming
the SO, one has no project template, the other has a template (the
one we create just beforehand)
- Create an SO, add the 2 lines, 1 for each service, 5 and 3
quantity respectively > Confirm SO
- Go to the Project's Update panel of either created project, we can
see that both lines are present. If you timesheet in a task in
either project, it will show up in both project's profitability
report.
Reason for the problem:
In some places, when we are constructing the domain that is used to
fetch the sale order lines that will be added to the profitability
items, we fetch the correct sol (only linked to this project), then get
the sale order linked to this line, and we search all lines related
to that SO (so we included products that are not services, for
example materials necessary for a service). This flow includes lines
that may be linked to other projects.
Fix:
We fetch SOL linked to the current project or that have no project
(for materials).
⚠️ **known limitation** Material lines are shared between
projects (because of `('project_id', '=', False)`), but that's
already current behaviour, even before this fix.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3300322
closesodoo/odoo#123803
X-original-commit: d0735a6168f5c019d5c03190f930882addd2496a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
While creating a new Manufacturing Orders, if user set value of 'date_finished'
field in the 'Work Orders' as null. As 'date_finished' field is not required,
user might have removed it by using other way.
Traceback will be generated.
'>' not supported between instances of 'bool' and 'datetime.datetime'
This commit will check the condition if the value of 'date_finished' is set or
not.
sentry - 4197616234
closesodoo/odoo#123802
X-original-commit: 11f6f2315159d321180e0fd6c9bc5747c5a7e781
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
This commit reverts a previous commit which allowed to
display the current stage when the state is changed.
The reverted PR: https://github.com/odoo/odoo/pull/119925
The reversion was done as what was implemented does not
follow the standard display of tracking messages and
because it doesn't look good in the chatter.
Task-3336184
closesodoo/odoo#123797
X-original-commit: eff511140175ba8224c2f9be59a798a3e1dee6da
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Dylan Kiss (dyki)