With this commit: we are adding basic search feature for binary fields,
custom filter will have binary fields and selecting binary field will
display 'is set', 'is not set' operators.
with this user can at least filter records based on whether binary field
is set or not set.
task-2512226
closesodoo/odoo#70149
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, in the expense module, demo expense products are more
specific to the expenses and label tooltip of the cost field doesn't
convey proper difference between fixed and variable cost of
expense products.
So in this commit, replace old expense products with new expense
products and recreate expenses and reports using these
categories(products). it will provide better experience on demo.
overwrite label tooltip of cost field in expense app to convey proper
difference between fixed and variable cost of expense products.
closesodoo/odoo#68955
Task-id: 2491238
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Make the email body take the entire space to avoid having some wasted space,
this will also make the user have more focus when designing an email.
Revamp the settings notebook page in order to give more clarity to the user,
and move some fields from the main form have been moved to this section to
have more space in the bottom for the email body.
In the mailing form, when the mailing is sent or is being sent, set fields
which are no longer useful for the user to change to readonly mode.
Add a wizard that enables the user to schedule a mailing, the schedule field is
still kept in the form for the user to be able to change the date when the
mailing is in the queue (if they want to send it sooner).
Display an action helper-style content when the email is empty, because,
currently, the user is left with a big white screen when the email has no
content which is not desirable.
Update the html_empty function to take into account style attributes to better
match the editor's void content.
Hide A/B testing fields from SMS mailing form view as these are not supported
for SMS marketing.
Task-2469409
closesodoo/odoo#68882
Ent-pr: https://github.com/odoo/odoo/pull/68882
Related: odoo/enterprise#18391
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488
closesodoo/odoo#68387
Related: odoo/enterprise#17316
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
======
During the development of the task #2169100, it appeared that the synchronisation
of a task's partner_id according to its project's partner_id and its parent's
partner_id was not very clear.
A first idea was to simplify the partner_id management: as it could be annoying
for the customer to see all the task's partner_id overriden after project's
partner_id modification, the idea was to just use the parent's parnter_id or the
project's partner_id as default value of the task's partner_id. Then, if the
partner_id of the project or of the parent is changed, there is no more impact
on the task partner_id itself.
The main problem of this solution is that the management of the task's partner_id
is also extended in several others modules like sale_project and sale_timesheet.
You can find below what seems to happen with all these task partners.
Start following rules according to which module is installed.
(for the record: sale_timesheet depends on sale_project which depends on project).
Rules are applied in the order they are written.
Rules labelled "O" only apply when changing the project through the task form view.
Rules labelled "C" apply everywhere.
technical: C=compute, O=onchange
project
C.1 If parent's partner changes and the partner is not set, then set the parent's
partner
C.2 Else if project's partner changes ant the partner is not set, then set the
project's partner
sale_project [+ project]
C.1 If the project's sale order line's partner changes and the partner is not set,
then set the project's sale order line's partner
C.2 Else apply (project.C) rules
sale_timesheet + [sale_project + project]
C.1 Apply (sale_project.C) rules
O.1 If the project is billed "At Project rate" or "At Employee Rate" and the
partner is not set, then set the project's sale order's partner
the sale order line's partner
Specification
===========
- If the partner changes, we ignore all current tasks and let them be. We set the
new partner as default value on all new tasks. In detail, we have done
this:
- When the user creates a task give the customer of the default project or the
task parent as default customer for the task.
- When the user changes the project and no partner in the task, we take the
partner of the new project (if this project has a customer).
- When the user changes the customer of the project, the linked tasks are not
impacted by this changes, even if some tasks have not a customer yet.
- When the user changes the customerf of the parent task, the child tasks are
not impacted by this changes, event if these tasks have not a customer yet.
- remove the onchange rule to remain consistent.
- get the display_project_id if parent is subtask.
## Miscellaneous
- display commercial_partner_id in project kanban view rather than the partner_id
in the kanban card of each project to be consist with task's kanban card.
TaskID: 2232042
closes#51471
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Before this commit, when the partner_id in the project, we display the
partner_id selected in this project in the kanban card of it.
This committ displays the commercial_partner_id rather than the
partner_id in the kanban card of each project in the kanban view to be
consist with task's kanban card.
task-2232042
closes#51471
Before this commit, when the user creates a subtask in subtask then we
take the project_id but if the user has changed the display_project_id,
the subtask of this task has not the correct project.
This commit gives the project_id by default if the parent task is not a
subtask or the display_project_id of this parent task is not defined
otherwise it gives the display_project_id.
task-2232042
closes#51471
Purpose
=======
During the development of the task #2169100, it appeared that the synchronisation
of a task's partner_id according to its project's partner_id and its parent's
partner_id was not very clear.
A first idea was to simplify the partner_id management: as it could be annoying
for the customer to see all the task's partner_id overriden after project's
partner_id modification, the idea was to just use the parent's parnter_id or the
project's partner_id as default value of the task's partner_id. Then, if the
partner_id of the project or of the parent is changed, there is no more impact
on the task partner_id itself.
The main problem of this solution is that the management of the task's partner_id
is also extended in several others modules like sale_project and sale_timesheet.
You can find below what seems to happen with all these task partners.
Start following rules according to which module is installed.
(for the record: sale_timesheet depends on sale_project which depends on project).
Rules are applied in the order they are written.
Rules labelled "O" only apply when changing the project through the task form view.
Rules labelled "C" apply everywhere.
technical: C=compute, O=onchange
project
C.1 If parent's partner changes and the partner is not set, then set the parent's
partner
C.2 Else if project's partner changes ant the partner is not set, then set the
project's partner
sale_project [+ project]
C.1 If the project's sale order line's partner changes and the partner is not set,
then set the project's sale order line's partner
C.2 Else apply (project.C) rules
sale_timesheet + [sale_project + project]
C.1 Apply (sale_project.C) rules
O.1 If the project is billed "At Project rate" or "At Employee Rate" and the
partner is not set, then set the project's sale order's partner
the sale order line's partner
Specification
=============
- If the partner changes, we ignore all current tasks and let them be. We set the
new partner as default value on all new tasks. In detail, we have done
this:
- When the user creates a task give the customer of the default project or the
task parent as default customer for the task.
- When the user changes the project and no partner in the task, we take the
partner of the new project (if this project has a customer).
- When the user changes the customer of the project, the linked tasks are not
impacted by this changes, even if some tasks have not a customer yet.
- When the user changes the customerf of the parent task, the child tasks are
not impacted by this changes, event if these tasks have not a customer yet.
- remove the onchange rule to remain consistent.
TaskID: 2232042
closes#51471
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
The value taken into account in the SQL for the calculation were wrong:
- Not based on the state of the invoices (cancelled and draft
were taken into account)
- Had the tax included
opw-2464004
feedback-2478356
closesodoo/odoo#71088
X-original-commit: 8b0e438af24883f979cb54eb046564e4e2a3f64c
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bve-odoo <Abridbus@users.noreply.github.com>
The web editor does not work well with the e-learning fullscreen view.
It actually completely closes the fullscreen view and opens the edition on a
blank page.
To avoid this, we intercept the click on the 'edit' button and redirect to the
non-fullscreen view of this slide with the editor enabled, whose layout is more
suited to edit in-place anyway.
A small testing tour was added to ensure this behavior is kept.
Task-2507179
closesodoo/odoo#71086
X-original-commit: 8009e6fedb78e7c16764faef77459614c7ff5ed2
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit,
Share action was displayed on list view as well which
doesn't makes sense as it will always use `active_id` only.
With this commit,
we are displaying `Share` action on form view only.
opw-2530652
closes#70821closesodoo/odoo#71062
X-original-commit: 45845a87ab6a6260b42abacf16811684418cd775
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit improves the crm.iap.lead.mining.request error handling by
displaying the encountered error (currently one of "no results" or
"insufficient credits") within a warning block on top of the form view.
This allows the user to quickly understand what's going on and change his
parameters to get results or buy additional credits if he's out.
Furthermore, this commit simplifies the technical implementation by avoiding to
re-create a separate crm.iap.lead.mining.request when we encounter an issue and
instead allow the user to modify the current request with an error state.
UPG PR odoo/upgrade#2261
Task-2478427
closesodoo/odoo#67574
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.
When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.
The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.
This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.
This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.
To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.
closesodoo/odoo#71069
X-original-commit: bdeea73dc1efb6ff7d02cc2f58347a69762bcc3c
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
If a MO is validated with all of its (component)
move_raw_ids.quality_done = 0, then when trying to validate the
nonsensical "The quantity to produce must be positive" validation error
will occur. This is due to all move_raw_ids being marked as Cancelled,
which auto-updates the MO state to cancelled, which prevents the
validation from properly completing.
To avoid this error, we prevent the user from having 0 consumption for
all components.
Task: 2422698
Related (v13 fix + bug description) Task: 2463893
ENT PR (test fixes): odoo/enterprise#18355closesodoo/odoo#71068
X-original-commit: 81ba7084aeb3899787d083a2a2568a490f9c53e5
Related: odoo/enterprise#18411
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <ticodoo@users.noreply.github.com>
Purpose
=======
Add a unicity constraint (on the url, UTM campaign, medium and source).
As we must care about null values, we can not implement it in SQL
(possible in pure SQL, but we will need to create an index on the
columns, which is not possible in Odoo if we want to customize the
error message).
Clean the code, before the "search or create" behavior was implemented
in the create, causing strange behavior (creating a link tracker with
the same values as an existing one didn't raise an error, but open
the form view of the existing link tracker).
Task-2090344
closesodoo/odoo#48845
Related: odoo/enterprise#9608
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when we create an expense that is paid by company,
then create and approve a report, then post entries, 2 entries are
created. 1 is posted and is correct, the other one is in draft due to
the creation of the payment for employee and should not be there.
As when a company pays for an expense, in 99% of the cases,
it's because employees have a credit card funded by the company.
It happens often that company owners have this kind of card or even
employees but that's more common in the US. In such case,
it's just an account payable to visa or mastercard. so no need to
create a payment for the employee.
So this commit, draft entry will not be created when payment paid
by the company while posting the entries from the expense.
closesodoo/odoo#71063
Taskid: 2410551
X-original-commit: 2aedd076317b37ceffba061c48e3d4fc38f02ea9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Manually adding a line should not trigger the computation of the field,
just like modifying the line fields that occur in the field's domain.
In other words, the dependencies of the field should be limited to the
ones declared on field or its compute method.
closesodoo/odoo#71049
X-original-commit: 1c39814bd729cc08882f1545c7d88b0592e63f9a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Enable 'product configurator' and 'variant grid entry'
- Go to product [DEMO]:
- Add an optional product.
- Go to the variants tab and add some variants
- Select 'order grid entry'
- Remove all the variants
- Create a SO adding [DEMO]
Traceback will occur
opw-2439764
closesodoo/odoo#71048
X-original-commit: da9541089fcf33c778748c4c3da0d81f6b5ea227
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Right now, for failed SMS, user have to go through each record one
by one to resend the SMS, which is not ideal and user should be
able to resend SMS in batch from the list view.
This commit improves the behavior with following changes:
* Introduces an action 'Resend' which is availabe on list view of the SMS.
It enables resending multiple SMS (that are in error state). It also
displays appropriate toast notifcation to users so they know how it
worked (if few/none SMS sent successfully or there was no SMS that could
be resent etc).
* On the SMS form view, a new 'Retry' button is introduced, visible on SMS
whrich are cancelled or in error state. It pushes the SMS back in sendng
queue (outgoing state).
* 'Cancel' button on form view now also appears in error state.
* Uses the state-decorations on the list view for better identifications
of the records (info for outgoing, muted for canceled and danger for error
state).
taskID-2465233
closes https://github.com/odoo/odoo/pull/67502
Before this commit, we use the 'product.product_category_3'
external_xmlid to find the 'Services' category but this record is in
fact a demo data.
This commit removes this using to create a new category called
'Services' for the product created in this test.
Related PR: #65146closesodoo/odoo#70869
X-original-commit: dd68808fd074ba776f4a9f6b3218df99b887ae9b
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Currently, there is traceback while installing the l10n_in module
due to the wrong xpath.
So in this commit, fix the xpath and added the l10n_in_code inside
the uom_ids's tree view instead of uom category.
closesodoo/odoo#70157
Taskid: 2515007
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Prior to this commit, the default stage didn't follow the value of the
display project id as the project_id was only updated after the write
call.
This commit makes the project_id to be updated after the display
project id changes.
This allows the default stage to be updated too once the onchange is
done.
Tests
---------------
This commit changes the behavior of a test making the use case more
smooth.
Previously, when a user removed both display project id and parent id
from a subtask, the project id was set to False. Now, if the display
project id is removed, the project id goes back to parent project, and
when the parent is set to False, it doesn't affect the display project.
PR: #50576
task-2522066
closesodoo/odoo#71029
X-original-commit: a908b9e8e6577bb7f8c8769db730c855fcad9504
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit: when float_time field value changed and field is
blurred, it does not format value and it formats value only when saving
record, this looks awkward and buggy.
After this commit: when float_time field value changed and blurred, value
will be formatted.
task-2518730
closesodoo/odoo#70481
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On unbuild order creation, when the user selects a manufacturing order,
the UoM of the quantity will be defined with the product's UoM instead
of MO's UoM.
To reproduce the error:
(Use demo data)
1. In Settings > General Settings, enable "Units of Measure"
2. Create two products P_finished and P_compo
- Both are storable
- Qty on Hand of P_compo = 12
3. Create a Bill of Material
- Product: P_finished
- Component: 1 x P_compo
4. Create a Manufacturing Order MO
- Product: P_finished
- Quantity To Produce: 1 Dozen(s)
5. Check Availability, Produce, Mark as Done
6. Create an Unbuild Order:
- Manufacturing Order: MO
Error: The unit of measure of the quantity is incorrect, this is
Unit(s), it should be Dozen(s)
The method `onchange_mo_id` defines the product, therefore the method
`onchange_product_id` is also called and here is the issue:
`onchange_product_id` will override the UoM using the product's UoM.
OPW-2467017
closesodoo/odoo#71017
X-original-commit: 1ec10d89ed265e0fb30e98063e80a51a37773ec7
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
with this commit we disables autofill of autocomplete by setting
autocomplete=off, this was previously done in commit: 64293fbdb0
but it was not working because we were setting autocomplete=none
it seems that none does not work all the time.
task-2462676
closesodoo/odoo#71016
X-original-commit: 9d6ef842902e9e192924fa0caba99514e1543352
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If a visitor tries to send a file too large, they will get a message after a
while that an error occurred. The message isn't specific enough.
With this commit:
- when a visitor sends a form, a spinner will appear indicating that the file
is being uploaded.
- if the upload fails because the file is too large, the user will be notified.
task-2234699
closesodoo/odoo#70301
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
This commit makes it so boms are no longer required for a replenishment
of a product via the manfuacture route. This change is related to the
v14 refactoring of the manfacturing app to make it more flexible and
user-friendly. In the refactoring, manufacturing orders no longer
require a BoM, therefore a MO created by a replenishment should also no
longer require a BoM.
closesodoo/odoo#64910
Task: 2422698
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Prior to this commit, MOs would throw a usererror if there were no
components in it. This restriction made it so MOs created by a
replenishment (i.e. `warehouse.orderpoint`) for a BoM with no components
were never confirmed and the `qty_to_order` would accumulate for each
replenishment's new draft MO.
Steps to reproduce:
1. create a bom for a new product (w/ manufacturing route) with no
components
2. create and confirm a sales order for the new product
3. go to Replenishment and automate the product's replenishment
4. create a new sales order for the product
Expected result: 2 confirmed MOs where the quantity of the first MO
matches the first sale order's quantity and the 2nd MO matches the
second sale order's quantity
Actual result: 2 draft MOs where the first MO matches the quantity of
the first sale order and the second MO matches the quantity of the first
sale order + the quantity of the second sale order
This commit makes it so MOs can now be confirmed even when it has no
components. Note this requires changing the logic in a few locations to
ensure expected behavior still occurs including:
- backorders are automatically confirmed.
- `reservation_state` is recalculated when expected (will be blank when
no components).
Task: 2422698
To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO
We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move
Task 2484939
closesodoo/odoo#71000
X-original-commit: 6aaf337558e59474efcef937f0175ee531b4b477
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
before this commit:
_adapt_parent_account_group or _adapt_parent_account_group call with multi-company record then raise singleton error
after this commit:
singleton error is fixed
closesodoo/odoo#70977
X-original-commit: 40797b0705f3df210cbc7119944583addfc72684
Signed-off-by: William André (wan) <wan@odoo.com>
Issue
Use Safari (or equivalent) browser
- Install e-commerce
- Go to Website -> Configuration -> Payment Acquirers
- Activate Ingenico in test mode
(write aaa in required fields)
- Go to shop, and add product to card
- Go to checkout
- Select Ingenico payment mode
- Click on Pay button
- When on the ingenico page, press back
The page is blocked and the button is disabled.
Cause
When clicking on Pay button, the page is locked and
the button is disabled.
With Chrome, when coming back to previous page,
this one is regenerated and therefore adapt the button.
In Safari, it is not the case.
Solution
On `pageshow` event, if event have `persisted` attribute set to
to true, meaning using cache, then reload page.
Fixes https://github.com/odoo/odoo/issues/69453
opw-2510281
closesodoo/odoo#70906
X-original-commit: c89224940bcc59aab4bddefa95b2b0ef7713e02f
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When there is a materialized view that has not been populated any select
on it will fail.
Example of traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT: Use the REFRESH MATERIALIZED VIEW command.
```
Several upgrade requests have or had had this error which has been
solved with specific scripts.
Related to #40930closesodoo/odoo#71008
X-original-commit: b208570ce8399bc6d3e4a8ba02eef6558e0a6ccc
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Currently, the selection field and boolean field values are displays
below the string 'search for: '
like, Search status for: input value
New
Running
Cancelled
so, this commit improves the quick search dropdown by displaying the
selection field and boolean field value and strings in the same line
like, Search Status: New
Search Status: Running
Search Status: Cancelled
TaskID-2462138
closesodoo/odoo#67575
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
data-parent fields were set on tab link and not on the tabpanel
div. It prevented the accordion of having the right behavior:
closing all the other tabs when a tab is clicked to be opened.
closesodoo/odoo#71001
X-original-commit: 51c868bd9bfcd9a7e81f386b0c889befa5dd6e20
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.
Specifications
==============
This is done with 2 system parameters.
If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.
If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.
Otherwise we do not encapsulate the email (same behavior as before this
commit).
Task 2367946
See odoo/odoo/pull/61853
closesodoo/odoo#70980
X-original-commit: 08a561505b92d23c4c4ec4094b0cee209ece8753
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If 'send by post' is enabled and the address is incomplete when we send one invoice, display:
"The customer's address is incomplete:" followed by a link to the corresponding partner
If 'send by post' is enabled and some addresses are incomplete when we send invoices in batch, display:
"Some customer addresses are incomplete. [number of incompete addresses] Contacts"
and if we click the Contacts, we will be redirected to the corresponding Contacts
Purpose:
When the user tries to send an invoice by post, the system warns him that the customer's address is incomplete.
But then, it's a dead end. The user doesn't have any tool to rectify the situation.
closesodoo/odoo#69469
Taskid: 2502597
Related: odoo/upgrade#2445
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.
This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.
This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.
opw : 2451298
closesodoo/odoo#70975
X-original-commit: e8c1f6b1a3f58b68181bf4d2599bd37efb83b5c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
website_forum.faq_accordion is not rendered by a drag'n'drop
and data-parent is therefore not set on tabpanels by onBuilt.
closesodoo/odoo#70978
X-original-commit: d4e046209914a7be3aed976a1fc3a74020843309
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
accordions in pages created by configurator have not been
added by a drag'n'drop. onBuilt is therefore not called and
attributes (data-parent and id for tabpanel and data-target
for tab) are not set. We set these attributes directly
in the xml to make accordions work also for configurator.
closesodoo/odoo#70974
X-original-commit: 887f6d539ebf4f3a6d95f44f2cdd4152b59d5910
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
As pickings can be moved from a batch into an another one, a batch can suddenly
be emptied or having no more active pickings.In such case, we cancel it.
This way, empty batches won't be displayed by default as there is a default
filter showing only draft or in progress batches.
If we manually remove all pickings from a batch or create a empty batch, we
consider it intentional, and won't cancel it automatically.
Task-2464457
PR #66600
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>