*account,hr_expense,purchase,repair,sale,spreadsheet_dashboard_*,web
In Chile, "Untaxed Amount" has its own special term that isn't used in
Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [Chilean customer
changed what term should be once fw-port was at v17]. Therefore
everywhere that it appears (in a .pot file), we ensure that the es_CL
localization uses this term.
Also untranslated terms from the es_CL.po files that were edited have
been removed since they add no benefit and make it harder to read the
file (we expect to only add terms to the file, not translate every
term for Chile).
opw-3670297
closesodoo/odoo#154473
X-original-commit: d1d4d30ef402ce835cba892459fdceadfc9944e1
Related: odoo/enterprise#56853
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Move compute of `imStatusTrackedPersonas` to its inverse field. Doing
the compute on the "One" side of the relation prevents from looping and
computing all values whenever there is a change in any of them.
In practice, this reduces the "compute" time of the message fetch (which
also fetch persona as authors of messages), reducing by approximately
half the time it takes to insert these messages (depending on the number
of persona it had to loop through).
For example from 60ms to 30ms on my machine for message insert in
"partner_1_125" (populate medium).
closesodoo/odoo#154918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In commit[1] an improvement was made to increase the scrollbar height
on hover to make it easier to scroll. However chromium updated the way
::webkit-scrollbar works breaking the behavior on recent browser. On
firefox the margin was applied without the change of height on the
scrollbar creating a visual glitch on hover.
On chromium >121 the `scrollbar` property takes priority over the
`::webkit`-x to keep the scrollbar styling with height change on webkit
browser we have to apply the `scrollbar` property only on Firefox.
The mixin was used only on `website_sale` filter offcanvas and category
horizontal scrollbar, this commit removes the mixin and customization on
the offcanvas vertical scroll to make it consistent with the other
offcanvas across website.
This commit also disables the scrollbar hover effect on touchscreens.
The transform was causing an issue on some devices displaying the
scrollbar behind the items, thus it's now applied on the container.
Note: We use not `.o_wsale_filmstip_fancy_disabled` to avoid the
`scrollbar` property being set when the Javascript is not loaded yet.
Otherwise the scrollbar would be invisible until a hover from the user.
[1]: odoo/odoo@bdede43e1e
task-3718501
closesodoo/odoo#152456
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
When checking a partner's validity on Peppol network, we should always check the `commercial_partner_id` to get the right eas & endpoint. Also, the Peppol verification check should not occur if the current company does not have an active peppol registration.
Currently, if a user wants to send an invoice to a specific contact of a partner, they cannot as `_need_ubl_cii_xml` evaluates to False because the contact is not a valid Peppol participant.
opw-3748720
closesodoo/odoo#152654closesodoo/odoo#154823
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Peppol endpoint must not contain special characters. This commit adds
an onchange, where the input is being sanitized.
If the endpoint is not filled in, we already throw an error when
creating an edi user, so that should be fine.
task-3718573
Part-of: odoo/odoo#154823
Turn your odoo user's language to "French (BE) / Français (BE)".
Now, let's say you have a pivot function returning an amount in the one million
(e.g. 1 230 000). It's formatted to "1.230.000,00"
Reference that cell with `FORMAT.LARGE.NUMBER`. The result is "1.230k"
Now hit the share button and open the share link in an incognito tab.
=> the cell is now "123m"
That's because the string "1.230.000,00" is wrongly parsed to 123000000
(to fix in o-spreadsheet).
Besides that, the formatted value may not necessarily be parsable.
With this commit, we export the raw value, stringified.
opw 3720586
closesodoo/odoo#154712
X-original-commit: 7f8d705b216b392ce1249793a0b44dcec0ac536c
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, calling _applyCommands with a lot of commands
DELETE or UNLINK on a StaticList already containing a lot of
commands was very slow. This happened for instance in the Automated
Rule form view, click on "Add an action", and in the dialog form
view, select a "mail" type, e.g. "Add followers". In that form view
there's a many2many field "available_model_ids" which contains at
first almost all models of the database (LINK commands). Switching
to a "mail" model restricts those models to the ones inheriting
from the thread mixin, i.e. it generates a lot of UNLINK commands.
On runbot, in represents 1000+ LINK and UNLINK commands. This
could take several seconds.
With this commit, we no longer iterate over all commands when
applying UPDATE, DELETE or UNLINK commands. Instead, we generate
at first a mapping of record ids to their own commands, and we
then have a quick access, given a record id, to the list of his
commands, which is small in comparison to the whole list of
commands. After iterating over all commands, we generate the new
list of commands and we update this.records and this._currentIds
to do the necessary cleanups (i.e. removing records and ids for
which we received DELETE/UNLINK commands).
task 3599674
closesodoo/odoo#154568
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Steps to Reproduce
- Install E-Commerce app
- Add Demo payment provider in Test mode
- Go to Settings > Website > Invoicing and activate Automatic Invoice
- Go to Settings > Website and set the domain for:
- My Website -we'll refer to it as website_1- as http://[IP_address]:[port] such as http://127.0.0.1:8069
- My Website 2 -we'll refer to it as website_2- as http://[IP_address]:[port] such as http://127.0.0.2:8069
- Create a new product with Invoicing Policy as Ordered quantities
- Go to website_2 and add the new product to the cart and checkout
- With Debug mode on, Check the Emails sent via Settings > Technical > Email > Emails
Current Behavior
Two emails are automatically sent:
- An SO email that opens website_2 when clicking on View Sales Order button which is correct as we purchased the product through website_2
- An Invoice email that opens website_1 when clicking one View Invoice button which is WRONG as it should follow its originating SO and opens website_2 as well
Expected Behavior
Both SO and invoice emails should refer to the website where the SO was created -website_2 in our use case-
Observations
The automatic invoice always refer to website_1 regardless of the website where the SO was originally created.
Investigation
The website_id of the invoice is decided by the corresponding field https://github.com/odoo/odoo/blob/322889ea0a24c5eff2e3289502a2f606cb4048d0/addons/website_sale/models/account_move.py#L10-L13
- As noticed it's a related field to the partner_id.website_id which is False
- That's why the invoice website_id is also False leading to the preview button to fall back to website_1
- The partner_id.website_id is always False unless you manually added the field to the view and then set the website_id. Our case will work correctly if you set the website_id for the user/customer to website_2
- I also tried to sign up at website_2 to see if the website_id will be set accordingly but it stayed as False
Proposed Solution
make the invoice website_id relates to the originating SO instead of the partner
opw-3685742
closesodoo/odoo#154376
X-original-commit: 361e8f68af9c9656764906c8a44d22e1fed090a8
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
ZATCA changed the demo VAT code used with Sandbox, this commit aims to update the demo data in the l10n_sa_edi module
closesodoo/odoo#154309
X-original-commit: 54628c497322b9afb506d9d2437cce90c3262b08
Signed-off-by: Josse Colpaert <jco@odoo.com>
When installing a new module, the access of the Default Template User
is propagated to any existing employee (introduced at
aefb05eb497a8a16a). This can be problematic in companies that don't
want all their employees to become manager by default. Allow to
disable this behaviour in a settings.
This is the version of the patch targetting stable version that is not
configurable through the interface, manually creating an ICP
base_setup.default_user_rights_minimal=True as the way to change the
behaviour.
Closesodoo/odoo#149224
Task-id 3685856
closesodoo/odoo#154816
X-original-commit: 70f66f147bb0c133be6ae3fd2b11438afe2366a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Issue:
=====
When you undo a column command, you won't be able to write on that line
anymore.
Steps to reproduce the issue:
=============================
- Go knowledge
- Use column command to add columns
- Do ctrl+z
- Try to write anything
Origin of the issue:
====================
When we apply a columns operations , it will use the current block and
insert it under the first column so the `ouid` of the block will change
to the `oid` of the div (the column) so will will have 2 mutations : one
to remove the block from the root and one to add the block under the
column.
Reverting history will do the operations in reverse order, so it will
remove the block from under the column and the add it under the root but
the `block.ouid` is already set to `oid` of the column which is
different from the actual `ouid` which is `root` so adding any text to
the block will first add a textnode with `getOuid(node,true) =
block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will
mark `this._toRollBack` as true and the operation is rolled back that's
why we can't add anything anymore.
Soltuion:
=========
Mark the `ouid` of the removed elements as undefined so when we insert
them again we can recalculate it correctly.
task-3693076
closesodoo/odoo#154815
X-original-commit: 16163f135d4fc215361dddf2f4520d08a3b0ac1c
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
=====
The stock move date is the scheduled date of the production and not the
date the production is done.
Steps to reproduce the issue:
=============================
- Create a manufacturing order with any product (large desk)
- Assign a date in the past for scheduled date (5 days before)
- Confirm the order.
- Added quantity produced and mark as done
- Go to traceability , you will see the date here is the scheduled date
and not the production date.
- You can see also the inventory at date in
inventory/reporting/locations will have the product they after the
scheduled date.
Solution:
=========
Use the value of `date_finished` if it's set when calculating the `date`
for `move_finished_ids`
opw-3640708
closesodoo/odoo#154811
X-original-commit: ac94a429ed5ab0ffe7ac8fbc55243adaed3ce60f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Use read_group with groupby=['id'] raise a Exception:
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 2386, in _read_group_format_result
m2x_records = self.env[field.comodel_name].browse(ids).union()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 521, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/Documents/dev/odoo/odoo/modules/registry.py", line 190, in __getitem__
return self.models[model_name]
KeyError: None
```
Even if it doesn't make lot of sense to do that (mostly equivalent to
search), it is preferable to manage the case correctly.
closesodoo/odoo#154799
X-original-commit: 75a259365989d469972c0616dba22a56bf218bb5
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
With this commit, list data is loaded using `web_search_read`
instead of `search_read`.
The goal is to fetch the currency (symbol, decimal places, etc.) of monetary
fields in a single request, instead of 2 RPCs.
Pros:
- less code
- one evaluation saved
- one network request saved
- easier future refactoring (see below)
Cons:
- overhead of data transferred over network (from 4.5MB to 6.5MB, unzipped
and from 711kB to 725kB gzipped to fetch a list of 20K crm leads).
Before this commit, here is what it looked like:
1. the list data is fetch (with the currency_field)
2. the cells are evaluated with the new data
3. we realize we want to format a currency amount. We already have the
currency name but not the symbol, etc. So we fetch the currency data
4. evaluate the cells again with the new currency format
Now:
1. fetch the list data with everything we need for the currency
2. evaluate the cells
This commit also serves another goal for a future refactoring: in the hope
of avoiding throwing "loading errors", I'd like to have an easy way to know
if a data source is fully loaded or not (the data and the format).
With this commit, everything is centralized in the list data source with
a single RPC. The goal is therefore achieved with this commit.
closesodoo/odoo#153434
Task: 3730232
Related: odoo/enterprise#56253
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This commit resolves a bug related to zero-width spaces within the inner
content of a link. The bug led to a systematic test failure in 17.0
link_tools when comparing the input value with the expected value.
The bug originated from [1] that manipulates zero-width spaces to allow
users to select the edges of the link.
Steps to reproduce:
- Navigate to the Project app and open a random task (create one if none
exists).
- Select the "Description" tab.
- Enter "/link" and press "Enter" to activate the link tools dialog box.
- In the link label field, input "The Website".
- In the URL or email field, input "localhost:8069".
- Save the changes.
- A new div is generated with the class "note-editable".
- Click on the newly created link.
- Edit the link by clicking on the edit icon in the popover.
- Direct the focus to the link label field at the end of the string "The
Website".
- Press the "Backspace" key — observe that nothing happens.
This fix is actually a complement to [2].
The test added in [3] eliminates zero-width-spaces prior to asserting
the equality of values. This was appropriately addresses and handled in
this commit.
In version 16.2 [4], they refactored and improved the handling of
zero-width spaces (ZWS). As a result, ZWS in the link are now escaped
when the selection is made, eliminating the need to filter out these
empty characters. So, I added two assertions that provide more
comprehensive test coverage. The previous test only accounted for one
way to open the LinkDialog: selecting a part of the link and clicking on
the toolbox icon. Another method is to simply click on the link. In this
case, a popover appears, allowing link editing via the edit-link icon.
In the latter case, the test fails without the fix.
In version 16.4, the link component was migrated to OWL. So the bug
isn't there anymore. The new test is kept. Note that after this commit's
merge in 16.4, it was patched with [5]. This forward-ported version
includes the patch directly.
[1]: https://github.com/odoo/odoo/commit/99bc9b115dbdfc29260b4ccdb55ffa2ed16dffb3
[2]: https://github.com/odoo/odoo/commit/71feab51f41f0658f4ad61f99386c9c6978c6025
[3]: https://github.com/odoo/odoo/commit/a56586119845969e9d867a220f5330a6c7daa5c2
[4]: https://github.com/odoo/odoo/commit/89b0ce0c74458342fea5e1b093e9383f82e2440f
[5]: https://github.com/odoo/odoo/pull/154644
runbot-44779
closesodoo/odoo#154474
X-original-commit: 9db065e75d7b31febe4a42138308b47d0fa46508
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Rodolpho Lima <rcdl@odoo.com>
Steps to reproduce issue:
1. Create Draft invoice with no Invoice Date
2. Set payment terms with multiple due dates (e.g.: "30% Now, Balance 60 Days)
3. Make sure "Show installment dates" is ticked in the payment terms form
4. Print invoice
5. Receive traceback with main message:
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> ValueError: The value send to monetary field is not a number.
> Template: account.report_invoice_document
> Path: /t/t/div[2]/div/div[3]/div[2]/t/div/div/t[1]/td/span[1]
> Node: <span t-options="{"widget": "monetary", "display_currency": o.currency_id}" t-out="o.invoice_payment_term_id._get_amount_due_after_discount(o.amount_total, o.amount_tax)"/>
Explanation:
`_is_eligible_for_early_payment_discount` will normally return `True` only if every condition is fulfilled. In previous fix odoo@9b20af823d3d2d8c3c70fd016d71448caa039958, we bypassed all of them if `reference_date` had no value.
https://github.com/odoo/odoo/blob/4b744c82c3f902448a5c89c4711eccfeb1b548b8/addons/account/models/account_move.py#L1910-L1918
The method is called here, leading to the field that triggers the traceback.
https://github.com/odoo/odoo/blob/8f3c0b218eb9ea725995d716e97999556ce74578/addons/account/views/report_invoice.xml#L230-L236
The reason it only blocks with multiple due dates is because of the first line: `payment_term_details` is true when there are multiple due dates or an early discount, the latter being the concern of the previous fix.
The second one is true if "Show installment dates" is ticked.
Suggested fix:
`reference_date` should not take priority. Therefore, we will only override its own condition when it has no value.
opw-3726968
closesodoo/odoo#154736
X-original-commit: 16cdd4226de5f731a80599df0599d6d7cbcd2186
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Consider models A and B such that B inherits from A (with _inherits),
and a form view of A with a one2many field that inverses the many2one
"delegate" field from B to A. When adding a new record in the one2many,
onchange() crashes while trying to update the cache of an empty parent
record.
The situation is caused by how onchange() initializes the new record of
model B, and the fact that the form provides a value for the delegate
field. The new record is actually initialized with an empty value for
the delegate field, which causes the code to crash. The fix simply
consists in updating the parent record only if is nonempty.
opw-3744514
closesodoo/odoo#154735
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Since 17.0, the `Cancel` button in the `mail_activity_schedule_view_form` uses the hotkey `z`, which conflicts with the other button.
Change the hotkey into `x`.
closesodoo/odoo#154727
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When HR refuses applicants in batch and sends mails,
the mails are removed, because auto_delete_keep_log
is set to false.
It gives to HR wrong understanding that mails have
not been send.
Expected behavior;
Don't remove refused mails, when sent in batch
closesodoo/odoo#154720
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Reproduction:
1. In project -> task, create a new task
2. In the description, make a table of 1 row 2 columns, type two line
long string in the second cell
3. Create a row above, type anything short, save
4. Add the portal user as follower, e.g. search user joel
5. In an incognito tab log in with portal portal, check the task and the
table is out of the field
Fix: we should not fix the columns' width when create a new head row in
the table, for extra long table, it should be scrollable
task-3559104
closesodoo/odoo#154715
X-original-commit: 997b2f2817efe06ea37e5aca278507e0ef878635
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
closesodoo/odoo#154679
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
Part-of: odoo/odoo#154679
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
Part-of: odoo/odoo#154679
See parent commit for more details. This commit disables the remaining
problematic step in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
runbot-57204
X-original-commit: 60b2b182473beaa4e338d8345f8aa4a5984336dd
Part-of: odoo/odoo#154679
The test `test_15_website_link_tools` associated with the 'link_tools'
tour has been problematic for a long time. Many fixes have been made
already, mainly [1] but also [2], etc.
As of today, the test now succeeds 100% of the time in 16.2 and below.
Starting from 16.3, the tests still contains race conditions. As a first
step towards fixing those, we will first disable the problematic steps
so that we can re-enable the test on runbot. First, this commit is about
unifying the 16.3 version of the tour with the previous versions (16.2).
Indeed, while the test currently tests the same things as 16.2, for no
apparent reason (see [3] and others):
- Some phases of the test were reordered during the forward-port that
introduced them.
- A new "Popover should be shown" step was added during some
forward-port (it is actually one that is the cause of a race
condition, see below).
- 16.4 and above: many new steps which save/re-enter edit mode were
added, random clicks were added, trigger were changed, check were
rewritten for no reason, etc... none changed the race condition rate
(if anything, it worsened in 16.4, see below).
- 17.0 above: some useful steps were added and do not seem to impact the
success rate, this commit of course keeps them.
This commit thus:
- Reorders the steps the same way as 16.2.
- Temporarily disables the problematic new step.
- Removes all those useless changes.
Here are some tests made in all those versions (before this commit):
=> 16.2 and below:
- Tested: 100% working
=> 16.3:
- Tested: 162
- Failed: 88
- 57 on "Check popover content is up-to-date"
- 31 on "Popover should be shown"
=> 16.4:
- Tested: 30
- Failed: 28
- 24 on "Check popover content is up-to-date"
- 4 on "Popover should be shown"
=> 17.0:
- Tested: 80
- Failed: 80
- 69 on "Check popover content is up-to-date"
- 10 on "Popover should be shown"
- 1 on "Check that links's href was updated"
=> 17.1:
- Tested: 83
- Failed: 83
- 64 on "Check popover content is up-to-date"
- 17 on "Popover should be shown"
- 2 on "Check that links's href was updated"
=> master:
- Tested: 37
- Failed: 37
- 26 on "Check popover content is up-to-date"
- 11 on "Popover should be shown"
Note that this commit actually seems to reduce the race conditions...
which is of course not a solution on its own. The next commit will
disable the problematic steps to have the test pass 100% of the time,
until a real solution is found.
=> Tests with this commit:
- Tested: 11
- Failed: 4
- 4 on "Check popover content is up-to-date"
[1]: https://github.com/odoo/odoo/commit/da9afc46e32111afbe0f4bdae6d539795239290a
[2]: https://github.com/odoo/odoo/commit/06f9a21c60b4bf7d375bdaba3fd4c8bc89d16b54
[3]: https://github.com/odoo/odoo/commit/9fc283b514d420fdfd66123845d9ec3563572692
runbot-57204
X-original-commit: 155bfd45b0678d69ed34d4e832df5a331a91a551
Part-of: odoo/odoo#154679
Restore the "Cancel" button when selecting a plan from the activity wizard.
When we introduced the plan feature in v17, the "Cancel" button was forgotten. The only way for users to cancel the action is to click on the "X" button at the top right.
task-3754897
closesodoo/odoo#154678
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Improve the wording of the argument descriptions for the functions
`ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and
`ODOO.FISCALYEAR.END`.
closesodoo/odoo#154668
Task: 3680374
X-original-commit: bd5ddaca16f6ced709d3aa3af72829b1d443d4bb
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Adrien Minne (adrm) <adrm@odoo.com>
Steps to produce:
- Configure Outlook Calendar and navigate to the calendar app.
- Click on the Outlook sync button, redirecting to the general settings.
Before this commit, the Outlook sync pause buttons directed users to the general
settings.
with this commit, it now redirects to the calendar settings.
task-3731652
closesodoo/odoo#153581
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Steps to produce:
- Configure Google Calendar and navigate to the calendar app.
- Click on the Google sync button, redirecting to the general settings.
Before this commit, the Google sync pause buttons directed users to the general
settings.
with this commit, it now redirects to the calendar settings.
task-3731652
Part-of: odoo/odoo#153581
Remove `No documents to display` as there will always be aa least
the addresses and security/connection cards.
closesodoo/odoo#146197
Task-id: 3629038
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
"Mandatory" days use a random text color and they don't render well with
the colored background colors of `.fc-today` and hovered days.
The text-color has been removed on hovered mandatory days and
mandatory days happening "today".
The background of "fc-today" now uses the color of mandatory days when
that day is mandatory.
The SCSS has been cleaned up so as to not create repetitions.
task-3617334
part of task-3575827
closesodoo/odoo#144236
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When a payment method was updated in a way that prevented creating
tokens with it, that is, by either disabling it, unchecking the
"Tokenization Supported" field, or unlinking it from providers, only the
latter would automatically archive the related tokens after showing a
warning to the user. The two first actions prevented the creation of
future tokens with that payment method, but existing tokens could still
be used.
This commit fixes that behavior by adding the warning and the automatic
archiving of related tokens where they were missing. Preventing further
tokenization with a payment method now consistently blocks payments
through existing tokens, too.
closesodoo/odoo#150120
Related: odoo/enterprise#54700
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
The keyword arguments of the callees were never forwarded to the
`payment.method::_get_compatible_payment_methods` method, preventing
overriding modules from controlling which payment method should be
available depending on the kwargs.
task-3640488
Part-of: odoo/odoo#150120
Issue:
- when an order is created through the kiosk, the order appears several
times on the cashiers side.
Steps to Reproduce:
- Make an order in the POS kiosk.
- In the backend, navigate to the kiosk's session and select
"Continue Selling."
- Click on "Orders" located on the top right.
- Observe that the order appears multiple times on the cashier's side.
Solution:
- added _get_shared_orders that retrieve orders without duplicates.
opw-3597973
closesodoo/odoo#149049
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Testing quantities and availablility states in subcontracted BoM report
1. Create a BoM of a finished product with a single component
2. Update the on hand quantity of BoM to 100
3. Move 20 components to subcontracting location
4. Check that the free/on-hand quantity of component is 100 (sum of warehouse stock and subcontracting location stock)
5. Check that producible quantity of 'Product' is equal to only subcontractor location stock
6. Check availability states when:
6a. Search quantity <= subcontractor quantity: component is available
6b. Subcontractor quantity <= search quantity <= total quantity: component is available
6c. Total quantity < search quantity: component is unavailable
task-3632211
closesodoo/odoo#145889
Signed-off-by: Steve Van Essche <svs@odoo.com>
The free to produce quantity was calculated based on the available stock in the warehouse in addition to the subcontracting location. For this reason, `free_to_manufacture_qty` variable was introduced. If it is a non-subcontracting BoM, it will be equal to the free quantity available in warehouse stock. Otherwise, it will contain only the stock in the subcontracting location.
task-3632211
Part-of: odoo/odoo#145889
When `_update_product_info` and `_get_components_closest_forecasted` were called on bom lines or child components, the functions were called with a parent product equal to the parent of the current product, whereas it should be called with the current product itself as we are calling functions recursively in a DFS-like pattern.
task-3632211
Part-of: odoo/odoo#145889
In BoM overview report, the free quantity and the on hand quantity only reflected the available stock in subcontracting location. After this commit, selected warehouse stock is also included in the calculation.
task-3632211
Part-of: odoo/odoo#145889
If user created pricelist which applied discount on fixed prize delivery
and set the discount visibilty to be shown in sale order, the discount
would be applied twice. Due to stable version limitation, the visibility
of discount on sale order for pricelist discount for delivery is removed.
opw-3517879
closesodoo/odoo#154663
X-original-commit: f96ce5102aea5651710bb5bf50903b1c1d4f101e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
In cases where the cursor is at the end of the current block and the next block
begins with a zero-width space, the mechanism that skips these characters while
using arrow keys should not traverse all the way to the end of the zero-width
space in the next block. Because this mechanism operates before the browser
applies its own behavior for arrow keys, potentially causing the cursor to jump
to the start of the third block when second block only contains a zero-width
space, completely bypassing the second block. Conversely true for the arrow left
keys.
This commit ensures that the navigation does not extend beyond the current block
when searching for a `newFocusNode` when moving with arrow keys near zero-width
space.
task-3653307
closesodoo/odoo#154676
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
- Install Accounting and Purchase
- Create a PO with Purchase Representative different from current user
(e.g. Marc Demo)
1) - Mark the product as received
- Create a bill from PO
2) - Go to Accounting
- Create a bill
- Select the PO in Auto-Complete field
- Save the bill
Issue:
The Purchase Representative of the PO is set as Salesperson (hidden field) of the bill.
He should not.
In the second case, by adding the purchase representative as Salesperson of the bill,
he is also added as a follower of the bill and he receives a notification about being
assigned to the bill.
opw-3677713
closesodoo/odoo#154669
X-original-commit: 07cf6c0e320cd719ea5b6531c2c84f55d8627722
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
When a tax is set to inactive, the fiscal positions mapping other taxes to it continued to apply, disregarding the fact that it shouldn't be used anymore. Not anymore with this fix.
closesodoo/odoo#154646
X-original-commit: 07fa1b880875fc075555ca65f4ddd0cddb619979
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Go to Documents activity view.
- Click on Schedule activity.
- Perform multiple clicks on any record.
Issue:
The 'Schedule Activity' wizard opened as many times as the record was clicked.
As a result, even after successfully scheduling an activity on that record,
the user still faced multiple open wizards remaining and had to manually close
each one of them.
Fix:
This commit introduces a method `executeOnceAndClose` which makes use of a
flag 'busy' to ensure that the `onSelected` function is called only once and
hence exactly one `Schedule Activity` wizard is opened, despite clicking a record
more than once.
closesodoo/odoo#154442
Task: 3721404
X-original-commit: 19cc5ea3cf2c8fcf742ba5ab9b4b82305d81d555
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open Settings/Gamification Tools/Challenges
- Create a new challenge
- Keep "Assign Challenge to" with default values
- Need a domain that return some user
- Create and Edit a goal
- Computation Mode: "Automatic: sum on a field"
- Save & Close
- In reward Tab set "For Every Succeeding User"
- Save
- Start Challenge
Actual result:
- Traceback due to wrong aggregate value
- CHallenge is not started
Expected result:
- Challenge is started
opw-3740960
odoo/odoo@234db70dclosesodoo/odoo#154614
X-original-commit: aa0f617682a59c5ac285308000f35d44b75f04df
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Previously, an issue was observed where the dropdown menu of the
spreadsheet's share button displayed a scroll bar when users had
selected a different language, such as French (BE).
This commit addresses the problem by setting the height of the dropdown
menu to auto, thereby resolving the issue of unnecessary scroll bar.
Task ID: 3742260
closesodoo/odoo#154561
X-original-commit: a3b56d25357ed7e7cadbf5f955440b2c2c4d7a35
Signed-off-by: Adrien Minne (adrm) <adrm@odoo.com>
Current behavior:
Creating an SO with negative quantities for a storable product with an
invoicing policy of type "delivered quantities" automatically generates
a return move for the stocks. However, when this delivery is validated,
the delivered quantities are not updated on the SO. This is problematic
as these quantities are therefore not taken into account on the
associated invoice.
Expected behavior:
The delivered quantities should be updated negatively on the SO to
enable the invoicing of these lines.
This is already the behavior in the POS application and when you
create an SO with positive quantities followed by a return
for a larger quantity than the one delivered.
Steps to reproduce:
Create a storable product with an invoicing policy of type "delivered
quantities".
Create an SO with 2 lines:
- a line with positive quantities for any other product.
- a line with negative quantities for the product you created.
Confirm and validate the corresponding deliveries.
Return to the SO. The quantities for the second line are not updated.
Create an invoice. The second line is not taken into account.
Cause of the issue:
The to_refund field of the stock.move model defined in the stock_account
module enables a decrease of the delivered quantities in the associated
Sale Order. This field is set to True for "classic" returns but not for
the stock.move generated from sale.order.line with negative quantities.
Fix:
We rely on the _get_custom_move_fields method to add the to_refund
field in the procurement 'values' arguments in case the stock_account
module is not installed. It is then available to use in the
_get_stock_move_values method where we set its value to True if the
quantity is negative (so that the move should be considered as a refund)
opw-3676045
closesodoo/odoo#154496
X-original-commit: 92917d507a63ee08fc839ed3f7607d5e5060f0a2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Tiffany Chang (tic)