The "launch" button of an email campaign mark the current campaign ready
to be processed. As sending all the mails is a pretty heavy operation,
it is done asynchronously in a cron. The cron was running every hour, it
means the cron was running even if there was no active campaign and it
has a best precision of 1 hour.
We now use the new mechanism of cron triggers (4b28f11) to schedule the
con execution at the time the campaign is configured to be sent. It
achieves a better precision and ensures the cron only runs when there are
stuff to process.
We still let the cron run once a day as a security until the cron
mechanisme proves reliable.
closesodoo/odoo#65124
Task: 2416741
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Remove 'refuse' leaves from the Calendar View.
Improve leave/leave.allocation popup form views.
Add Sequence handle to leave type list view.
Change the sorted key func. in _search override to
first order by sequence asc then sort ties by
remaining,taken desc.
closesodoo/odoo#62162
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
place of supply always set from customer address.
After this commit:
place of supply is set by delivery address
closesodoo/odoo#67393
Opw: 2456095
X-original-commit: dd141a882478c2e3684638321f36b952bcac3858
Signed-off-by: Josse Colpaert <jco@openerp.com>
According to the documentation from IPCF, the proportion of VAT that may not
be claimed back must be recorded by default on the same account as the base
amount in a different move line that this base amount.
Task ID: #2373849closesodoo/odoo#67492
X-original-commit: 8b831cd5d1d837b103aab1abd5ee3cbe0e6787d7
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Commit [1] altered the way the FieldMany2Many behaves with respect
to 'create' and 'delete' options. Indeed, for many2many fields,
adding or removing records doesn't mean "creating" or "deleting"
records, as it is only about adding/removing records to/from a
relation. This is completely fine and correct.
Unfortunately, a feature has been lost in the process: it is no
longer possible to state that a many2many field should be editable
but should not allow to add (or remove) record to the relation.
This commit fixes the issue by adding two new options: 'link' and
'unlink' for that purpose.
[1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096
opw~2466213
closesodoo/odoo#67495
X-original-commit: df44e65bbbba55a7ee2224ad5b4f13248a39423a
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit gives access to float_compare function in server action python
code.
closesodoo/odoo#67500
X-original-commit: 3046b11f50aa1a0e02725492ba63b17c194db751
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When confirming a SO, if a line uses a different UoM than the default
UoM of the line product, the computed cost will be updated to the
product unit cost.
To reproduce the error:
1. In Settings, enable:
- Units of Measure
- Margins
2. Create a product P
- Sales Price: $100
- No customer taxes
- Cost: $50
- UoM: Units
3. Create a SO
- Add P
- Set the line UoM to 'Dozens'
4. Display the order line field "Cost"
- [Note] As you can see, since UoM is 'Dozens':
- Unit Price: $1200
- Cost: $600
5. Confirm the SO
Error: Line cost becomes $50 (the cost of one P-product). Since the UoM
of the line is 'Dozens', Cost should be $600 (as before confirming the
SO). As a result, this error creates incorrect data in the margins
(95.83% instead of 50%).
OPW-2444335
closesodoo/odoo#67480
X-original-commit: 377f70ada0ec720aca055986ff19b8bbff84e33d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The astroid package where version is lower than 2.5.1 uses imports the `imp`
module that was deprecated in python 3.4 [0].
In Debian buster, astroid version is 2.1.0 and 2.3.3 in Ubuntu Focal.
With this commit, the deprecation warning is filtered out.
Note that pylint 2.5 avoid that deprecated import [1], that's the reason
why the warning was not showing on current runbot Docker image.
[0] https://docs.python.org/3/library/imp.html
[1] https://github.com/PyCQA/pylint/commit/51c646bf70a6e0a86492bfd2ddd1885671d64d67closesodoo/odoo#67469
X-original-commit: 8127bea147c093aa64ac7d31ebc69e4dcbef6eef
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The run_push() method may change the location_dest_id of the stock move
but not the associated stock move line. That can produce a
de-synchronisation between stock move and stock quants as those are
updated by the stock move lines.
This commit ensures the location_dest_id of the stock move is also set
on the move lines in run_push()
opw : 2427301
closesodoo/odoo#67460
X-original-commit: 7dafde71c0591be74f9d433976243342b1b3e635
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
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>
Kevin Baptiste