In res.partner the Fiscal Information Tab content was broken than to a
bad adding of the Gross Income fields. This PR solves the problem.
closesodoo/odoo#88704
X-original-commit: 23f5aa3c105ca33f0146ba21d7f463a8310688c4
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit fixes "box-shadow" assignations added by default when using
Bootstrap's `.btn` classes, which result into an undesired "outline"
effect on selected buttons.
Task-2821469
closesodoo/odoo#88458
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Current SCSS is replaced with global Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2821469
Part-of: odoo/odoo#88458
In case the karma gained for the quiz is 0, avoid showing:
"Amazing! You earned 0xp".
Instead, show a standard completion message ("You did it!").
Task-2790997
closesodoo/odoo#86497
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently when uninstalling SMS notifications linked to SMS are kept but set as
email notifications. This makes no sense as they are not linked to any outgoing
mail.mail or email address. As the SMS are removed and as the SMS feature is
not available anymore it is better to simply remove existing SMS notifications.
Task-2778461
closesodoo/odoo#88970
X-original-commit: f307a6c19a2dbe64ba6120a00610063f256102d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
``CRM`` application calls ``phone_get_sanitized_number`` on partner model to
synchronize lead values to its partner values. This method is defined in
``mail.thread.phone`` mixin. ``Partner`` model inherit from this mixin in
``SMS`` application which is auto install after mail and IAP. If this app
is removed, code is not reachable anymore and lead synchronize fails.
How to reproduce
* install CRM and its automatically installed dependencies;
* uninstall IAP;
* run lead unit tests -> synchronize crashes due to missing method as partner
does not inherit from the mixin anymore;
In this commit we define the missing methods on Partner model directly into
phone_validation. In SMS the inherit order is fixed so that the mixin method
takes over the manually defined one.
Fixes#79460.
X-original-commit: eefac25da8d8a01e5f7da8fab35810da402c0bd9
Part-of: odoo/odoo#88970
Co-authored-by: Thibault Delavallée <tde@odoo.com>
In some cases, due to rounding errors, the state of a MO is incorrect
OPW-2753598
closesodoo/odoo#88964
X-original-commit: d349743c99e042ecd798aa2079695339cc9e80c5
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
If the user triggers several orderpoints one by one, some purchase order
lines may be merged while they shouldn't.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a product P:
- Type: Storable
- With a vendor V
- Route: Buy
3. Add two reordering rules to P:
- Min=Max=1 at WH/Stock
- Min=Max=2 at WH/Stock/Shelf 1
4. Inventory > Operations > Replenishment, trigger the orderpoints of P
(one by one)
5. Open the generated PO
Error: There is only one line with 3 x P, there should be two lines (1 x
P + 2 x P, one for each orderpoint). If the user confirms the PO and
receives the products, the destination location will be Stock or Shelf 1
(depending on the last orderpoint triggered)
Running the orderpoint leads to `_run_buy`, where we try to find an
existing PO line so we can update it (else we will create a new one):
https://github.com/odoo/odoo/blob/5b34adb51eda978aa9ef1a434ab77257d73b9594/addons/purchase_stock/models/stock_rule.py#L122-L129
Here is the issue: the filter in `_find_candidate` contains an `or True`
that makes a whole condition useless.
Considering [1], the condition on `move_dest_ids` is only relevant when
an orderpoint is defined. Therefore, we can remove the `or True` and
improve the condition
[1] 63fffa0bee
OPW-2720868
closesodoo/odoo#88959
X-original-commit: 0802d4c61d7b47f0b32a36c5bb0ec49a0f425043
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create the workcenter_1:
- Time Efficiency: 100%
- Capacity: 2
- Setup Time: 1
- Cleanup Time: 1
- Create the workcenter_2:
- Time Efficiency: 100%
- Capacity: 4
- Setup Time: 10
- Cleanup Time: 5
- Alternative Work centers: workcenter_1
- Create a storable product “P1” with BOM:
- Add any product as component
- Add operation:
- Duration: 60
- Work center: Workcenter_2
- Create a MO:
- select “P1” as Product
- Qty to produce: 4
- Confirm and Plan
Problem:
The workcenter_1 is chosen while work_center_2 is faster it can manufacture the 4 units at the same time
while workcenter_1 must do two cycles
As the Time Efficiency = 100%, so:
Total duration = (Setup Time + Cleanup Time) + duration_by_unit * nb_cycle
Work_center_1 = (1 + 1) + 60 * 2 = 122
Work_center_2 = (10 + 5) + 60 = 75
The calculation is bad because we use the number of cycles necessary for the work_center defined in the BOM
in the calculation for the alternative work center
opw-2821749
closesodoo/odoo#88945
X-original-commit: deb87a6abf8b8ccc4328eaac21430eedc2536361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Go to inventory > Reporting > Inventory report
- Click on “Inventory At Date” > Select a date > Confirm
Problem:
The date is not displayed in the breadcrumb, like in inventory valuation
opw-2791566
closesodoo/odoo#88943
X-original-commit: d7a09a257bfb3690a4b580ed26bbf2894a74a6c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Step to reproduce :
-set your company country in Italy
-install accounting
-install contacts
-create a new individual contact
-set the country address of this contact to Italy
Expected Behavior:
No problem
Current behavior:
Error message in function _l10n_it_normalize_codice_fiscale
Explanation:
In this fix commit https://github.com/odoo/odoo/commit/702c01661f255fe9ebbfc04c90b2cd0fa194d1e8
the case where vat is unset but the country is Italy is not rejected
anymore and a unset value is passed in _l10n_it_normalize_codice_fiscale
opw-2822259
closesodoo/odoo#88846
X-original-commit: fb5c8adc8aa86491cd2175f60c17d17bbd60b57b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
1. _get_payment_method_codes_to_exclude was not considered on _compute_payment_method_line_id
2. to avoid duplicating code on _compute_payment_method_line_id we can directly call available_payment_method_line_ids
3. to avoid re-defining dependencies (and make inheritance easier) we can use 'available_payment_method_line_ids' on _compute_payment_method_line_id
4. fix docstring, _compute_payment_method_fields does not exists anymore, it's called _compute_payment_method_line_fields
5. fix using "self" instead of pay when calling _get_payment_method_codes_to_exclude
closesodoo/odoo#88666
X-original-commit: 63d46ba547c3b0fbadd7c076451659734ad767ae
Related: odoo/enterprise#26167
Signed-off-by: Florian Gilbert <flg@odoo.com>
This commit is to prevent "AttributeError: 'NoneType' object has no
attribute '_name'"
When an xmlid does not exists, the _xmlid_to_obj returns None and the
condition was failing when trying to retrive the model name.
Closesodoo/odoo#88273closesodoo/odoo#88503
X-original-commit: e1be4b5c2dca0ca11bad724a4714f5f71c16de4f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit fixes a symptom of a more general problem which will be
investigated later.
Steps to reproduce:
- Go to apps
- Install website
- Follow the configurator flow up to entering edit mode
- Go to the 3rd tab of the editor panel
- Change the "background" color of the third color combination and
choose one of the gray colors
- Go to the backend => SCSS compilation crash
Basically, "frontend" color (complex) maps are available in all assets
(via the variables parts that all assets have in common). The original
plan was for them to be used in shared "frontend" environment like the
mass_mailing application. The web_editor SCSS generation uses those
variables to customize bootstrap variables... but it conflicts with the
backend also customizing those. That's why there is code to "clean" what
the web_editor app does when you are in the backend environment. The
problem after the mentioned steps is that this "cleaning" is done too
soon: gray colors are removed from maps to not alter backend grays and
a web_editor css rules wants to access those gray values if configured
to be used as mentioned in the steps to reproduce. This commit basically
reviews what was done at [1].
In master it should be reviewed so that the web_editor probably does not
touch any bootstrap variable when in a backend environment and/or some
code should simply be moved to the website app only. See also
web_editor.common.scss where many CSS rules depends on this and are
available in the backend... while they probably should not (like the one
which tried to use that gray value like explained above). But in stable,
we wanted to avoid changing too many things.
However, this was only a symptom of the problem: the fact that some
CSS rules should not be loaded in the backend is not a critical issue.
The real problem is that those CSS rules were breaking because the
backend assets are actually generated using website-specific assets
while the backend is supposed to be website-independant. That's probably
a bug introduced with the new assets system (ir.asset) which would
explain why this bug cannot be reproduced in 14.0. This will be looked
into in a future update. Also, this could be backported later if judged
necessary or if a traceback is actually found.
Note: the forward-ported commit also includes the fix made at [2].
[1]: https://github.com/odoo/odoo/commit/70f35620babdfdf43e2c603efbf37f2cf7399240
[2]: https://github.com/odoo/odoo/commit/0fef8cfb5dc2fc0a2d9e0352ea6a473a0d7b9dbc
opw-2735123
closesodoo/odoo#88968
X-original-commit: c58cee82939edb0ae0a95b5141d5c3b85dc404c0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this Commit, while sending the digest emails, the tip description was
incorrect due to sanitizing. Some jinja was also badly converted into
inline qweb instead of regular qweb.
After this Commit, we have fixed the tip description field value. We do the
html_sanitize after rendering the QWEB template. So, we get the proper values
of conditions and aliases. Replacing jinja with qweb template, should use
<t t-out="variable"/> to print the dynamic value so, remove the inline_template
expression `{{` and `}}` and put the <t t-out="variable"/>.
Task-2704083
closesodoo/odoo#88937
X-original-commit: c08cdc39965df1941b12a98dc80a015673f502e0
Related: odoo/enterprise#26293
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit introduce the MessageSeenIndicatorView model,
in order to move business code from MessageSeenIndicator
component to MessageSeenIndicatorViews.
Code that are not in modelling are hacky, hard to maintain,
and very prone to bug. That's why it's important to move most
code in components to models.
Task-2793280
closesodoo/odoo#88950
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Revert commit 54cd73a4f4 as it prevents customers from closing
their pos sessions without timeouting.
closesodoo/odoo#88941
X-original-commit: 43165dc3f7a8cc199219b8a32b65eb0ee7b5c2dd
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.
Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.
Task-2579306
closesodoo/odoo#88878
Related: odoo/enterprise#26277
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the tab labels of the colorpickers were too long
in some languages (e.g. German) making them overflow and making the UI
impossible to use in some cases. Indeed, the bug was different depending
on where the colorpicker was:
- In the text tools, the colorpicker overflew the whole panel, making it
impossible to use
- In the snippet options, the colorpicker buttons were cropped without
ellipsis making them impossible to read
- In the backend, as the toolbar is floating, it was ok but the code was
quite dependent of the other colorpicker-related scss
This commit solves those problems and unifies the way colorpickers look
independently of their position (always full width, the buttons fill the
available space, if the buttons are too long they are cropped with
ellipsis, they have a title on hover and are always aligned on the
left of the tabs area).
opw-2786778
closesodoo/odoo#88844
X-original-commit: a4755218f239e5c00e9c6a23321654a3ab029470
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes the timer that was cropped out when taking a
survey having a time limit on mobile devices.
Task-2810299
closesodoo/odoo#88910
X-original-commit: 6c7f8eeb275d8de9e06fe70cde293e18beb8fc01
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In v15, the rule `hr_leave_rule_employee_unlink` has been modified.
Because of that, during an upgrade to v15, the rule is reloaded from the
security xml.
If the rule had been edited and `perm_unlink` was set to False, since its
value is not explicitly stated in the xml, the upgrade will fail by
violating the constraint `ir_rule_no_access_rights`.
Related:
https://github.com/odoo/upgrade/pull/2127https://github.com/odoo/odoo/pull/65361closesodoo/odoo#88908
X-original-commit: b3994a0277a165ceedd2e8df1f31da7044b8d33e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To reproduce:
1. Start a meeting in Discuss or start a group conversation of V15, then try to leave this channel by clicking channel's x button in the page's left side `DIRECT MESSAGES` list.
2. After clicking `Leave` button in Confirmation dialog you will get Access Error prompt: Due to security restrictions, you are not allowed to delete 'Listeners of a Channel' (mail.channel.partner) records.
Cause and Solution: the computed field value:
Since in the middle of process, outdated.channel_id.channel_partner_ids doesn't contain current env.user, to bypass access rule restriction we need to use sudo().unlink()
closesodoo/odoo#88897
X-original-commit: b3d371a4380305a2ea8fd14c30432e6ddbd9cb35
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
There is an issue where we redirect to a list view/form view of
res.partner but with id's from res.partner.bank, thus redirecting to
the wrong views.
closesodoo/odoo#88865
X-original-commit: a1cce790fcd2d1823fb9e3d5c3c3e916d34568e5
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
- The dashboard list view is replaced by a kanban view.
- When you have a time off with a joined document when you click on it, the attachment view is now kanban and not list. The dropdown in the kanban card allows to download the file.
taskID #2658415 [Time Off] Mobile experience
closesodoo/odoo#84667
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Additional resources of a lesson content are displayed twice, once as a
link and an other time as a file
Steps to reproduce:
1. Install eLearning app
2. Go to the website
3. Go to Courses and open course 'Basics of Gardening'
4. Open the first chapter 'Gardening: The Know-How'
5. Exit fullscreen (on the top right)
6. In the course content, the file 'Document' is displayed two times and
the link doesn't work
Solution:
Display the resource as a link or file depending of its type
opw-2811279
closesodoo/odoo#88879
X-original-commit: 924c3e849f9f5b2408cefc913ee1d72243417feb
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Follow-up of: https://github.com/odoo/odoo/pull/87597
This is the 2nd and final step of splitting public_livechat.js
into several files.
This is part of refactoring public livechat so that it uses
essentially the same codebase as discuss in the web client.
Splitting in smaller files helps following steps to refactor
the code.
Task-2818675
Part of Task-2212347
closesodoo/odoo#88654
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Observed Behaviour
When using a pricelist with a fixed price for all products with a different
currency than the one of the company, adding shipping cost in a sale order
using this pricelist will give a wrong value of the shipping cost
Expect Behaviour
The computed shipping cost added in the sale order should be the same as the
fixed price defined in the pricelist
Reproducibility
This issue can be reproduced using the following steps :
1. Define a pricelist PL1 with a fixed price for all products and a different
currency than the one used in the company (eg fixed price to 15KR)
2. Create a sale order and select PL1 as pricelist
3. Add a product and add a shipping cost
The shipping cost should be the defined fixed price (15KR) but it gives
another value, depending of the company currency
Fix Description
This fix remove a useless currency conversion coming from the fact that since
https://github.com/odoo/odoo/pull/86484 we get the delivery price from the SO
priceliste (using pricelist.get_product_price) giving us a price that is
already converted to the correct currency
Related issue/PR
opw-2810506
closesodoo/odoo#88861
X-original-commit: 25e2f403e88172d67ea6ce382ac1e3f5e0e37835
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
When setting acc_holder_name on the bank account receiving the payment of a QR-bill, acc_holder_name was used instead of the company's name inside the QR-code, but not on the summary text displayed next to it. This fix replaces the company name there as well. The behavior is unchanged when acc_holder_name isn't set.
closesodoo/odoo#88804
X-original-commit: e37d43d52d56e55291f9deb0eb76b5cd3863739e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
This PR introduces multiple changes to improve potential inheritance regarding
products.
Purpose
======
Be able to sale products on eCommerce that have some specificities regarding
their price computation. For example, accommodation price depends on the duration
of stay, or rental product price depends on the duration of the rental.
Specifications
===========
This PR introduces some hooks or methods as :
- Add kwargs to price compute methods in order to give some additional parameters
- Allow adding optional parameters to product/cart rpc to give additional information
concerning product.
- Make the cart-quick-add button displayable with a given condition on the product.
- Regarding stock on eCommerce, improve the inheritance of the cart quantity and
the free quantity computation (which may depend on the temporality). It also allows
to increase the inheritance potential of the computation of the max quantity of products
that can be added to cart.
- The stock warning field is now added in the eCommerce module to allow other
eCommerce modules to take advantage of this message prompt.
task-2382027
See also https://github.com/odoo/enterprise/pull/23741
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#83359
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
SPECIFICATION
Before this commit when setting a forum which was already selected
by another course one got an error message when saving.
This commit avoid this error message by only displaying the forum
which have no course attached to them.
LINKS
Task-2791247
PR : odoo/odoo#86584
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps :
Install modules hr_holidays and google_calendar;
Log into Odoo with two different users, one manager and one employee (subordinated): f.e. Admin e Demo;
Set Google Client ID and Google Secret with a OAuth2.0;
Check if in Odoo's Calendar the Synched with Google tag compares on the right (with manager);
From employee user, go to Time Off -> My Time Off -> My Time Off Requests and Create with a date;
From manager user, go to Time Off -> Managers -> Time Off and accept the time off created;
Go to manager's Google Calendar.
Current behavior:
Google event is created and visible for manager, employee has an event since is an attendee of the first.
Expected behavior:
Google event is created and visible for employee, manager is not involved.
Fix:
Group the leaves with user and create events with this user.
We could not modify easily the behavior of the calendar sync modules.
The following approach was tested: odoo/odoo#86385
But it has some side effects on recurring events, oultier events
(events not following the recurrence) and could bring performance issues.
The solution of this fix was chosen because it is less intrusive.
opw-2761158
closesodoo/odoo#88607
X-original-commit: ce96dd4f7488ce66d3fda5fd09a4566424c52bd2
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Steps to reproduce:
- Set a new DB without demo data
- Install Ecommerce
- Switch language to Arabic
- Try to open website module
Issue:
Traceback raised.
Cause:
When generating random sample data for website dashboard, it will use
the current local to generate dates (in the given format), who in this
case have a non-latin numbering system, and therefore will break when
trying to parse field value.
Solution:
Use `serializeDate` or `serializeDateTime` to format datetime (with
`latn` as `numberingSystem`).
opw-2743243
closesodoo/odoo#88840
X-original-commit: 5597912ad65e0b98c498f95ba884b9581a737211
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Co-authored-by: Nasreddin Boulif (bon)<bon@odoo.com>
Before this commit, the internal user can access to all milestones
created in Project app even if he has no access to the project related.
This commit adds the rules for the project.milestone to filter the
records when the user is not a Project Manager.
closes odoo/odoo#88819
X-original-commit: 6438d8e690229b27ab08ecac436e54a85096eb0f
Forward-port-of: #88546
Forward-port-of: #88509
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Before this commit, the portal user can read the `project.update`
and `project.milestone` records but there is no reason to grant this
access for those models.
This commit removes the read access for thoses models since we don't
show the data in its portal.
X-original-commit: f0331531826974ddaab5dff28739115c37a351c0
Forward-port-of: #88546
Forward-port-of: #88509
Part-of: odoo/odoo#88819
The Credit Limit group on the res.partner record
doesn't appear until you save the record.
This means you have to perform extra clicks
if you want to edit this value.
The goal is to show the `credit` field on the accounting tab
on creation if `res.partner` is a company and
Credit Limit setting is activated.
task-2817650
closesodoo/odoo#88830
X-original-commit: 0ac5f58d4d4786a0b86bf0b71406d7d2c5d470bf
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Instead of doing the difference between output tax and input tax, the tax report was doing the sum.
This commit fixes this computation without revamping the rest of the report
closesodoo/odoo#88774
X-original-commit: df0372a168db184c03fd901359fec6abd08f5bdd
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps :
Create a Time Off Type T.
Create 2 Allocations :
> Type : T
> Start date : monday D
> End date : /
> Number of days : resp 4 and 1
> Employee : Admin
Create 2 Time Off Requests :
> Type : T
> Dates : resp monday D to thursday and friday to friday.
Validate both.
Issue :
Allocation's days taken are resp 5.0/4.0 and 0.0/1.0.
Cause :
We set allocation to leave before validating.
To do so, we take the alloc with max allocated days.
Fix :
Take the alloc with max days left = allocated - taken.
Recompute the allocation before validating,
to check that enough days are left.
opw-2812534
closesodoo/odoo#88773
X-original-commit: b0bace129e3f9a4876c2cefb2c24cbcb76d8b0c6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
X-original-commit: 0ad8faf3bfc7b28e5668c3445fcc06c24ad98354
[FIX] account_*: payment method journal filter
Fix two issues linked to payment methods and their journal link.
SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.
There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.
opw-2777522
closesodoo/odoo#88677
X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>
Joseph Caburnay