Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.
Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
* For warning, select either warning or blocking message
* Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product
Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.
The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.
This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.
Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).
Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99
* We're also sending the warning only if there is one because of this:
```python
<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
You can't edit this product in the catalog.
</span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.
Since the module purchase also uses the warning on products, this fix is extended to include it.
opw-3631511
closesodoo/odoo#149155
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
-------------------
- create an accrual plan;
- create an accrual level;
- save;
- create a second accrual level;
- save the form;
Issue:
------
We trigger an error with an invalid `added_value_type` field.
Cause:
------
The `added_value_type` is a compute stored field without inverse.
As it is not inversible, this field will be readonly by default [^1].
When the dialog window is opened, we trigger a specific logic
which will trigger an onchange [^2].
During this onchange, we work with a virtual record from the `hr.leave.accrual.level`
model (the one corresponding to the first level) which has an origin.
Unfortunately, we are using the cached value for the virtual record, i.e. `None`.
The latter will have been set as if it is a record without origin.
As the `added_value_type` field is readonly on the dialog form view,
we have to save the record with this value.
Since this field is required, the error occurs.
Solution:
---------
In order to use the value on the original record,
the field must be forced with `readonly=False`.
Note:
-----
Commit which introduced the issue: 0a9e83dfd8
The fix allows you not to use `_origin`
(which normally shouldn't be used in this case).
[^1]: https://github.com/odoo/odoo/blob/e89ed59269974f148c2285446dcd60e871df1a01/odoo/fields.py#L451
[^2]: https://github.com/odoo/odoo/blob/25cda065dccaae5edd861114c29157c7abb68533/addons/web/static/src/model/relational_model/static_list.js#L194-L299
opw-3745463
closesodoo/odoo#155033
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
-Move menu options to have 'Close session' and 'Backend' at the bottom of the list
task id: 3759943
closesodoo/odoo#154998
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
- In this commit, we make some requests in js to get a list of HSN codes to
match with the input entered by the user in the field.
- And for the options attribute in hsn_autocomplete widget, when a user selects
an option from the list, the hsn_decription will be stored in the field
specified by the user.
task-3646598
closesodoo/odoo#151507
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Steps to reproduce:
===================
- Open any app (sales for example)
- Toggle studio
- select reports tab
- Select any report
- Select some text and open any dropdown (font size or color)
- Click somewhere else on the document
- Select some text again
- The dropdown stayed open from the first select
Origin of the issue:
====================
Clicking somewhere on the document in studio doesn't trigger the events
`defined in bootstrap/js/dist/dropdown.js` because of the iframe.
Solution:
=========
Trigger click event on toggle button for the opened dropdown when hiding
the toolbar to close them
task-3674736
closesodoo/odoo#154969
X-original-commit: 878f3b27966a278a9332ef43e827eb2006911583
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
As of the first of March 2024, the SST tax
will increase from 6% to 8%.
To that end, the current 6% tax will be set
to inactive by default, and we will add
a new 8% service tax to replace it.
Task id # 3748127
closesodoo/odoo#154966
X-original-commit: 772d16bc6da7a696681805be42ca48e8cfd13db2
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Order name rather than ID so that the user has more control on documents
published in eCommerce and quote builder. Minor CSS cleanup.
closesodoo/odoo#154961
Signed-off-by: Fabien Pinckaers (fp) <fp@odoo.com>
Issue:
Articles were erroneously marked as changed,
leading to unnecessary autosaves. Part of this was
caused by the inclusion of history IDs in the
content comparison process, which differ even
without substantive content changes.
Solution:
Applied `stripHistoryIds` to the content obtained
from the WYSIWYG editor before performing the
dirty check. This ensures that comparisons focus
solely on actual content changes, eliminating
history IDs as a factor in the dirty state
determination.
opw-3707380
closesodoo/odoo#154068
Related: odoo/enterprise#56626
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Description:
In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1,
you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()`
to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending
on the version.
On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider.
On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the
wrong company, preventing the record from being created.
In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly
for the new record.
Desired behavior after PR is merged:
The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method
opw-3683338
closesodoo/odoo#154521
X-original-commit: 76cf4221b332c924c243e19f911131431c041bc6
Signed-off-by: Joel Bluemel (jobl) <jobl@odoo.com>
*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
