The regex patterns for dailymotion and youku were too permissive and
not specific enough for the way they were intended to be used.
The new regexes should correctly isolate the video ID from the URL
string and cover all embedding needs for the two providers.
There are also new test cases for specific embed URL variations.
For the initiating discussion and PR, see following link:
https://github.com/odoo/odoo/pull/44537#discussion_r753250276
task-2696033
closesodoo/odoo#82369
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] the CSRF token used by the donation snippet's form did end up
being cached for new visitors that did not have a session id yet.
This made the validation of the token fail when using the form because
the token from the very first new visitor on the worker was reused.
After this commit pages that contain a Donation snippet are not cached
anymore in order to always get a fresh CSRF token - similarly to what is
done for the form snippet.
When using incognito mode the csrf token is sometimes not recognized
during navigation to the donation payment page.
Simple sequence to reproduce it:
- drop a Donation snippet on the Home page
- use Firefox and do not log in
- in normal browser, select 25 then press Donate Now
- open an incognito browser, select 50 then press Donate Now
=> 400 Bad Request
Alternative (any browser):
- open page with Donation snippet in incognito window
- remove session id from cookies using developer tools
- close window
- reopen page in a new incognito window
- try to donate
=> 400 Bad Request
[1]: https://github.com/odoo/odoo/commit/7fccbac004628093da49016f75370a84bba49465
opw-2774065
closesodoo/odoo#88184
X-original-commit: 16c9b103195f342f8bcca928a53121dbe4480d58
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In case of purchase agreement, call for tender still appears everywhere
and it's confusing for the user in case of purchase agreement. It would
be better to create another action to have a correct pdf name and report
name but it will be modify in master and we could keep a minimal diff
here.
Also the conditions where not present, so the report could be hard to
communicate to a supplier. Same for the agreement deadline
closesodoo/odoo#88164
X-original-commit: c3b9de36e40c24d0bb521ec0f161d4415b1d86ff
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Before this commit:
When you create a new channel HTML tags are visible in Autocomplete text area
for a split second
After this commit:
Added prevendDefault for the autocomplete select event to stop it's defaullt
behaviour as changing the autocomplete text area's value by the selected item's
value
Task-2792365
closesodoo/odoo#88148
X-original-commit: cc11accfeca4bee0f4a364bf59b6311a99855c2b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when closing an action Dialog ( when the action is
wowl ) an error was raised. This occurs because we use the
LegacyAdaptedActionDialog, and an old function is called.
closesodoo/odoo#88118
X-original-commit: a6e45c53642003243e8a0f498e69ffddcac6e086
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit:
In Discuss topbar, call buttons are added to allow call and video between
channel members. Those buttons were also added to live chat channels but any
voice call or video call features are not available for visitors.
After this commit:
Call buttons will not appear in Discuss top bar for live chat channels.
Task-2744224
closesodoo/odoo#88105
X-original-commit: 1fd8af1a30abbe65fd4266c2fb4793ea2a06fab5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The image transform option uses the `transform` CSS property, which is
very poorly supported in email clients. This hides that option so as to
avoid bad surprises.
task-2802705
closesodoo/odoo#88052
X-original-commit: 611c9a2aa65f3c6f9e1c0780cb9177bc1e67513d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
This is the optimal way to add a user on a group, to avoid calling the
contraint method _check_one_user_type on all the users from the group
closesodoo/odoo#87998
Related: odoo/enterprise#25908
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the ProductDiscountWidget (sale.product_discount) worked by overriding the reset method.
The main drawback is that the reset method is called whanever a field on the line is changed.
This commit rely on _onFieldChanged that allows to target single change. A small mixin is created to allow working with different kind of fields of the SOL.
taskid: 2568007
Before this commit, the sale module could not be used to manage subscriptions in an override.
This commit adapts the sale module to https://github.com/odoo/enterprise/pull/21825
taskid: 2568007
Currently, when modifying an invoice line and setting taxes
(price included) for 100%, the price_unit field will
be displayed as 0.
This is incorrect and is being fixed here.
opw-2793284
closesodoo/odoo#88180
X-original-commit: 674eaa3bc10210d34a02145529516da1fa1c1b66
Signed-off-by: Laurent Smet <las@odoo.com>
How to reproduce:
1- Create Product Category "PC" AVCO|FIFO Automated.
2- Create Storable Product "P" with product category PC and unit cost to 1.
3- Create SO with 10 units of P.
4- Create PO with 10 units of P and unit cost of 2.
Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)"
Global IV of P should be 0 qty, 0 value.
5- Return the delivery order of SO.
6- Open valuation of the return
Error: The value is 0, should be 20
In `_get_price_unit`, `price_unit` is taken on the last svl of the origin_returned_move_id, in our case it's the revaluation layer.
`_get_price_unit` now take all svls of origin_returned_move_id into account.
OPW-2784033
closesodoo/odoo#88177
X-original-commit: bfd1a06b054dcc115f7fb0937db98812f4a6d5dc
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
Unnecessary call to _create_check_sequence because is called in create method and create is called in supper().copy()
TT35608
closesodoo/odoo#88159
X-original-commit: 2f83737b8eb4f2b378cf4d6a6348d9ba15200561
Signed-off-by: Florian Gilbert <flg@odoo.com>
This fix prevents the `/Annot` key from a PDF PageObject
to cause errors during its handling by PyPDF2.
opw-2811793
closesodoo/odoo#88182
X-original-commit: 1c0fc5b20efb9e5829447f97480d0813c6c9e367
Signed-off-by: William André (wan) <wan@odoo.com>
Manual forward port, commit was lost from 15.2 to master. Either it
seemed not needed after the httpocalypse refactoring, or was simply
lost during the rebase.
-----
We can remove an useless SQL Query for public user on every single page
serve, if we directly set the website's company_id in the available
company_ids of the public user.
Indeed, the public user from a website always have the same company_id
as the website.
We can then do that directly and bypass the next line which will
always be true in the case of the public user, making a read for
nothing.
task-2774979
closes#85419
X-original-commit: c95ab6f
[1]: https://github.com/odoo/odoo/commit/728ade674cb12c64718efda56b0d5d542e319cbaclosesodoo/odoo#87856
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: test_website, website_blog (test perfs)
An error regarding tests was not catch during httpocalypse [1] review.
The test query counts were lowered in website by 2 everywhere, but it
shouldn't have as there were no SQL perf improvement from this
refactoring regarding website.
The query count actually decreased because the test-only SQL Savepoints
got divided by 2, probably thanks to a low level test improvement in
the PR.
But outside of tests, there were no SQL Query gained.
This should have been reflected in the `EXTRA_REQUEST` variable
instead.
Before:
Savepoint > Rollback > Savepoint > [Actual SQL Queries] > Rollback
After:
Savepoint > [Actual SQL Queries] > Rollback
It is important to fix it because:
1. (Minor) There is a de-sync between the query count in the test and
the actual query count (in the logs outside of tests), making it
hard to figure.
2. (Major) Some controller got then wrongly lowered to 0 query counts
instead of 2. An incoming PR in master would then make those tests
expects negative query counts, which doesn't make any sense.
[1]: https://github.com/odoo/odoo/pull/78857
Note that the exact commit can't be found by bisect as those don't work
on their own, DB can't be started due to circular import.
Part-of: odoo/odoo#87856
Step to reproduce:
- install sale, accounting and l10n_de
- activate proforma in sale settings
- set the template to external_layout_din5008 in the settings (use developer mod)
- create sales order or quotation
- print it as a proforma
Current behavior:
- the proforma is missing from the title in the document
Behaviour after PR:
- the proforma is in the document title
The l10n_de_sale module was missing the case scenario of a proforma sales report and the sale module only
gives the information of a proforma report in the xml context. Then we add the case scenario and propagate
the proforma info from the sale module also in the python context using the proforma variable.
opw-2796603
closesodoo/odoo#88153
X-original-commit: 14e0f84abeba8453930522047df3610940d6aa9a
Signed-off-by: William André (wan) <wan@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
Enable discounts
Have a price included tax 10%
Have a product with sales price 100$
Make a SO adding the product, the price incl. tax and a 1% discount
Open the portal page of the quotation
In the left recap sidebar the price before discount is reported to be
100.10 while it should be 100.0
opw-2759804
closesodoo/odoo#87418
X-original-commit: db6994c2ac991822014d168022c854ba75f3095f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Step to reproduce (Traceback):
- Be in multi-company
- Create a time off type with duration in hour and no company_id
- Create an instance of this type on company A with a user linked
to company A (need access to both)
- Switch to company B
Current Behaviour:
- Traceback
- Cannot fetch user's calendar if content of company A is not checked
for convertion from Days to Hour
Behaviour after PR:
- We only fetch if the user related to the leave is in allowed_companies
-> only fetch if the user data is available
- This is also true if duration is in Days/Half-Days (GMF Approved)
opw-2749258
closesodoo/odoo#88104
X-original-commit: cb5942e5461ec0fc1fa54cd249de23e4f28f8692
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit applies the correct primary colors to maintain consistency
with the overall design.
task-2817682
closesodoo/odoo#88088
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
``get`` default is a dict that gets evaluated to be sent as parameter,
causing an unnecessary read on the component's computed fields.
The read should only happen only if we don't have a value in ``res``.
closesodoo/odoo#88050
X-original-commit: 4d16869e5c0a627dfe32ad1c8f54e83373dc3c8b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Before this commit:
For guests and portal users, a separator(differentiates channel name and
description) in the thread view topbar is displayed even if there is no description.
And when portal users are trying to write/edit channel description at that time
access error is generated.
After this commit:
A separator will only be displayed when there is a description and portal users
will not be able to write/edit channel description as they don't have rights.
Task-2664843
closesodoo/odoo#87999
X-original-commit: 84604910af931131fd10ad37787a803c8905d55c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
add get warehouse address method
needed in Indian EDI to pass value of dispatched address
improve demo data and bypass one GST number from validation because that GST number use to test EDI
Add Non GST Supplies and State CESS tax report line
Non-GST Supplies and State CESS is required to get related value from the invoice for send EDI
Part-of: odoo/odoo#79995
This follows up e045e76e35.
Change the heuristics for ordering columns, as padding is not determined
by column size, but by column alignment inside a row. Because in Odoo a
row always starts with a column of size 4, the following columns should
be the ones aligned on 4 bytes, then the ones aligned on 1 byte, then
the ones aligned on 8 bytes.
The analysis in the commit message of e045e76e was not correct, as it
did not take into account the fact that rows themselves are aligned on 8
bytes. So we have: before each row used 40 bytes (+24b header)
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
create_date | timestamp | 8
write_uid | int4 | 4 -> 4 bytes padding
write_date | timestamp | 8
active | bool | 1 -> 7 bytes padding
After each row uses 32 bytes (8 bytes saved per row):
attname | typname | typlen
-------------+-----------+--------
id | int4 | 4
create_uid | int4 | 4
write_uid | int4 | 4
active | bool | 1 -> 3 bytes padding
create_date | timestamp | 8
write_date | timestamp | 8
Of course, when more columns are present, the space savings depend on
the alignment of the other columns.
closesodoo/odoo#88084
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Since commit [1], we should use domain instead of _get_http_domain().
However _get_http_domain() checks if the domain exists which is not the
case in commit [2]. It only impacts databases having multiple websites.
[1]: https://github.com/odoo/odoo/commit/7d8a8ddea0b363732f2177ad589a3e0e10e2fb6c
[2]: https://github.com/odoo/odoo/commit/ee71cdff0786d5c41fbcc50894cd06811d3d8d5b
Steps to reproduce:
1. Install the eCommerce app
2. Add a second website
3. Keep the domain field of the website empty
4. Set the website field of a product to the website.
4. Click 'Go to Website'
Current behavior before PR:
- RPC_ERROR: Odoo Server Error
Desired behavior after PR is merged:
- Redirected to the product's page
closesodoo/odoo#88067
X-original-commit: 18c8a97ac986753728462b374a1c327bc9597a37
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This patch solves memory problem on exporting `account.move.line` records:
while export method invalidate cache for `account.move.line`, it keeps cache for
`account.move`, which may lead to memory error.
opw-2764457
closesodoo/odoo#88060
X-original-commit: 80c65498adf05b37d91207e0b59c781c6057f64b
Signed-off-by: Raphael Collet <rco@odoo.com>
Reproduce:
* Create default analytic rules
* Create a quotation/sale order.
Before:
Default analytic rules were not added on sales orders, like they are on
invoices and purchase orders.
After:
Same behavior on all documents.
This behavior was mistakenly removed during a refactoring:
https://github.com/odoo/odoo/commit/3c67bb20feb42f16799b7491411e213b818c4f83
opw-2800936
closesodoo/odoo#87980
X-original-commit: 0598eb70c13310d79202607e3bf46f82a85d6935
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This commit replaces raw SCSS with default Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2812497
Part of the overall v16 SCSS optimization/restyle, task-2704984
closesodoo/odoo#87796
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit
On mobile, clicking on a powerbox item called the first command.
After this commit
On mobile, clicking on a powerbox item call the clicked item command.
task-2751059
closesodoo/odoo#88059
X-original-commit: 03638e4d46941bb4751ac2d6df8c08cb4cc2208e
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
`this.root.el` can become undefined, so it should always be guarded.
closesodoo/odoo#88053
X-original-commit: 2e634bb431642fbe21b61d61354c85282c365d40
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When using an internal transfer to move some products between two
warehouses, the forecasted inventory becomes incorrect
To reproduce the issue:
(Let WH01 be the existing warehouse)
1. In Settings, enable "Multi-Warehouses"
2. Create a second warehouse WH02
3. Create a storable product P
4. Update its quantity: 1 x P at WH01/Stock
5. Create a planned internal transfer (the warehouse does not matter):
- Source: WH01/Stock
- Destination: WH02/Stock
- Operations:
- 1 x P
6. Mark the transfer as Todo
7. Consult the Forecasted Inventory report:
- Filters:
- Forecasted Stock
- Product: P
- Group By:
- Warehouse
Error: The line for WH02 is missing and the line for WH01 is incorrect
(qty is 1 for next days while it should be 0)
The report used (`report_stock_quantity`) does not handle this transfer.
Because both locations (source and destination) are defined, the SM is
not considered as an in-move or out-move:
https://github.com/odoo/odoo/blob/07f0ffad6ecc08f4165902db45ae96e4b41199e8/addons/stock/report/report_stock_quantity.py#L38-L43
Moreover, it would be hard to change the SQL view to generate two lines
(one 'in' and one 'out') from the same SM (the internal move).
The graph on the forecasted report of product P is also incorrect (it
uses `report_stock_quantity` to get the data, so if the user selects a
specific warehouse in the filters, the result will be incorrect)
So, the user should only avoid to transfer some products between two
warehouses if the internal transfer is a planned one.
OPW-2752017
closesodoo/odoo#87965
X-original-commit: 7f56063f6fe63a70d3e23b9c5fb486cc0958dd3e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to follow
- Use a browser timezone of GMT +2
- Create a pricelist ending in an hour with a matching product
- Add the pricelist to advanced pricelists in the POS settings
- Open a POS session
- Add the aforementioned product
- Apply the pricelist
-> The custom price is not applied
Cause of the issue
`date_start` and `date_end` are stored in utc
They are then off by the amount of the offset in the browser timezone
opw-2794490
closesodoo/odoo#88056
X-original-commit: 2fcecef406540323a753df5d802fb15a7546efdb
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Fix errors when adding attachment to records with read only permission:
Current behavior:
1. Error adding attachment to records with read only permission.
2. The message is not as clear as version 13.0
closesodoo/odoo#88036
Expect: Only display the message "You are not allowed to upload an attachment here." if you do not have permission to upload files.
X-original-commit: 8385f192873cfd33f311e00d9074571f1b3810a7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.
Task-2797359
closesodoo/odoo#86572
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Alexandre Kühn