Have an invoice with single line and 0% tax on it
As the tax has 0 amount, no related moves are created,
the e-invoice export will fail the formal compliance check as it is
missing a section
opw-2461496
closesodoo/odoo#66960
X-original-commit: 71cc7212b1c1abad5d37e29f3a1f33f6e6cd2a81
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Account move synchronization has already taken place during the creation
of the moves. No need for this additional check during the
reconciliation itself.
This commit helps when a lot of move lines are being reconciled at once.
For instance, the duration of the reconciliation of a batch of about 700
payments on a large database took 20 minutes before this commit, and
takes about 4 minutes after this commit.
closesodoo/odoo#67447
X-original-commit: e883fffaebd05727b399b26ca86cc54df79cde93
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit:
In a mass mailing, the action buttons such as 'put_in_queue' (Send) and
'action_schedule_date' (Schedule) are visible in 'sending' state, which
is not correct because users should not be able re-launch it in sending
state.
After this commit:
We hide those action button in 'sending' state to prevent user from
re-launching mass mailing when it's already in queue.
Task-Id : 2469352
closesodoo/odoo#67446
X-original-commit: 2b874486266e14e81ee93b61c402b4d14dc9a225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
/longpolling/poll requests are most often requests to Odoo. Moreover,
such requests may be sent at the same moment from all users. For
example, when all users are subscribed to a common channel and someone
sent a message, all current polls are closed to deliver the notification
and after that, all clients start the request again.
If some users have several clients open (e.g. on desktop and mobile),
they may send many parallel requests and hence make concurrent queries
to update presence. We don't need be sure that every such query is
processed. So, just fail fast and carry on polling.
To test perfomance impact of this commit, copy curl command for poll request
from browser network tool and repeatly execute it, e.g.,
```
for i in {1..1000}
do
sleep 0.1
curl ... &
done
```
Without this commit you may notice such warnings in the logs:
```
... odoo.service.model: SERIALIZATION_FAILURE, retry 1/5 in 0.2071 sec...
```
At that moment, try to make normal odoo operations (e.g. create a sale
order): it would work slower than usual.
---
opw-2451865
close#57067closesodoo/odoo#67390closesodoo/odoo#67440
X-original-commit: aad9cbe80dae28c0869fe6f543fbe0118357ce57
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to follow to reproduce the bug:
In Odoo - V14
-Go to sales app
- Create a product and give it for example a “sales price” of 200 and a “cost” of 100. Select a category of product with "Costing Method == Standard Price"
- Create a new Quotation/Order
- Add the product you just created
- Modify in the order line, the value of cost from 100 to 120 for example.
- Save the sale order and confirm it
Problem :
The final price is calculated in relation to the base price of the product and never takes price changes into account.
Solution :
Check if the "Costing method" of the product category is "Standard price". If it's the case, do not change the "purchase_price" defined in the order line.
opw-2451721
closesodoo/odoo#67434
X-original-commit: e9c89569dec46f03ed37100b73105bc243944ed7
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
For each move post the system send a PEC.
This should not occur, as only outgoing invoice should be
registered in the EDI system as e-invoice
opw-2461496
closesodoo/odoo#67406
X-original-commit: 2bbe214e816902d7e0c85ca38fedbeece9c47e7d
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).
We deal with extreme cases (when the widget is, by mistake, set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.
Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.
This commit ensures that we keep in the relation all values that
aren't displayed.
Issue spotted when working on opw~2439041
closesodoo/odoo#67400
X-original-commit: 9e9d3aa78c42ad4ffca3b56a28382ed84078cde3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if the widget "many2many_checkboxes" was set on
a field with more than 40 values in the comodel (i.e. more than 40
checkboxes displayed), (un)selecting a checkbox that wasn't in the
first 40 checkboxes crashed. This was due to the default x2many
limit of 40: we only created a datapoint for the first 40 values,
whereas we could have up to 100 values to process (name_search
server-side limit). Note that this limit of 40 had no other impact
than limitating the number of records processed by the BasicModel,
the maximum number of checkboxes displayed being ruled by the
name_search server-side limit.
This commit ensures that all values returned by the server (at most
100 when this message is written) are processed and can be edited
as expected.
opw~2439041
X-original-commit: d037d12753179d890459b23319b0d769fce62771
This was caused by trying to not show dynamic-svgs that had already been
downloaded when the option to not allow the media-library was activated
(eg in the website logo, we do not want to allow dynamic SVGs)
Unfortunately the domain was doing a string comparison to make sure the
url wasn't like the one from dynamic SVGs but implicitly required that
the url field be not null. This commit fixes that by explicitly allowing
images with a null url field.
task-2466819
part of odoo/odoo#66732closesodoo/odoo#67411
X-original-commit: 0784e14dd39817720e6fc70c2b41ea3bbad5843a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, when quality options were not available, the option would
simply not be displayed. User feedback suggests that this is confusing,
as for example, in the case of modifying the image in a t-field, quality
options would not be available when starting the editor, but would
become available when picking the image again in the media-dialog.
Some leftover code allowed to display a warning about why the quality
options were not available in the case where the image is not local to
the database. This warning has been adapted to display a more
informative message about why quality options are not available, as well
as suggest a solution:
- External image => download the image and upload it in odoo
- t-field => "You need to choose this image again in the media-dialog or
reupload it to have access to quality options"
- Images that are in an unsupported format (anything other than PNG or
JPEG) => short explanation that quality options are only available on
PNG and JPEG images.
task-2466819
part of odoo/odoo#66732
X-original-commit: 84417a174bc2bb76730cc89783d3426a3a3b07d9
Styles for the hex and rgba inputs from the color picker were modified
on directly from the web module, which means that for a specification
concerning only the frontend colorpicker, the backend colorpicker was
also changed.
This commit reverts the changes that were made and only applies the new
style for the website editor.
Related to https://github.com/odoo/odoo/pull/65249closesodoo/odoo#67396
X-original-commit: 9529e29615699942aac89099cd37144e052b9004
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently in init of mail.notification we search for a specific index
and create it if not found. This is easily replaced by a standard
CREATE IF NOT EXISTS allowing to simplify code.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR #67382
UPG PR odoo/upgrade#2245
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
A bit of history. Link between a message and its recipients has been added
at first mail refactoring towards a Chatter / Discuss feature. It was done
in v7 at d64f3c9783 with the base addition of mail notification model (lots
of commits follow that one but that's the first one about notification).
Due to some people thinking that it was unnecessary to keep a model for
notification it has been removed in v9 at 88b8cd0587. Notification table was
renamed from mail_notification to mail_message_res_partner_needaction_rel.
It was proven to be a mistake even if those "some people" were warned and
model made its way back to Odoo in v10 at 72dfcae2a4 . Table name mail_message
_res_partner_needaction_rel was kept to ease migration and backward
compatibility.
It is now time to complete the circle and rename it to mail_notification.
SPECIFICATIONS
Rename ``mail_message_res_partner_needaction_rel`` to ``mail_notification`` .
RIP JEM.
Never forget.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
As I was passing by I found some docstrings or helpers could be updated or
rephrased a bit more clearly. This is free as in free beers, without beers.
Some code about mail features (posting) may also be re-indented to ease
understanding of future modifications. Or just because we had to read
it and go through many files. Still free beers.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Before this commit a cookie policy page was created every time the
website settings were saved with the "Cookies Bar" option enabled.
After this commit the policy page is created only if it does not already
exist for the website.
task-2454424
https://github.com/odoo/odoo/pull/67217closesodoo/odoo#67370
X-original-commit: 2f920e0023d29545d2957e5d6ca1619068af893b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit the save snippet button appeared for the cookie bar.
But this makes no sense because the cookie bar is implicitly saved.
After this commit the save snippet button is not available for the
cookie bar.
task-2464233
https://github.com/odoo/odoo/pull/67217
X-original-commit: 439a7568b5b1e7d0aa53c63c7332dd22e3d6fc04
Issue
- Install 'website_event_track' module
- Go to settings and remove website favicon
- Save
Traceback is raised.
Cause
Trying to create image from favicon for app_icon,
but favicon not set anymore.
Solution
If no website.favicon, set website.app_icon to False.
opw-2451934
closesodoo/odoo#67367
X-original-commit: dfe1a6af4b7b740540270d38581f64aa37616222
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If the company uses multi-step routes, when duplicating a MO, if the
user changes the BoM, one stock picking will be missing.
To reproduce the error:
1. In Settings, enable "Multi-Step Routes"
2. Go to Inventory > Configuration > Warehouse Management > Warehouses
3. Edit the warehouse "YourCompany"
4. Set Manufacture to "Pick components, [...] products (3 steps)"
5. Create a storable product SP
6. Create two non-empty BoM (BoM01 and BoM02) for SP
- (Hint: set a different reference for each BoM)
7. Create a MO
- Product: SP
- BoM: BoM01
8. Save, Mark as Todo
- (As you can see, 2 transfers have been created: one from WH/Stock
to WH/Pre-Production, and a second one from from WH/Post-Production to
WH/Stock)
9. Duplicate the MO
10. Set BoM to BoM02
11. Save, Mark as Todo
Error: Only one transfer has been generated. The transfer from WH/Stock
to WH/Pre-Production is missing. (The duplication step is used to
compare the result. If the user saves a new MO, and then edits this MO
to change the BoM, the same problem will occur).
When confirming the MO, the module runs both pull and push rules. When
running the pull rule, the modules assigns a stock picking to a stock
move. To do so, it checks if one stock picking already exists:
https://github.com/odoo/odoo/blob/7d9264c56ac725c8d19aebad55d5668df2a8c814/addons/stock/models/stock_move.py#L863-L873
Since such a stock picking does not exist, the module creates a new one:
https://github.com/odoo/odoo/blob/7d9264c56ac725c8d19aebad55d5668df2a8c814/addons/stock/models/stock_move.py#L887-L900
When changing the BoM, an `onchange` method is raised, deletes the stock
moves linked to the first BoM and creates some new ones. However, since
`group_id` is not a field required by the view
`view_stock_move_raw_tree`, this field will not be included in the
`onchange` response.
As a result, when saving the new MO, the `write` request does not
contain the `group_id` field, so the new stock moves do not have this
information. Therefore, when running `_search_picking_for_assignation`,
the module finds a picking and does not create a new one.
OPW-2444235
closesodoo/odoo#67356
X-original-commit: b810e5ff72b892983c52b24ca7efe5025c8a7142
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to follow to reproduce the bug:
-Go to sales
-Add a vat number with a '-' like: "123456789-5" to any customer
-Create a new SO
-Search the customer by entering their VAT number
Problem :
When the VAT number contains the character '-' you cannot find the customer with his VAT number.
The problem is the same if the vat number contains a '.'
Because, the "_name_search" method before creating the query to search clients by VAT number, removes all the special characters from user input
Solution :
Do not remove the characters '-' and '.' from the user input for the customer search by vat number.
opw-2457692
closesodoo/odoo#67355
X-original-commit: 3f54c1c7556c5d06759bf5ec74dd83872f0d24d2
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
When a block is removed, the parent will be activated.
If the parent element is empty and removable:
1) It will be removed too.
2) In '_activateSnippet' method, we look for the right element to
be selected using the block's parent (removed from the DOM...).
The goal of this commit is to fix this behaviour by computing the
selected element before parent removal.
task-2431506
closesodoo/odoo#67354
X-original-commit: 1d483ab5e2f9bba0fd86c6fe4595a9959b2f125d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
Some computed stored editable fields are computed in the same method.
In that case, when one of the value is provided in a create / write call,
the computed method is not called and other fields computed in the same
method do not have the right value.
Task 2377119
COM odoo/odoo/pull/65772
ENT odoo/enterprise/pull/16221
closesodoo/odoo#67345
Forward-port-of: odoo/odoo#67017
Forward-port-of: odoo/odoo#65772
Related: odoo/enterprise#16894
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Some computed stored editable fields are computed in the same method.
In that case, when one of the value is provided in a create / write call,
the computed method is not called and other fields computed in the same
method do not have the right value.
Task 2377119
COM odoo/odoo/pull/65772
ENT odoo/enterprise/pull/16221
X-original-commit: c9c64fa740fea31964f433a05d37a0f869b8e9d3
Purpose
=======
Some computed stored editable fields are computed in the same method.
In that case, when one of the value is provided in a create / write call,
the computed method is not called and other fields computed in the same
method do not have the right value.
Task 2377119
COM odoo/odoo/pull/65772
ENT odoo/enterprise/pull/16221
X-original-commit: c37ff784f2195325d770e41c70e24a0d1d0420c7
When we double click a form submit anchor, and depending on the selected
element before click, the selection range ("document.getSelection()") can
start from a parent of the targeted node. This will send a wrong range
to be used in LinkDialog widget.
The goal of this commit is to prevent this behaviour by adjusting the range
if it starts from anchor parent.
Note: the bug only occurred in Firefox.
Part of https://github.com/odoo/odoo/pull/62206
task-2381305
closesodoo/odoo#62206closesodoo/odoo#67171closesodoo/odoo#67176
X-original-commit: 9a16c313f131ed2e1017566a5f1bed134e22cc10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor, website_mass_mailing
When we double click a link/button, a link dialog appears
to update the target properties, and since the current link dialog
can only handle anchor targets, using it on buttons leads to some
inconsistencies :
- visible href options for button & url required to save changes.
- missing preview when button style changed.
...
The goal of this commit is to add a fix (with minimum of code) on
summernote linkdialog to handle button elements using the same logic as
anchor nodes.
Also, update website form test tour to test those new changes.
Part of https://github.com/odoo/odoo/pull/62206
task-2381305
X-original-commit: 19fbbdc0327482b5d70bdbcf17c2a5a950327d63
currently, the expiration date of the coupon is checking based on quotation date
now in this commit, the expiration date of the coupon will be check based on the
current date and if the quotation date is before the starting date of the
coupon then it will show this coupon is not yet usable.
task-2229956
Closes#49187
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
create a SO;
Add a fiscal position;
Add a promotion of fixed amount kind.
Before this commit, the taxes of the promotion are the one of the
promotion product and not the one of the fiscal position.
Now, the taxes will be computed taken into account the fiscal position.
opw-2467966
closesodoo/odoo#67318
X-original-commit: 16dab7df5bb966219fa8798b77743149ad129572
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, if we replaced an icon of the showcase snippet
with an image, this image was streched depending on title size (if too
long and on 2 lines). Its because the align-self default value of a
flex item is strech.
task-2447087
closesodoo/odoo#67244
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When we want to send the invoice to the client, a hack was made in account_edi
to make sure that we put the XML of the electronic invoice formats as well, in
the case of web services such that the client has the XML we sent to the government.
For MX however, we also send the payment to the government. However when we wanted
to send the confirmation about the different changes, we still needed to add the XML
manually before this fix. Now it should be added manually even when manually composing
the mail to the customer with the payment receipt confirmation. (but we hope it dies)
closesodoo/odoo#67315
X-original-commit: 327852a6399a19191bd78c820971cc4108dc7821
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
CONTEXT: Within a container, delete a block which has a sibling.
The actual behaviour is to select the container after deletion.
The goal of this commit is to select the previous sibling (if exists),
or next one. Otherwise the parent element will be selected (default behaviour).
task-2431506
closesodoo/odoo#64875
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
We only support int, following #c9edca7896e3096289936f5399a82f08a59b60ce
opw-2456796
closesodoo/odoo#67286
X-original-commit: a05a34366f6dc8c70b39c15c3441beaf6bbb72d2
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the states (collapsed/not collapsed) of the tabs
of the accordion snippet were not saved if it was the only changement
in edit mode.
After this commit, we trigger a content change when the states of the
tabs is changed.
task-2442237
closesodoo/odoo#67276
X-original-commit: 18af2ecade9482b5243059aefbfa79410ebf59a6
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps:
- Install account,payment
- Go to Invoicing
- Create an invoice
- Click Actions > Generate a Payment Link
- Follow the generated link
- Pay
Bug:
The transaction is not linked to the sale order in the link table
`account_invoice_transaction_rel`
Explanation:
This fix is broadly mimicking the behavior of the sales module regarding
the link of an order to a transaction, adding `invoice_id`s where they
are needed throughout the payment process in order to link the
transaction to the invoice.
opw:2451534
closesodoo/odoo#67296
X-original-commit: 7c6d06fa5858f79f3b22cdeaf74cdc26a642742f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
commit at each lead makes the system spend 80% of the time recomputing
bayesian probabilities. Avoid to commit too often speed up the process
while not altering final result.
Task ID-2475352
closesodoo/odoo#67275
X-original-commit: 34f6e38e68208b9509a429cdb09f8316a7ef566f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Field vehicle_id is missing on the account.move.line view of refunds.
This fix updates the domain to make visible the field in in_refund.
Task ID: #2466914closesodoo/odoo#67269
X-original-commit: 97fb335e3f70a55b18685b9b6b08fe0162e1a17b
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
A previous commit (8dbd1efef899fb637acca3c318ae99cb23838b8f) fixed a
part of the basicmodel that used _.each to iterate on an object with
field names as keys, which does not work when a field is named "length".
To fix it, I simply used a native for ... in statement. However, I
missed the fact that there was a second 'return' statement in the body
of the closure given to _.each, so the onchange method returned
prematurely.
The fix is to simply use the continue statement in that case.
closesodoo/odoo#67267
X-original-commit: d9834e65ee57511f4850fa2d74287eb0b67087b9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The test is running in sudo mode, so we need to specify the company in
the search.
Also do not load the demo data when installing as we would do the work
twice for most localization.
closesodoo/odoo#67235
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
PR #66910 has been created so the MX can print their receipts.
Eventually, this needs to be reverted since printing a receipt is
actually illegal.
closesodoo/odoo#67209
X-original-commit: 7e9261cacd9f6963dca517fe7b1f3de067af1366
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>