WHY: it's computed field that is not supposed to be editable. In previous task
it was asked to make it visible, not editable.
closesodoo/odoo#64676
X-original-commit: f7788fdf03bcf81710f5b01fbf67a90aa30e1e58
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When the customer use Anglo-Saxon stock valuation and have already
reconciled some `account.move.line` related to an open `pos.session`,
closing the session will fail.
(You are trying to reconcile some entries that are already reconciled)
Now, the reconciled lines are ignored.
The inventory valuation is still correct as these lines were already
reconciled.
opws:
2374559
2376187
2377958
2391395
2425197
closesodoo/odoo#64668
X-original-commit: 3f939af62df65dcb9c8cdd2ecc3ac3d4c2983a2f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
BEFORE: sms templates from these modules become inaccessible if any module from
the list below is installed
* crm_sms
* event_sms
* stock_sms
* enterprise/account_followup
* enterprise/marketing_automation_sms
* enterprise/sale_subscription
those modules add security rules for sms.templates, which adds additional
conditions to get access: at least one security rule has to be passed. So, we
need to add such rules to give access not only to Superuser
closesodoo/odoo#64661
X-original-commit: 23c82340c1cbd3d5a25d5c2ecec6c7d0f988cd90
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When reconciling a statement line with multiple lines in a multi-currency environment, it could lead to a rounding issue due to the currency rates. It could lead to an auto-generated open-balance of 0.01 amount to auto-balance the journal entry but the result is wrong since the partner has an open amount left on the receivable/payable account.
closesodoo/odoo#64636
X-original-commit: 4d4e6e588d14742f153a1c6b67d510e0c21e5d64
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Restore Project Kanban view for mobile.
Added a name for the default stage of the tasks in the Internal project
Removal of redundancy for the creation of the Internal project and its tasks
Fix task_reccurrence for the type 'after'. (too much task created or bad task created)
Task-2326258
closesodoo/odoo#64607
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In order to clarify the purpose of the account_lock module, slightly
update its description.
Task id #2382740closesodoo/odoo#64559
X-original-commit: f15188907a63d3f50c80c8254e60b9f31a666c55
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
From Invoice list view select 2+ invoices (A, B), click Action>send and print
In each invoice 2 invoices will be sent:
- In A, you'll find A and A
- In B, you'll find A and B
This occur because the composition_mode of the composer is computed
after the attachment has been generated.
When the composer has an attachment, it is included into
the sent mail along the relevant one, generated on the fly for each record.
opw-2428544
closesodoo/odoo#64445
X-original-commit: 9b585963a4b4f53b856b219004322232c2acf318
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit:
- The precision on geolocalisation fields were set to (16,5) which
caused rounding when data was comming from Goolge.
After this commit:
- The precision on geolocalisation fields are set to (10,7) which is
aligned with what Google does.
This precision of (10,7) is actually already used in the Sign App.
task-2426985
closesodoo/odoo#64401
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Currently, the signature of the admin defaults to 'administrator'. Odoo
does not take into account the actual name of the user. The onboarding
experience would be better if the signature was personalized
for the user.
SPECIFICATIONS
The default signature of the admin is his name (Mitchell Admin) instead of 'Administrator'.
Task-2416715
closesodoo/odoo#63914
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this task is to improve the various modules like crm_iap_lead, hr,
hr_timesheet, product, project, web.
So in this commit done the below changes:
- timesheet: project is open in the form view insted of the quick view
- earlier the popup window notification is sticky so after this commit it will
disappear automatically after a few seconds
- product form view: 'extra prices' display as a link
- project sample data: move the helper a bit higher in mobile view
- CRM > Generate leads > industries > search more: rename 'tag name' into
'Industry'
- preferred_role_id: 'ceo' written in all caps
- employees kanban view: the chat icon aligned to the bottom of the card
- move the project tour droplet to the right of the add button.
closesodoo/odoo#63693
Task-id: 2374726
Related: odoo/enterprise#15426
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit groups creation and posting of account moves related to
stock valuation in case of automatic valuation product.
Previously, the account move were created one by one and posted right at
the creation. Which can really slow (for instance running
_run_fifo_vaccum with a large amount of remaining quantity layer)
closesodoo/odoo#62700
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When using the route `/report/barcode/...` in a report, wkhtmltopdf
makes htpps requests on the server to retrieve the barcode image.
If a lot of barcodes have to be printed, this can overload the server
with too much requests and makes wkhtml crashes.
With this commit, the qweb barcode widget is used to include the barcode
as an img tag with inline barcode image as base64 data.
closesodoo/odoo#64211
Related: odoo/enterprise#15619
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When printing barcodes for a large amount of records, wkhtmltopdf will
make the same amount of http requests to the server in order to retrieve
barcodes. This can lead to performance issues or wkhtml to crash.
Fortunately, an already existsing qweb widget exists that include
barcodes images as inline base64.
With this commit, the web widget is a bit improved to accept attributes
for the generated image tag. Each option dictionary key starting with
`img_` will be converted into a tag attribute with the corresponding
value.
e.g.: `'img_alt': 'Barcode'` will result in `<img alt="Barcode"...`
The `alt` img attribute now defaults to `'Barcode %s' % value` with the
barcode value.
Also, the `quiet` reportlab option is also avalaible in the widget
options, as well as the `mask` option.
Finally, if the `symbology` option is not given, the widget defaults to
`Code128`. If `symbology` is set to `auto`, the action report will try
to guess the barcode type, based on the len of the value.
The design was not properly adapted to the last changes before the 14.0
release and still contained some invalid properties. Now the list inputs
match the design of the normal inputs.
closesodoo/odoo#64400
X-original-commit: fe102c04c0526cb7aa547f146974cdfb80629723
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, when opening a colorpicker in safari, the crash manager
would open with the message "An unknown CORS error occured [...]". This
is actually odoo's default message when an error has no file, line or
column, which is usually the case for security reasons on CORS error.
This is however not a true CORS error, but a "ResizeObserver loop
completed with undelivered notifications" error, which also does not
report file, line and col for the error.
This error is caused by the fact that in webkit, the baseline of an
empty input is considered to be at the bottom of the input element,
rather than at the baseline of the text of the input once it has some
content. (see https://bugs.webkit.org/show_bug.cgi?id=142968 )
In the case of the colorpicker, it uses a ResizeObserver to update its
UI, including updating the content of its inputs. This will cause the
first _updateUI to fill the empty inputs, which changes the layout of
the widget content and changes its size. Changing the size of an element
inside of a handler of a ResizeObserver on that same element will cause
an error and not call the callback again, so as to prevent infinite
loop.
This commit fixes that by filling the inputs before attaching the
ResizeObserver, so that it has its final size from the get-go, and
_updateUI will no longer change the layout/size, causing this error.
opw-2419296
closesodoo/odoo#64389
X-original-commit: 5e9e35ef0d7b0cdecc5c25dc4db04925ed0408a6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Let's make a bancontact payment with Stripe on mobile from the web shop
- Stripe redirects you to Odoo
- Your phone asks on which browser you wanted to redirected to Odoo
- Choose one
Bug:
An internal error was raised.
When you clicked on a browser (the same you were using or a new one, whatever)
Odoo will resend a request to Stripe. But this request will have wrong data in it.
Stripe will answer with:
Stripe: entering form_feedback with post data {'error': {'code': 'resource_missing',
'doc_url': 'https://stripe.com/docs/error-codes/resource-missing',
'message': "No such payment_intent: 'py_1I6c4UKhH8RhRq18TJs2CP0z'",
'param': 'intent',
'type': 'invalid_request_error'},
'reference': 'S00002-1'}
opw:2422031
closesodoo/odoo#64385
X-original-commit: a42075c9f913f4a20b28f97f0f6786f5a7b2968a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider a partner P linked to an employee E and a vehicle V
- Let's change the mobility card of E with 12345
Bug:
The mobility card on V was not changed.
opw:2431316
closesodoo/odoo#64343
X-original-commit: 81e574aae3059844179dd9f54a241cd51a2474fd
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previously, when double clicking and image, video, icon, or document in
the web-editor and replacing it with a different media type, it would
lose its custom classes. This means among other things, that it would
lose margins and paddings from bootstrap classes, or in the case of the
three columns snippet, that the new media would not be properly rounded
in its top corner, or not show up at all in the case of the video. The
only exception was when changing any media type to an icon, but in that
case it would also keep some of the media-specific classes that are
supposed to be removed (eg img-fluid or media_iframe_video).
This commit fixes that as well as some _clear behaviour that didn't
remove all classes that had to be removed, eg some fa-classes would
linger depending on their order, and the o_image class from documents
would always remain
Part of https://github.com/odoo/odoo/pull/64234
task-2282542
closesodoo/odoo#64234
X-original-commit: 99531f5dd8966fc4ad89d1e9c2886ad701527f3a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, changing a media from a video/icon/document to a different
type would leave empty elements in the DOM, this is because summernote's
range API `range.insertNode` function deletes the content but not the
structure (HTML elements).
This commit fixes that by using jQuery's replaceWith method instead of
summernote's insertNode when a media was found, and only using
summernote in case no media was found (eg. a text range).
Part of https://github.com/odoo/odoo/pull/64234
X-original-commit: 63f80995a05eeab1061b769c7733a1cfa98c726e
Clicking on save on html editor is taking quite some time. The user might think
something is not happening and need to click again.
If he does click again, 2 write RPC will be sent, making the COW business code
being triggered twice, ultimately leading to create 2 COW.
Instead of
A
/ \
B B'
It will be
A
/ | \
B B' B'
With as many B' than there is click on save.
This commit adds a generic helper to make a button load/spin.
closesodoo/odoo#64366
X-original-commit: 80592abda266ef3f9f463854c3101eb3f728087b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
STEPS:
* configure rounding:
- cash_rounding=True
- only_round_cash_method=True
- round method: 1.0 Down
* open a session
* add products with subtotal in decimals (such as 6.35)
* select Bank payment method and process the order
BEFORE: error "You have to round your payments lines"
AFTER: order is processed and marked as paid
---
https://github.com/odoo/odoo/commit/42425996e36d9cb1fc1391402cf6d00df4aea019
opw-2426027
closesodoo/odoo#64351
X-original-commit: db0b65e547defe3d49c1a31c4671f546aa5156e8
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The intent of the test was to count renders but it counted calls to `onUpdate`
which was the same "by luck", but the function was changed to be called more
often than renders to fix another bug.
Proper way to count renders (after the initial mount) is just to use `patched`.
closesodoo/odoo#64352
X-original-commit: c7375ebaf8d4baa6e02534425ed634c7264ce90f
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When sending several invoices, customers also receive those that do not
concern them.
To reproduce the error:
(Need mailcatcher)
1. Go to Invoicing
2. Select two invoices
- Status must be "Posted"
- Customers must be different
3. Action > Send & Print
4. Uncheck "Print", then click on "Send"
5. Repeat 2-4
Err: Each customer receives both invoices. (In some cases, a third mail
is event sent). Each customer must receive his own invoices.
The mail composer wasn't correctly configured.
OPW-2422117
closesodoo/odoo#64340
X-original-commit: 603752df5444f60ac7282758c7e6596940747889
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Free reservation is called each time an extra quantity is
used on a move (and for each immediate transfer). It means
that the function is called many times on a database with an
inventoy activity. Also _free_reservation method do a search
on fields that are not indexed, and is slow on large database.
This index is specific to _free_reservation.
On a live database with an important stock, the queries dropped from 265ms
to 1.5ms.
closesodoo/odoo#64327
X-original-commit: 74ea87d0a354b7414afb76d98ed39ecde45a8fb1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When running the scheduler, if one of the concerned product is a
kit, it will always generate a RfQ for the components, even if there
are already enough of them.
To reproduce the error:
(Need purchase)
1. Create 2 products P and P_compo
- Both must be storable products
- P_compo must have at least one vendor
2. Go on P-product page
3. Add a reordering rule (e.g., min: 5 and max: 10)
4. Add a BoM
- Must be a Kit
- Add P_compo to components
5. Inventory > Operations > Run Scheduler
6. Go to Purchase, find the generated RfQ
7. Confirm the order, Receive Products, Validate
8. Go on P-product's page
- As you can see, you have enough P-products on hand
9. Repeat steps 5-6
=> You should not find any RfQ since you already have enough P-products.
When checking the P-product's page, you can see the correct quantity on
hand because it uses the `_compute_quantities` method and this one has been
overridden in the mrp-module so a kit will be correctly computed.
However, when running the scheduler, it uses another method to get the
current quantities: `_compute_quantities_dict`. Since this method has
not been overridden in mrp-module, it will use the basic implementation
and this one does not consider the possibility for a product to be a
kit.
This fix creates an override of `_compute_quantities_dict` so it can
compute the correct quantities of products with 'phantom' as BoM type.
Moreover, for the code to be simpler and clearer, thix fix also merges
`_compute_quantities` and the new `_compute_quantities_dict`.
OPW-2421841
closesodoo/odoo#64326
X-original-commit: 609e2f4427082431b56aa8f999d74ed9d39db653
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps:
- Install accounting
- On the dashboard, try to upload an "encrypted" PDF like this one https://launchpadlibrarian.net/24827090/DS-0157.pdf
Bug:
Traceback:
PyPDF2.utils.PdfReadError: file has not been decrypted
Explanation:
In 13.0, these errors were caught in a catch all `except` as shown here: https://github.com/odoo/odoo/blob/4e089041252c25cc197a30f9e285d82f7162d809/addons/account_facturx/models/account_move.py#L303-L328
From this SO comment: https://stackoverflow.com/questions/52047944/pdfbox-extracting-blanks-from-pdf-encrypted-with-no-password#comment91054285_52047944
> A PDF can be encrypted with two passwords: a user password and an owner password. When a PDF is encrypted with a user password, you can't open the document in a PDF viewer without entering that password. When a PDF is encrypted with an owner password only, everyone can open a PDF without that password, but some restrictions may be in place.
From time to time, we get a PDF encrypted with an owner password. The
content is still readable, but PyPDF2 fails because it thinks the PDF is
encrypted. With this fix, we try to unwrap the PDF by providing an empty
user password. This way, PyPDF2 thinks the content is now decrypted.
However, PyPDF2 only supports decrypting versions 1 and 2 of the
encryption implementation. If the version is different, we skip reading
the attachments and carry on to allow the user to upload the document.
opw:2375993
closesodoo/odoo#64320
X-original-commit: 851fe64f7789bb398383c22e3ebbaebb051791f6
Signed-off-by: backspac <backspac@users.noreply.github.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Fine tuning of 78286851034b8f3ef4dcab78e50b7220c0bdd213
The link to view Cash Statements on the dashboard openned the wrong
action.
Also in some cases, removing the context key `search_default_journal`
was not enough so we set it to `False` instead.
closes#64118closesodoo/odoo#64279
X-original-commit: 95ffa9fd122eae82d12d40db3cb7364cf3d3c919
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Steps to reproduce the bug:
An account with the type "Credit Card" can not be chosen for the
creation
of a journal with the type "Bank" as the domain for bank account filter
only for accounts with the type "Bank and Cash"
As the filter on the `user_type_id` is too restrictive we remove it in
case the journal is bank or cash
Bug:
Impossible to select the correct account.
opw-2394959
closesodoo/odoo#64288
X-original-commit: f4e67d8ae174d7e2ee75a1de1083b31a6ff2af8b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before that, write-offs were simply never created in this case ; only an open balance. This was (obviously) wrong.
Also, the partner set on the statement line was not modified, and kept empty. We fix that so that, when a statement line without is reconciled with lines sharing the same partner, this partner is also assigned to the statement line.
Task 2423231
closesodoo/odoo#64253
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create an invoice for 100
- Create a bank statement for 95
- Setup your reconciliation model so that it will match them and create a write-off for the remaining 5. Make it auto_reconciled.
=> Doing that, we expect the bank journal move to be created like this:
- 100 on payable/receivable, reconciled with the invoice
- 95 on the bank account
- 5 on the write-off account
This wasn't the case. Instead, Odoo created the following (correct from an accounting point of view, but weird):
- 95 on payable/receivable, reconciled with the invoice
- 5 on payable/receivable, not reconciled
- 95 on the bank account
- 5 on the write-off account
=> So an open balance of 5 was actually created. This was weird, and also caused an additional bug, as only the first payable/receivable line was reconciled with the invoice, making it only partially paid.
This commit restores the expected behavior.
Issue
- add a new language with locale code KUR (for Kurdish)
- print any report with a datetime on it (RFQ for example)
Cause
Babel (version < 2.7.0) does not handle locale "KUR".
Solution
If wrong locale or not managed by Babel, try to fallback
on server default locale.
If still wrong locale or not managed, then fallback on "en_US" as locale.
opw-2416482
closesodoo/odoo#64304
X-original-commit: e6ccdb397792db62c3b08d96435b3c1667c1aa9d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps:
- Install eCommerce
- Go to "Website" > "Go to Website"
- Click Edit
- Add the Dynamic Products block with a template and a category
- Save
- Switch to mobile view
Bug:
The right arrow of the block overflows and makes it possible to scroll
the entire view sideways.
Explanation:
This commit puts back prev and next arrows onto the carousel. It also
changes their design to be more visible over the content. The arrows are
now smaller and displayed in clickable gray circles.
opw:2415187
closesodoo/odoo#64274
X-original-commit: a5d7a1a6f3cf82610802ad84a9ae1baaa3f58e15
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
In the context of bug #43365, the fix merged in #48031 introduced an
override of `ir.translation._load_module_terms()`, which calls `super()`
then does some extra stuff.
This was forward-ported to later versions, unfortunately the
forward-ports missed the fact that the method signature changed at some
point (circa saas-13.2) and the `overwrite` flag which used to be passed
in the `context` had become an explicit method argument.
As a result, that argument is lost in the `super()` call and the
`website` module entirely disables the "overwrite" mode for the
translation loading wizard.
The fwd-port that seems to introduce the issue is odoo/odoo#50477 (998987f8ee148235f4025eb97a424e838ac6fc9f)
closesodoo/odoo#64251
X-original-commit: 26355a6bf83a194c2e398e859e49920da1f415b8
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Some of the feature of the "My Activities" list view of the crm app were not
available on the regular crm tree view.
This commit aligns the 2 views by sharing these features, notably:
- You can "snooze" your next activity if there is one
- You can contact the lead by email with a direct button on the row/list header
- You can contact the lead by sms with a direct button on the row/list header
The "team_id" column is now optional="hide" since not required most of the time
when you go to check your own leads (and can be activated in a few clicks if
needed).
Finally, the "Email" action at the end of the tree row is now in "single" mode
to allow adding contacts on the fly. This implied re-introducing an action that
was recently removed in 8c65d7c5f7
Further demonstrating that R&D is just an eternal loop.
UPG PR odoo/upgrade#2064
Task-2390500
closesodoo/odoo#62289
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This takes a former patch one step further.
Assume you recompute a field on two records, and the computation assigns
the first record but not the second one. Before this patch, the
recomputation process was accessing the field on both records. When
accessing the first record, both records are recomputed, and the value
of the first one is found in cache. When accessing the second record,
no recomputation is made (it has been done already), and the cache is
empty. The field is thus fetched from database, and this crashes because
of insufficient access rights.
This scenario was causing some obscure nondeterministic crashes in
tests. The nondeterminism comes from the choice of the environment for
flushing (it should not be in superuser mode); the order of records in
the set to compute; the order in which records are assigned in the
compute method; the fact that the compute method should assign some
records and some not.
The fix consists in adding a method that processes pending computations,
without doing anything special for unassigned records. The method is
used in field accessors (__get__ and mapped) and in method recompute().
The access error is gone because the recomputation no longer tries to
get the value of a field to compute.
closesodoo/odoo#64264
X-original-commit: b7676ec33172e6196b5fd1eda4df730ebf90eb6b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps:
- Install Invoicing and load French
- Go to Invoicing
- Click an invoice due in the future
- Click Preview
- Switch the preview to French by modifying the URL like this: example.com/my/invoices/6 -> example.com/fr_FR/my/invoices/6
Bug:
"Due in %d days" is still displayed in English. The rest of the page is in French.
Explanation:
This is due to two things:
1. `mail` and `portal` are both installed and we cannot have more than one `code` translation of a source [1]. Since `mail` is loaded before, alphabetically, `portal` doesn't add the duplicated translations with its own module name. When loading a web page, only the modules returned by `_get_translation_frontend_modules_domain()` are sent to the frontend. `mail` is not one of them and the duplicated translations are not sent. Since sending all the `mail` translations is overkill, this commit is modifying the format string. This won't change the text outcome, but will make the new sources unique and make the backend send these translations to the frontend.
2. Translations in `portal_sidebar.js` are queried before the translation DB [2] is made. This results in an empty array and `_t()` returns the source. `session.is_bound` will wait until the app is fully loaded before querying.
[1] https://github.com/odoo/odoo/blob/ad2d96db8ad3e1fd7af2edda218fc34c0c1d259a/odoo/addons/base/models/ir_translation.py#L290
[2] https://github.com/odoo/odoo/blob/0de069b8ca9fb005ba5b076984f5677de25889ee/addons/web/static/src/js/core/translation.js#L51
opw:2421501
closesodoo/odoo#64263
X-original-commit: 118d79192cf0fc923a121745c78e6dd0da563df0
Signed-off-by: backspac <backspac@users.noreply.github.com>
Create two differnt journals for two different bank accounts (A, B).
Create an Internal Transfer in bank A to send money, then reconcile.
Create an Internal Transfer in bank B to receive money, then try to
reconcile
Internal transfers are labeled 'Customer Reimbursement' and 'Customer
Payment' even if no external partner is involved in the process,
opw-2423161
closesodoo/odoo#64258
X-original-commit: 4fcacfac8967a3facbe751f748faff02033ce0ae
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Ivan Yelizariev