Steps to reproduce the bug:
-Let's consider a multicompany environment with company A and B
-Let's consider a shared product P for A and B
-P has a deferred revenue type D set on it
-D is defined in A
-Let's consider a user U in company B
-U creates a SO with P and try to generate the invoice
Bug:
A access error was raised because U is not allowed to see D and
D is needed to genrate the invoice.
opw:1825944
When validating a statement with old posted moves, the lock date
was checked by function, _check_lock_date and then it was impossible
to validate the statement even if all the moves were already posted.
Backport of this commit: 86a0d31251
opw:1830804
Commit d39856db prevents crawler to crawl and index blog tag URL which could
lead to possibly millions of URLs combinaison.
Still, it would crawl (but not index) second level of tags combinaison.
This commit ensure that crawling is prevented when already one tag on the URL.
Before this commit:
If a blog had multiple tags on the page, the crawler would click on every one
of them one after another until every tags combination got crawled.
With a lot of tags, this could result in million of URLs.
Now, we prevent URLs with more than one tag to be crawled.
Eg: With tags 'A', 'B', C':
/A
/A/B
/A/C
/A/B/C
/A/C/B
/B
/B/A
/B/C
/B/A/C
/B/C/A
/C
/C/A
/C/B
/C/A/B
/C/B/A
category was changed to "Website" so it'd appear under the website
category in the store, but it needs to be "Theme" otherwise it doesn't
appear in the "Choose your theme" menu after installing website.
This is a backport of 10.0 https://github.com/odoo/odoo/commit/3d53a740
Without extra themes, the "Choose your theme" would be empty.
fixes#21898
opw-1802936
closes#24042
When installed, marketing_campaign shows the root "Marketing" menu by
default but this menu is not an action and just contain a
"Configuration" submenu without action as well.
Thus in community we got on a page without content, and on enterprise we
got a JS error.
note: only happen in 9.0
fixes#21898
opw-1802936
closes#24026
When creating sales/purchase receipt for a journal having a secondary currency, an error was raised as the amount_currency had the wrong sign (compared to the debit/credit).
Was Issue #1819396. Was PR #23768
To be able to retrieve the base amount of cash basis taxes lines, additional journal items are created for the base as well in the journal entry generated by the payment.
However, these additional journal items debitting and creditting the same account are considered as pollution in reports.
This module and hook allow to move these additional lines to an another account, if needed.
-task: https://www.odoo.com/web#id=35605&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #23349
When modifying a translatable record, we try to keep close translations
However, we do not need to do it if there is already a translation for
the matched term.
When a portal user changes his account details and presses the 'Save' button
when a mandatory field is not set, the selected country will be reset even when
the user did change the country in the form. This fix prevents this from
happening and leads to an improvement for the end user.
This commit closes#22439
As Admin:
- Set up 2 languages for the installation, e.g. English and French
- Admin language is English, Demo language is French
- Create a `res.partner.category` named 'Test English'
- Assign the category to a newly created partner
- Create a French translation for 'Test English', e.g. 'Test Francais'
As Demo:
- Create a Mass Mailing
- Select a custom domain: ('category_id', '=', 'Test Francais') => it
should match one partner
- Save and validate
Now either:
- manually run the scheduled action "Process Mass Mailing Queue" as
Admin
- wait for the cron to process the mass mailing
No mail will be sent since the domain will be evaluated in the Admin
language, i.e. English. Indeed, the domain
`('category_id', '=', 'Test Francais')` does not match any record in
English.
The solution/workaround is to use the language of the last user who wrote
on the mass mailing.
Closes#20906, Closes#15467, Closes#15445
opw-778922
- Create a new pricelist for a new currency
- Set the 'Sale Price' option to 'A single sale price per product', so
that the user cannot see the pricelist details
- Sell 0.5 unit of the product with the new pricelist
The pricelist is not correctly applied.
This is because the default minimum quantity is 1. Once the user is
selling less than 1 unit, the pricelist is not applied.
opw-1825353
This commit https://github.com/odoo/odoo/commit/965f49201812cc3cca319a3b5b93331272dd2288 removed empty meta-description and meta-keywords from
the DOM for SEO audit reasons (these tags when empty are considered as
duplicates at a SEO point of view).
By doing so it prevent the 'Optimize SEO' to work correctly since it can't
retrieve the DOM elements that are used to store the user modifications until
he saves.
Now, even when these meta-tags are empty, we display them to people having the
rights to 'Optimize SEO'.
This closes#23659
Before that, partial payments on open invoices were ignored by the query, due to the fact we used checked "reconciled=false" instead of "full_reconcile_id is not null".
The payment lines shown in the payment widget on invoices, should only list reconciliation made towards the lines sharing the same account as the invoice/bill. Previously, if a tax or an invoice line was using another account set reconciliable, any payment made against this account would be shown in the payment widget, which is wrong.
OPW: 1805968
When a membership line has its dates changed
(date_from, date_to, date_cancel)
The membership start/stop dates on the member
(res.partner) were not changed accordigly.
opw-1823981
In a multi-company environment,
if a user in company A
created a Payslips batch for an employee in the company B
and used the `generate payslips` button,
the created payslip was set with the user company (A) while
it must be the employee company (B).
opw-1820138
Have your OS be in Vancouver with time = 15:59:00
We are on day X
Have a next activity on a lead, scheduled for today
At 15:59:00 the next activity is not overdue
Before this commit:
Past 16:00:00 the next activity becomes overdue
This is because 16:00:00 is 00:00:00 in UTC (+8 hours)
And the next activity is scheduled for day X
But in UTC, we just passed at day X+1
Hence, the next activity being overdue
After this commit:
The next activity is not overdue, since we are actually on day X
OPW 1815323
The previous commit forbids to change the currency of a company having accounting entries, but there are some created by demo data and some tests were trying to set a different currency (to set up a fix environment). So in order to allow that in tests, we do it via a SQL query directly
The computation of residual amounts on account.move.line does not use account_id.currency_id... and should not. Never.
The previous implementation was thus stupidly recomputing the amount_residual fields on all journal entries of an account as soon as its currency field was touched, for nothing.
Make an invoice for partner X
Make a payment from partner X (not using the register payment button)
On the invoice, you'll see your payment proposal
Now, reverse the move of the payment
Before this commit:
On the invoice you *still have* the payment proposal
This is because nothing reconciled the reversed entries with the original ones when they were created
After this commit:
The reversed moves are reconciled one on one with their original counterparts
And the original payment doesn't show up anymore on the invoice's proposal
OPW 1816462
OPW 1816641
Strangelly, this worked in 9.0 as the `this` element refers to the
`window` which also contains the `$` function. This may still be
wrong in some cases though, so it is fixed here (even if reported for
10.0).
opw-(1)817789
The test_mimetypes and base_import modules need various files for their
tests. Before this commit some of those files (.ods, .odt, .xlsx, .docx,
.zip) were not included in the packages.
Fixes#22778
Before this commit:
1. When enabling 'List View of Variants' on a product page, it would not
replace the variant normal view as it should since the code being replaced
is included in the code replacing it.
2.The badge specifying the price difference between the variance and the
product base price would be calculated by taking the price_extra of the
variance attribute and converting it in the user currency which was not
correct if a pricelist was set on the product variant because the price diff
would then be (the variant price set on the pricelist) - (product base price)
Note: this is about the 'List View of Variants' mode, not the normal mode
which list variant attribute and not variant itself
3. The strikethrough amount was not in the user currency
Step to reproduce:
- Enable variants & pricelists
- Enable multi-currency and activate 'COP' as second currency (you may want
to change the currency symbol on edit mode since it is also '$')
- Go to iPad Retina Display product page in shop
- Enable 'List View of Variants' in 'Customize'
- Both Variants selection mode are visible (bug 1)
- The third variant shows '+$ 50.40' which is the diff between the
strikethrough prices (in fact the sum of the price_extra of the product
variant attributes, +50,40 on the 32GO attribute in this case)
It should show '+$ 40.32' since the price change from $600 to $640.32.
This is bug n°2
- Change Public Pricelist currency from USD to COP
- Back on iPad page, change between the 3 product variants, you will see
the $ price strikedthrough instead of the COP one:
Strikedthrough: 750 (it should be 1 714 491,47)
Price: 1 371 593,17
This is bug 3
- You can notice the bug n°2 being more visible since it shows
'+$ 115 213,83' instead of '+ 92 171.07'
- Remove the iPad Retina from Public Pricelist and add iPad Retina 32Go
variant to it with a fix price of $1 000 000.
- '32Gb, 2.4GHz, White' variant cost $1 000 000 but shows '+ 115 213.83'
instead of '- 714 491.47' since the base price of Retina is
'1 714 491.47'.
- You can play with the pricelist price for this variant up and down, the
diff price shown in the badge will always be 115 213.83 since it will
always calculate it by summing all the variant's attribute price_extra
and then converting it to the user currency.
This closes#14094, closes#22553
Goffin Simon