Steps to reproduce
==================
In 16.4:
- Go to Accounting > Reconcile 8 items
- Click on the first line on the right
- Edit the label and then press Enter
- Switch to another line
=> Odoo Server Error
Cause of the issue
==================
When pressing Enter, two events are triggered: keydown and change.
In the useInputField hook, there is a listener for both of those events,
and they both end up calling `record.update` with the current value from
the input.
In the relational model, the update is locked inside a mutex.
So the first update (triggered by the keydown) does an onchange.
This onchange deletes the current records (Command.CLEAR) and returns
new records.
Once this is done, the mutex is released. The second update (triggered
by the change event) then tries the same update. Since the value was
obtained when queuing for the mutex, it uses the old (now deleted)
record.
Solution
========
This adds a test for https://github.com/odoo/odoo/pull/154991
as part of the fix got lost in a conflict resolution for previous versions.
opw-3726818
closesodoo/odoo#157155
X-original-commit: fbebffe446de9dd80db2dbe5ca7bd2746dc2a54f
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia,
there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function.
closesodoo/odoo#157144
X-original-commit: 601c8b8a0b4aff44811fd37f365cc62205cf96f0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
To reproduce:
- Install account_accountant
- Create an asset (monthly for example)
- Compute Depreciation
- Modify the date of the first entry to 2 months later
- Modify the date of the second entry to 1 month later (so same month)
=> Traceback
The problem is that sorted does not work with ids of NewId. We should
look at its _origin.
There is a PR that would try to fix it in general, but it's in master
(and is not sure to be merged https://github.com/odoo/odoo/pull/155850)
The problem only began to occur in 17.0 because of the changes of the
onchange function.
opw-3759153 (in chatter)
closesodoo/odoo#156874
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
`Environment.__new__` expects a Cursor.
Ensure developers pass a Cursor and not another kind of unexpected object.
Passing another object with the same attributes would work during
the creation of the new environment, but then would fail later,
when using the created environment with the wrong `cr` attribute,
with a less comprehensive error.
Task-3796479
closesodoo/odoo#80644
Signed-off-by: Raphael Collet <rco@odoo.com>
Social users / managers shouldn't be able to access these keys,
only admin should.
For instance, in the user interface, it's only displayed in
settings, which is available to administrators only.
Task-3762961
Signed-off-by: Yannick Tivisse <yti@odoo.com>
-Step to reproduce: add a post_load method in the init of any module,
specify in the manifest like : 'post_load': 'post_load'. in v16 or above
Run
test_manifests of the test_lint module and we will get warning
closesodoo/odoo#156593
X-original-commit: f87473e82af8372346320ca747c1b41d3d5cf3c5
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The confirmation page wasn't displayed and the order wasn't sent to the
preparation display when confirming an order with a total of 0.
Now the confirmation page is displayed and the order is send to the
preparation display when the order is confirmed regardless of the total
amount.
closesodoo/odoo#157028
Related: odoo/enterprise#58348
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The previous fix ae3ec52 introduced a dict to display the values
required in the zpl label template.
This change didn't also update the template inheriting this one, hence
the need for this fix.
closesodoo/odoo#157160
X-original-commit: 416d29a59fb310071c2b7ed25e3032968b23d966
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Step to Reproduce :
-> Create product: Project & task
-> Create SO > Add product > Confirm it
-> Go to Newly created project > Project update > Sales order
-> Click on the project stat button > again go to project status > Sales Order
-> Crash it
Before these commit:
-> Clicking on so stat button in project update caused a traceback error that
null value is not defined.
-> When we are passing the context It was observed that create key
has null value in that context.
-> In sale_project if create_for_project_id has a null value then create key
also have null value.
After these commit:
-> So if we set False in the context, If we get null value of create key
it is set to False.
task- 3586341
closesodoo/odoo#157170
X-original-commit: 26d4c86ca1f8186811275cf6d001ef7105a07776
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Fix to avoid considering TS lines for projects linked to global time off
closesodoo/odoo#157156
X-original-commit: 2e46a8e9179a83709638bdefc7e664837cbd8e92
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When a slideshow opens, the keyboard events don't work right off the
bat. You first need to click on one of the arrows before being able to
interact with the keyboard, which defeats the purpose.
Steps to reproduce:
- Drop an Images Wall snippet and save.
- Click on an image: the slideshow appears.
=> Pressing left, right or escape doesn't work.
- Switch to the next image.
=> Pressing left, right or escape now works.
closesodoo/odoo#157126
X-original-commit: 32c6f7e7688eb3b05d569e1895e8fc102f71baf4
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
In odoo/odoo#93802 some filters (including submitted) were removed from
hr.expense.sheet view in favor of the side panel.
Meanwhile, action_hr_expense_sheet_department_to_approve
was not adjusted and was still using the removed filter.
This commit changes the action to also use panel view.
task - 3578235
closesodoo/odoo#157109
X-original-commit: 664442e75787b9c61dcfbeea56c2bab071c2fa7a
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
When creating a sub-task from a task form view in portal, the domain of
the stage should exclude personal stages and include only the one of the
project.
taskid:3551354
closesodoo/odoo#156776
X-original-commit: 3be073e73b5866d7b5da8cc549146be5efb5d7d0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Replace the hardcoded date "09-15-2022" in the list domain by
`context_today().strftime(\"%Y-%m-%d\")`
The domain is now stringified since it contains a dynamic value
which is not valid in a json file.
closesodoo/odoo#156550
Task: 3756934
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Currently, if you have an empty MISC journal and receive a document,
that document will be assigned a MISC sequence, regardless of the actual
document's type.
Cause
-----
When a document is received, it is processed in two steps:
1. An empty account move is created and linked with the document.
2. The newly created move is populated with data extracted from the
document.
At stage 1, when the move is created, it is temporarily placed in the
MISC journal. In the event that this journal is empty, a sequence is
assigned to the move. Consequently, even if the move's journal is
subsequently changed, the sequence remains unaltered.
Fix
---
Manually recompute the sequence when the move's type is set.
opw-3663873
closesodoo/odoo#155887
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
To reproduce:
=============
- create a `product.public.category` -> (id = 15 for example)
- create a `product.tag` with same id as the created category
- create two products, one with the category and the other with the tag
- go to the shop and make sure to have the categories positioned on left
(by default they are on top)
- select the tag (by clicking on the label not the checkbox)
-> the category is selected
Problem:
========
with this configuration the checkbox of the category has `id=15` attribute
and the tag has `id=15` attribute too.
so when we click on the tag label and thanks to the `for=15` attribute of the
label, we will trigger click event on `input#15` which is the category checkbox
because it's the first one in the DOM.
Solution:
=========
set id of the tag to `tag_15` and the for attribute of the label to `tag_15` to
avoid the conflict with the category checkbox.
opw-3759654
closesodoo/odoo#157095
X-original-commit: 15545301a05b538729da3c59e4d24063e9b02cb5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
__Current behavior before commit:__
`/jobs` routes have been modified in [this commit][1]. Old ones are
deprecated but are still working for backward compatibility.
When searching on this page, search params are now just added at the end
of the URL (instead of being part of the path like before).
If the URL of the page is a deprecated one, this can create a conflict
with the previous way the params were handled and produce an error.
__Description of the fix:__
Redirect the user to the new route any time he tries to reach the
deprecated ones. Any parameters included in the old URL will be carried
over to the new route to maintain expected behavior. If a parameter is
provided both in the path and as a kwarg, the kwarg value will take
precedence.
__Steps to reproduce the issue on runbot:__
1. Go to `/jobs/country/20`
2. Make a search using the search bar -> Crash
opw-3781374
[1]: https://github.com/odoo/odoo/commit/54f246f9c75b8f1ebdc637c6000f3e4773d702d5closesodoo/odoo#157079
X-original-commit: 5a9ce2d7773222ac8989e3172f9363a7d6f71871
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Don't try to keep extra params and co. Keep it simple...
Else we should pop from request.params `blog` and `post` keys because
now they are converted as query param with the slug format:
/blog/name-1/post-1?blog=blog.blog(1,)&question=blog.post(1,)
closesodoo/odoo#156990
X-original-commit: 5b1eacba2e09687d627988c53910110bfb63ed1d
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Codes like "Exch.Rate" in the Italian EDI XML template for invoices were
translated. They shouldn't be, as they have pretty short char limit and
it's risky to people change that. The XML users are either domestic or
the Italian Tax Agency itself, so no point in translating "Divisa" into
"Currency" anyway.
Link: https://www.odoo.com/web#model=project.task&id=3627379
opw-3627379
closesodoo/odoo#156987
X-original-commit: 8c6c244ada17b21c4f20c8ae566f44efdfeab162
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to reproduce:
- Create a new company contact and add a contact inside that company
- Create two service product that are service with following config:
- Invoicing policy: Based on Timesheets
- Create on Order: Project & Task
- Make an SO for the contact inside the company with the two service in
the order
- Confirm the SO
- Click on the smart button "Recorded"
- Click on new
- Click on new line at the "Sale Order item" column
Issues:
The list display "No records"
Solution:
Make sure that we search with the correct attributes, before we were
trying to match partner_id and commercial_partner_id.
Although similar in our case they are not equal as commercial_partner_id
represent the company and partner_id represent the individual.
opw-3750939
closesodoo/odoo#156471
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Install the l10n_de package
- Create and select a german company
- Accounting > Configuration > Settings > Fiscal localization
- Set: Deutscher Kontenplan SKR03 for the fiscal localization
- Accounting > Configuration > Accounting > Fiscal Positions
- Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position
translates to "Business partner EU (with VAT ID)".
Issue: The `vat_required` field of this fiscal position is False but
sould be True as the fiscal position is "(with VAT id)".
Cause of the issue:
The `vat_required` field is a Boolean of the account.fiscal.position
model without defaut value nor compute method. As such it is interpreted
as "False" when unset (just like any unset python boolean).
Since the `vat_required` field is not set in the data file of the
`l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)"
fiscal position, it will be interpreted as False.
Fix:
We update the data file of the fiscal localization to the expected value
opw-3721912
closesodoo/odoo#157022
X-original-commit: 19703adb2f7a5f790ee3c9a3037be6cdf189efd7
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
This commit prohibits the archival of a company if it is associated with
a website. Otherwise, the website wouldn't be accessible anymore by
public users (and so by all users if they need to login).
Step to reproduce:
- On website 2, change the company from SF to Chicago
- In the website list view (in debug mode), reorder the websites so
website 2 is the first one in the tree view
- Archive the Chicago company (from debug > companies and do it from the
list view)
- Try to access the website/runbot from an incognito tab
- It will show a raw 403 error
Note that the companies can only be archives since Odoo 16, thanks to
this commit: https://github.com/odoo/odoo/commit/7d0996bb151f68647b22719eee5ed4a4c35574bb
opw-3749772
closesodoo/odoo#156988
X-original-commit: d7456bf5376cf53670dbe8eaf1a2281aa254d521
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Due to a refactor of the code in [1], the string "Save current search"
in the filters dropdown was not translatable anymore.
This commit fixes that, so it is translatable again.
[1] 976491e012closesodoo/odoo#156946
X-original-commit: 5f1d6f26d6bfe1f23f4098eae2e0b32300adefda
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Steps to reproduce:
- Go to website (Homepage) > Switch to "Edit" mode.
- double-click the "Contact Us" button in the header or keep clicking it
many times > Traceback: Cannot read properties of undefined (reading
'find')...
After converting the `linktools` widget to Owl in [1], the DOM element
of the component [2] was retrieved in an async process after it was
mounted, (some legacy code can trigger the instantiation of the
`linktools` when its parent component is not in the DOM and
`this.linkComponentWrapperRef.el` won't be returned, see: `Link` >
`onMounted`).
When double-clicking the link, This implementation will lead to a race
condition where the `onWillUpdateProps()` (mainly triggered by the click
to focus the URL input...) will try to access the DOM element from [2]
before being correctly set in `onMounted()`.
The goal of this commit is to fix this behaviour by simply waiting for
`onMounted` changes to be done before doing any adaptation on the
`linktools` DOM.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
opw-3706902
closesodoo/odoo#155418
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
compute_packages method fetches all columns for stock_move_lines and its
result_package_id. If stock_move_lines are a big number, it causes
memoryerror. Pre fetch only the required fields. Also its better
to use _read_group then search count in a loop. For one database
it needed '2546604' stock_move_lines for a memory error to occur.
closesodoo/odoo#154150
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Add support for Internal Reverse Charge invoicing flows in Italy.
- Add 0% sale taxes and purchase taxes targeting VJ grids in `l10n_it`
for every Tax Exemption Reason involved (Scrap, Gold...)
- Add a Fiscal Position (equivalent to the Belgian "CoContractant" one)
mapping the sale tax and purchase taxes to their Reverse Charge
corresponding taxes. Those fiscal positions all have a different
law-required note (with the law reference) that has to be printed
on the PDF invoice through Odoo standard mechanisms.
- The way we compare the invoice features and each document type
requirements has been revised and expanded for the tax_tags sets case.
Now it should also avoid comparisons after the first failure, instead
of doing all the comparison anyway.
- Imported vendor bills that have TD16, TD17, TD18 now have their
0% reverse charge sale taxes converted to their purchase
22% VAT reverse charge corresponding tax impacting VJ tax grids,
following this mapping:
Sale tax examption reason -> VJ grid targeted by purchase tax
N3.2: VJ3
N3.3: VJ1
N6.1: VJ6
N6.2: VJ7
N6.3: VJ12
N6.4: VJ13
N6.5: VJ14
N6.6: VJ15
N6.7: VJ16
N6.8: VJ17
- Vendor bills that have taxes targeting grids VJ6, VJ7, VJ8, VJ12,
VJ13, VJ14, VJ15, VJ16, VJ17 are exported as Tax Integrations XMLs
to be sent to the Tax Agency with the document type TD16
- Vendor bills that have taxes targeting grids VJ3 are exported
as Tax Integrations XMLs to be sent to the Tax Agency with
the document type TD17
- Vendor bills that have taxes targeting grids VJ9 are exported
as Tax Integrations XMLs to be sent to the Tax Agency with
the document type TD18
Link: https://www.odoo.com/web#model=project.task&id=3724926
task-3724926
closesodoo/odoo#153556
Signed-off-by: Josse Colpaert <jco@odoo.com>
Added a small message in the chatter on an invoice when the invoice fails import.
Silencing errors on a blank invoice doesn't help us fix issues and
doesn't solve the import problem.
Part-of: odoo/odoo#153556
In Luxembourg, during the year 2023, the VAT rates were decreased by 1%
temporarily. Now that we are in 2024, we need to deactivate the taxes added
previously. We will not remove them so that client can still use them if needed.
closesodoo/odoo#157015
Task: 3635758
X-original-commit: 75cb238785c4979846a2db434bb5a715fec44867
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
If a partner doesn't have peppol eas or endpoint set, we still go through with checking participant's registration. This is not an issue if checking on a partner form, as the Verify button is invisible without these details being filled in. However, in the partner list view the button is always visible and it is possible to run verification for non-peppol customers. As a result, all of them show up as valid Peppol participants.
With this commit we only run verification if there are eas and endpoint details.
opw-3784945
closesodoo/odoo#156973
X-original-commit: 3caea860633744b547126f579da0c712b318e515
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
When mixing anglo-saxon accounting and multi-currency, it sometimes
leads to incorrect AMLs in the stock-in account
To reproduce the issue:
(Company in USD)
1. Setup some currency rates:
- Yesterday: 1000 EUR = 4335.1 USD
- Today: 1000 EUR = 4348.0 USD
2. Create an auto-avco product
3. (Yesterday) Buy one product at 1000 EUR and receive it
4. Deliver the product
5. Bill the PO
6. Open the journal items of stock-in account
Error: The AML for the exchange difference has been created twice
When posting the bill, it leads to `_generate_price_difference_vals`
where we generate AML/SVL in case of price differences. There, we
also generate such records in case of exchange difference. This is
what we do in the above use case. However, the AML is wrongly
encoded, we need to respect some specific conditions:
https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779
Otherwise, the reconciliation process won't work correctly and will
generate its own AMLs for the exchange difference (hence the above
error).
On top of that, to ensure a full reconciliation, we need to first
reconcile the exchange diff AML with the bill one. This is what we
are supposed to do in `/stock_account`: we split all stock-in AMLs
into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`.
However, we don't correctly isolate the correction AMLs. Therefore,
we try to reconcile all AMLs at once, which will not work.
Note: This commit brings a behaviour change since the amount
currency of exch-diff AML will now be zero, as it should (again, see
the comment of the code quoted above in the reconciliation process).
This also explains why this commit modifies an existing test:
comparing the `balance` and the `amount_currency` of such AML is
incorrect.
OPW-3544318
closesodoo/odoo#156951
X-original-commit: 19403baf53c38d3969b3ef1f97af955b5d454481
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, if a receipt was reprinted, the QR code was not
included. This could lead to issues with receipt validation and
scanning.
opw-3763169
closesodoo/odoo#156948
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
- Setup 2 companies with a COA: compA & compB
- For compA, have a journal having some data
- Give you access to compA & compB but make sure compB is your main company
=> samples data are displayed on the accounting dashboard for the journal
- Setup 2 companies with a COA: compA & compB, compB being a branch of compA
- For compA, create a journal
- Add some data into this journal using compB
- Give you access to only compA
=> you should not be able to see the data from compA since the data belongs to compB
Introduced by:
https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf
This commit also adds the company check in all queries/domains to manage the
branches correctly.
closesodoo/odoo#156737
Issue: 3722386
X-original-commit: a8097355ee8c4891ba4161fd82eb54f5d2d80e8c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
**Before Commit:**
- In the point-of-sale, when a company had branches,
- The branch company was unable to use the fiscal position of its parent
company.
**After Commit:**
- The branch company can now use the fiscal position of its parent company in
the point-of-sale.
Task ID: 3775865
closesodoo/odoo#156676
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
When the user creates a branch company, the pos(accounting) setting does not
allow the selection of a default temporary account for the user.
After this commit:
The user is allowed to choose a temporary account from the branch company.
Task-3775873
closesodoo/odoo#156478
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
When a company having branches,
they uses the same taxes as the parent company,
In POS settings, the default tax used a company domain
which does not allow branch to change the default tax
After this commit:
A branch is allowed to change the default tax
task-3775857
closesodoo/odoo#156434
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Set 'Rounding Method' to 'Round globally'
Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)'
Create a Payment term with 1% discount if paid before 30 days
Create a company partner with child contact
Create an invoice:
- Add as partner the company partner (parent contact)
- Add a line with product 420.99, tax 21% not included
- Add the payment term
Tax total will show 87.52
Add the child contact as partner (set again payment terms if needed)
Issue:
Tax total will show 87.53
This occurs because, when simulating the not yet stored epd vals,
we create the line using the `partner_id` and not the commercial
partner.
Then, when tax amounts are aggregated and rounding errors are managed
the partner is used as grouping key to retrieve vals, so we don't fix
the rounding error correctly
opw-3661210
closesodoo/odoo#156412
X-original-commit: 3c3c12f1427c7138357a7b4abffb4a15b1fd4dd5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
She disappeared between 15.2 and 16.0 but seems she is still alive. Commit
odoo/odoo@88483a6 does not seem to have been forward ported after 16.0.
closesodoo/odoo#151920
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the user doesn't have rights to registrations and tries to change the partner
on a SO, this will raise an access error even if there's no registrations linked
to the SO.
We use sudo to be coherent with what is done in _update_registrations.
Followup of odoo/odoo@fb17edd coming from odoo/odoo@19878d0
X-original-commit: 808ceb2
Part-of: odoo/odoo#151920
orderpoint creation should also consider archived location
while computing qty_available or else users will be faced with
a `KeyError`
closesodoo/odoo#156965
X-original-commit: 1467cc1a2d773b8c7cbb4410c5c2f756764ca7c8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Some templates are rendering the blog post cover in a very blurry way.
It was not detected sooner because of a mix of:
- The default blog posts img do not go through the `/web/image` route
and are not resized down / impacted
- Some of the layouts are working fine
- For the problematic layouts, the problem gets worse when you select
only one or two "Fetched Elements".
Steps to reproduce:
- Add an image on a blog post (you can just download the one on the PR)
- Add a "Blog Posts" dynamic snippet on a page
- Select "Card Layout"
- By default, you'll see that the image is very blurry. If you select
2 (or 1) instead of 3 fetched elements, it will get even worse.
Note that it's like that since forever, when it was introduced with
https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
opw-3771992
opw-3758676
closesodoo/odoo#156962
X-original-commit: 7d817e950f9e7c18a504d8bff04e02efb9d9dbde
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
to reproduce:
=============
- make a task recureent
- change its state to a closing one
-> Validation Error
Problem:
========
- when creating the next occurence, we insert the followers of the original
task in the new one, but it happens that we create a `mail_followers` twice
which violates an SQL constraint of `mail_followers`.
https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262
the create method will create `mail_followers` for the task and as the condition
that follows is truthy in this use-case `_insert_followers` will be called
and create `mail_followers` again.
- In previous versions we didn't face this issue because the creation of
occurences was done by a cron, so the condition was never truthy thanks to
`and self.env.user.active`.
Solution:
=========
to make sure the conditon stays falsy, we set `mail_create_nosubscribe`
in context to `True` when creating the next occurence.
opw-3742737
closesodoo/odoo#156945
X-original-commit: 64ca453bc36740ce4afcd46c1afbbb31abffdf7c
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
If the user has access to picking types as a stock manager without having access to pos config, deactivating a picking type triggers an AccessError on pos.config.
closesodoo/odoo#156820
X-original-commit: 743c70e8d4e753200411aeedc8482c374792b1d5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Hubert Van De Walle