The changes happening in the header often break the history, because a
lot of them add steps in it while they should not be observed at all.
This results in losing the redo history, having to click multiple times
to undo one specific change or even seeing some intermediate states that
should not be appearing, every time we interact with the header (e.g. by
opening/closing a dropdown or a burger menu, resizing or scrolling the
window).
This commit fixes these history issues by not observing some problematic
changes. Note that this commit only fixes the most "annoying" ones (i.e.
the ones that break things) that prevented the other commits of this PR
to work correctly. A second pass will be needed to remove other useless
mutations (i.e. that do not break things but should not be observed
either). This commit will also need to be backported, as these issues
are also present in earlier versions.
Here are the changes that are not observed anymore:
- When we open/close a "burger" menu (i.e. the "Hamburger menu" or in
mobile view). It was adding a step in the history, so if we opened and
closed it in the middle of a redo, we would lose the remaining "redo".
- When the extra menu is added/adapted. When resizing the window, which
also means toggling the mobile view, if there is not enough space for
all the desktop menus to be visible, they are moved in an extra ("+")
menu (they are moved out when there is enough space). This resulted in
the intermediate state where the menus are not in the extra menu yet to
be visible when undoing at some point, which did not look good.
- When hiding a dropdown by scrolling the page and hiding a hoverable
dropdown by clicking somewhere on the page. When they are hidden this
way, undoing the change that will be done after that would reopen the
dropdown, which could be annoying if the dropdown was a mega menu for
example.
- When showing a hoverable dropdown. This added a step in the history,
and since opening a "clickable" dropdown does not do it, this also
should not be the case for a hoverable one.
task-3609531
opw-3730165
Part-of: odoo/odoo#146492
With the headers redesign in PR [1], the "collapse menus" (e.g. in the
"Hamburger menu" and the mobile menu) are now `Offcanvas` elements
instead of `Collapse` elements (see `data-bs-toggle="offcanvas"` in the
headers XML templates). As such, when they are toggled, it is now
`bs.offcanvas` events that are fired, instead of `bs.collapse`.
However, the code using these elements and handling these events has not
been adapted and is therefore never executed, which causes some issues.
1) First issue:
- In edit mode, drop enough snippets to have a scroll bar.
- Toggle the mobile preview and open the menu or resize the screen so it
is smaller than the `SM` screen breakpoint.
- With the menu still open, go back to the desktop view or resize it up
beyond the `SM` breakpoint.
=> There is no scrollbar anymore so we cannot scroll.
This happens because the selectors and event listeners managing the
collapse menus and the scroll do not target the right elements/events.
- On toggle, the `overflow-hidden` class should be added on the body to
prevent the scroll.
- On hide, this class should be removed to re-allow scrolling.
=> Here the scroll is prevented by chance thanks to commit [2] but it is
not the right flow.
- On resize, when the screen becomes bigger than `SM`, the collapse menu
should be closed and the `overflow-hidden` class removed from the body
(see the `_updateHeaderOnResize` function).
=> Not happening because the collapse menu selector is not the right one
and commit [2] does not take the resizing into account.
2) Second issue:
- Change the menu to "Hamburger menu".
- Set the background to a dark color (so that the text is white).
- Set the "Header Position" option to "Over The Content".
- Open the menu.
=> The menu is still considered as transparent so the text is dark on a
dark background, making it difficult to read.
This issue was originally fixed by commit [3], by adding the `o_top_menu
_collapse_shown` class when the menu is opened. It happens again because
since the event is not the right one anymore, the class is never added.
This commit adapts the menus public widgets code in order to consider
these `Offcanvas` elements/events and restore the needed behaviors.
Note that the `NavbarDropdown` public widget (added in commit [4]) is
now useless. Indeed, it was added in order to prevent the dropdowns to
be hidden when opened inside a burger menu, but this issue does not
happen anymore when following the steps. It has already been removed in
master by commit [5].
The same goes for the `TopMenuCollapse` public widget, which was added
in commit [6] to avoid having a scrollbar when opening a sub-menu after
resizing up the screen with the mobile menu open. It is not even started
because its selector is not valid anymore (the `top_menu_collapse` id
only exists in the "Hamburger menu", where the issue cannot happen), and
the issue is not there anymore when following the steps, which makes the
widget useless. It will be removed in master.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510
[4]: https://github.com/odoo/odoo/commit/ce9b350403ff7c1004b50b39588891ee652e0a3a
[5]: https://github.com/odoo/odoo/commit/39b79832a0cd3e191077a11a485de78365928feb
[6]: https://github.com/odoo/odoo/commit/b7a4538c51aacca666920bdd9496ee575ab12e7a
task-3609531
Part-of: odoo/odoo#146492
*: test_website_modules
In PR [1], the headers have been redesigned. One of their major changes
is that now, they have two navbars: one for the desktop view and one for
the mobile view.
However, the `o_main_nav` and `top_menu` navbar ids are also duplicated,
meaning that there are multiple elements with the same id in the DOM,
which is not a good practice.
This commit fixes this by replacing the ids by classes in the navbar
templates, since their use does not really require for them to be ids
(e.g. `#o_main_nav` is mainly for styling). For the desktop view, the
ids are still kept (for stability purpose).
Note that the CSS rules and the selectors in the JS files (except for
the tests) now take into account both the ids and the classes (to be
safe).
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
Part-of: odoo/odoo#146492
Current Behavior:
The word "Discount" is translated in the users language unlike the
content of the description which is translated into the customer's
language
Expected behavior:
The word "Discount" should be translated as the content of the
description.
Steps to reproduce:
Sales > Product > Discount & Loyalty
Create a new loyalty program and add a translation to the reward
description.
Create a SO for a customer with the same language. Add products to
meet the requirements of the loyalty program and click on
Promotion.
A line is created for the reward, but the word "Discount" is not
translated into the customer's language, but the rest of the
description is.
Cause of the issue:
The translation of the word Discount is done inside a dictionary
comprehension using the _ = GettextAlias() method.
As a result, 'self' does not appear in the arguments from which _
guesses the contextual language. Therefore, the language in which the
translation happens is the contextual language of the request (user).
Fix:
The translation is applied before the discionary comprehension so that
the method "_" correctly guesses the contextual language.
opw-3700429
closesodoo/odoo#155296
X-original-commit: 03cbf7238400130c412a1606b6a9a2f22725e590
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit:
- In the fullscreen player, the content of an article from any course stuck to
the contents sidebar, leading to a lack of visual separation.
After this commit:
- Added padding to the article content in fullscreen view. Creating a clear
distinction between the content and the sidebar.
Task-3748836
closesodoo/odoo#155207
X-original-commit: ebb86b65acc2cf59fd3272f56054c00b161fe9aa
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Shubham Thanki (shut) <shut@odoo.com>
Prior to this commit, the receipt element was cloned and appended to
the render-container for web printing, then deleted after print
callback. This approach failed on Android, leading to an empty page,
as the cloned element was removed before printing. This commit resolves
the issue by retaining the cloned element until the next clone addition
to the container, at which point existing elements are removed.
opw-3755682
closesodoo/odoo#154777
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Ease understanding the purpose of main fields on alias domains. Set bounce,
catchall and default_from available in debug mode as those are advanced
configuration bits that should be displayed (and modified) with care.
Add tooltips on fields to ease understanding the field usage.
Task-3696224
closesodoo/odoo#150401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
During the revamp (https://github.com/odoo/odoo/pull/138670) the
classes `.o_event_hatched` and `.o_event_striked` were moved.
The `o_event_hatched` works on day, week, and month
view but not in Year view of the `hr_holidays` module where the events
all look like they have the same status. The `o_event_striked`
was removed by mistake.
To fix this issue, we move the `.o_event_hatched` where it isn't under
the `.fc-event` selector (because this one doesn't exist in Year view),
and we put back `o_event_striked`.
task-3617333
part of task-3575827
closesodoo/odoo#144208
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
A character was left out of the translation pattern, so the text was
never displayed correctly to the user.
closesodoo/odoo#155331
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Following commit ac90aa07, the Customer object was no longer created on
Stripe for one-shot (non-recurring) payments made with Stripe. This
prevented Radar (Stripe's fraud detection tool) to work effectively as
it could not rely on the customer's name and addresses anymore (see
https://docs.stripe.com/radar/integration#recommendations).
This commit forces the creation of a Customer object even for one-shot
payments.
opw-3694379
closesodoo/odoo#155276
X-original-commit: 20efda51fefcc50861d9c73a483b4291e5b7e85d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Since https://github.com/odoo/odoo/commit/a54c304487429139c08f384d7b2b620b50cf6f83, sale_loyalty_delivery does not depend on stock anymore.
So, the type 'product' (and detailed_type) is not added to the selection.
The test does not fail on runbot because the module is never tested alone.
We should just change it to type 'consu'.
closesodoo/odoo#155263
X-original-commit: 88ebd8918c0ffdd9ae784967fe0de42a9299e09a
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
It is necessary to force the definition of a namespace in the string type,
as it may come from an external context.
See odoo/odoo@13af401bc2
opw-3767015
Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com>
In some scenarios, it is necessary to evaluate the representation
of fields as a string (which triggers issues if this is not the case).
closesodoo/odoo#155299
X-original-commit: e89b47f44548170abff088427149337411fcc47b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- In User settings add 'allocation reports' group to the admin User
- In Inventory settings enable allocation reports
- Create a stored product with 0/0 reordering rules and set a vendor
- Create an SO for that product
- Confirm the generated PO and click assign all on its receipt's allocation report
- Reduce the quantity on the SO and save
Bug:
a return is created instead of adjusting the quantity to deliver
the stock moves were not merged because their procurement method do not
match ('make_to_stock' / 'make_to_order')
Fix:
ignore procurement method when merging the moves
(introducing new config parameter)
opw-3621316
closesodoo/odoo#154942
X-original-commit: 337d4c79bf51f0d1705a80341fa83a88c5297128
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When l10n_pe was initially developed, there were two unresolved matters that needed clarification for the users. However, with this recent commit, the manifest has been cleaned up, and now the explanation of the module is much clearer and easily understandable for the users.”
closesodoo/odoo#155321
X-original-commit: 86f4a3dcae0f171327c8527df974b406920da3f8
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce
------------------
* install `l10n_sa_edi`
* switch to a Saudi company
* deactivate the "EDI : Perform web services operations" scheduled
action. (this will help ease the reproduction process)
* create and post two invoices for a partner that's an individual (not a
company)
* manually run that scheduled action.
You should be met with a traceback.
Cause
-----
When a ZATCA document is submitted, the system performs several
operations, two of which are important for this issue:
1. Generating a signature (`l10n_sa_invoice_signature`)
2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`)
The QR code generation relies on the assumption that the signature
(`l10n_sa_invoice_signature`) already exists, which is a reasonable
expectation as the signature is typically created prior to the QR code.
However, complications arise when multiple documents are submitted
simultaneously in a batch process. During batch processing, each
document in the batch undergoes the same two operations mentioned above.
The issue emerges due to the behavior of non-stored computed fields .
In Odoo, computed fields are evaluated in batches, meaning that if you
access a computed field for one record, Odoo may also compute the same
field for other records fetched in the same operation. For example, if
you have two records, `A` and `B` such that `B.id in A._prefetch_ids`,
and you access a computed field on `A`, Odoo will also compute this
field for `B` at the same time.
This behavior leads to an issue when submitting two documents (`D1` and
`D2`) together. The system will generate a signature and then compute
the QR code for `D1`. However, when computing the QR code for `D1`, it
inadvertently attempts to also compute the QR code for `D2` due to the
batch computation behavior. Since `D2`'s signature has not yet been
generated at this point, this results in an error.
opw-3696146
closesodoo/odoo#155269
X-original-commit: 97e67514c0e72730882cc093b36cb5477eba496d
Signed-off-by: William André (wan) <wan@odoo.com>
Cascade removal of account.report.expression records to corresponding
account.report.external.value, avoiding the following issue when upgrading:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/tmp/tmpwrjjshgf/migrations/base/0.0.0/pre-models-no-model-data-delete.py", line 103, in _process_end
return super(IrModelData, self)._process_end(modules)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2562, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2491, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4218, in unlink
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_report_expression" violates foreign key constraint "account_report_external_value_target_report_expression_id_fkey" on table "account_report_external_value"
DETAIL: Key (id)=(94) is still referenced from table "account_report_external_value".
```
closesodoo/odoo#155242
X-original-commit: d28ae22e08c86392f3d772d3d7564b1b8e70e7e0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commit backports the test introduced in odoo/odoo#155154, as
it is relevant to have it in every versions to ensure that dropdown
menu (i.e. submenus) are correctly tested.
closesodoo/odoo#155218
X-original-commit: 8915c8db63d2ebc697bbfc073e3504589a26b4b8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The following combinations of payment methods and providers are removed:
- Amazon Pay - Adyen: The payment method cannot be activated because it
requires saving a public key in Odoo, and no field was made available
for that. Also, a custom configuration is necessary and the public key
must be generated through a lengthy process that is too cumbersome for
the added value of the payment method anyway.
- BLIK - Stripe: The payment method is not supported by Stripe when the
PaymentIntent object is created after collecting the payment details.
See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods
opw-3736511
closesodoo/odoo#153481
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When creating a SOL on the fly, if the name entered matches an existing service product, selecting 'Create' should create the SOL without opening a form view modal.
We do that by fetching the `default_name` from the context.
However, from the Many2one field, since the name will already be present in the create vals, in will not be in the default values in the context.
To fix this, this commit adds a new context key when calling `name_create` that allows us to retrieve the name from the `default_get`
Task-3553151
closesodoo/odoo#155191
Related: odoo/enterprise#57344
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
When creating SOLs on the fly in the employee mapping on projects, only the "Create and Edit" option is available.
This commit enables the quick create for SOLs in the mapping.
Task-3553151
Part-of: odoo/odoo#155191
When the user creates a new record having a property field, the system
fetches the property definition of the parent record to retrieve the
field's default values (see: `_add_default_values`). If the user lacks
read access on the parent record, the user gets an access error when
retrieving the property definition of the parent record.
To prevent this error, we will perform a sudo call on the parent record
before reading the property definition of the parent record. This allow
the user to create a new record, even if they do not have access to the
parent record.
task-3594814
closesodoo/odoo#155178
X-original-commit: 6f0fb8579d8230f91b7eefc5d29f8d61390dacc4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
Before this commit, validation transactions would send an email when the
token is assigned to the order.
closesodoo/odoo#155167
Taskid: 3675875
X-original-commit: f70967e240058d8a6b095fc58c591249e517bd31
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
When a message is posted, the server sends a `mail.record/insert`
notification to update the related channel pin state. In order to
recognize the thread, the client needs its id and its model.
Currently, only the id is passed so the thread pin state is not
updated. This PR adds the model to the notification.
closesodoo/odoo#155150
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This value is accessed often during sort of messaging menu, so it's
better to not compute it each time on the fly.
- make it a compute
- access correspondent2 to avoid extra indirection
- store in variable in sort instead of accessing twice (less proxy get)
The performance impact is more visible for subsequent sorting, as the
first one benefits less from the cache (when it still has to be built).
Part-of: odoo/odoo#155068
Avoid doing this process every time the datetime is accessed.
It looks like it is already cached with `_datetime`, but it's not
efficient because there are still many proxy get access (which are
costly).
3 proxy access before: getter itself, reading _datetime twice
1 proxy access after: the field itself
Part-of: odoo/odoo#155068
Before this PR, after having imported a module, a warning appears in the
log, because it tries to update the graph which does not make sense for
an imported module.
This commit makes sure the warning is skipped if the module was
imported.
closesodoo/odoo#155096
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
decided to add the domain condition in the project.task user_ids field definition,
which means we can remove identical domains in views
Task-3698867
closesodoo/odoo#155044
X-original-commit: c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*de,din5008,din5008_purchase,din5008_repair,din5008_sale,din5008_stock
After 15.0, part of the German localization modules have been moved to
the DIN5008 modules to be shared with other countries.
We migrate the translations here to the correct modules in the versions
after 15.0 and complete missing ones.
opw-3669388
closesodoo/odoo#155035
X-original-commit: 3c97b4aa3ecd0dc6f0208fd0dcdf05217748bfd6
Related: odoo/enterprise#57247
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
If payment_custom or payment_demo is installed 'Secured by' element is
overriden and becomes hidden for all payment providers.
We removed xpath as it is more convenient for the users to see which
provider is behind a payment method. After this commit 'Secured by'
element is shown for all providers except for custom.
closesodoo/odoo#155014
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit fixes summing list of dicts returned by
_prepare_analytic_lines.
closesodoo/odoo#154937
Nb: This code is not yet covered by a test use case.
X-original-commit: 0e91af415ece2f87b95a81a3f7bfdaae5113a840
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
__getitem__() of BaseModel, reset the prefetch set of the recordset.
Fix _compute_activity_date_deadline, to batched the reading of
activity's deadline.
closesodoo/odoo#154860
X-original-commit: ef7226aaa2f0ad135133fe27bdf1414b7ebf2a92
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This refactoring of action_unbuild() enhances its extensibility for stock_move_line creation.
Previously, passing additional values to the unbuild move lines necessitated a complete override
of the method due to its rigid design. With this refactoring, it is now possible to extend
the respective methods for preparing move line values, allowing for the addition of new values
or modification of existing ones.
closesodoo/odoo#154667
X-original-commit: 9716c3116dec9d3463123914b73d0556ccd07816
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Have a SA company
In Accounting settings activate invoice terms
Add a payment terms string in english, add the arabic translation
Create an invoice
Click preview
Issue: Payment terms will be shown in english twice
This occurs because, even if `narration` field is translatable the
translation is not automatically copied when the field is copied from
the company `invoice_terms`.
opw-3530811
closesodoo/odoo#153966
X-original-commit: b49198d42db0cbc90db54f8509eae0ebbbf7b894
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Steps to reproduce
------------------
* install `account_peppol`
* open a partner's list view
* select a contact
* on the top middle, click Actions > Verify Peppol
You should be met with a traceback:
`AttributeError: 'bool' object has no attribute 'setdefault'`
Cause
-----
`button_account_peppol_check_partner_endpoint` is expected to return an
action or a falsy value (no action to perform).
opw-3683612
closesodoo/odoo#152817
Signed-off-by: William André (wan) <wan@odoo.com>
**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.
**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.
**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab
2. Give it a name and, before saving the program, edit the
'Products' field of the default rule that is created at
the bottom of the form to have at least one value
3. Now save the program and observe that the 'Products' field
has been cleared of the previously selected values
**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.
The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.
**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.
opw-3669953
closesodoo/odoo#155093
X-original-commit: 7ed0a773b6e0711b127f236ce665c35202d973bc
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Current behaviour:
500: Internal Server Error
Error while rendering the template account.report_invoice_document
Steps to reproduce:
Accounting > Configuration > invoicing > Payment Terms
New > Create and save a payment term with 2 lines
For example :
- name 80/20 test
- line_1 : 80% after 0 days
- line_2 : 20% after 30 days
Sales > Orders > Quotations
Chose any > use payment terms 80/20 test
Save and create associated invoice > chose regular invoice
> create draft invoice > preview > 500: Internal Server Error
Cause of the issue:
The method _get_amount_due_after_discount() called during the rendering
of the template does not return a value in case self.early_discount is
False.
Fix:
Return total_amount by default since no discount is applied.
opw-3683708
closesodoo/odoo#155080
X-original-commit: c8154b6aa57cc42e352260c7f75e52cd29a2d52d
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Before this commit:
When using the removeFormat button, the backgroundColor and
foregroundColor were not completely removed.
After this commit:
The removeFormat button will completely remove all the styles applied to it.
task-3344762
closesodoo/odoo#155146
X-original-commit: 9c4194ad3387c55d39ec7bbef1c6414893098c6e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
- Install Accounting
- Create a fiscal position with a legal note
- Create an invoice with the created fiscal position
- Preview the invoice
=> The legal note from the fiscal position appears on the invoice as expected
- Install l10n_it
- Preview the invoice
=> The legal note from the fiscal position doesn't appear anymore
Cause:
The condition to display the legal note from the fiscal position is overridden
by l10n_it module to only display it for Italian companies, which is not correct.
Solution:
Remove the condition about the Italian companies.
By removing that condition, the inherited view becomes useless as the overridden
condition is the same as the original one.
The inherited view will have to be removed in master.
opw-3709443
closesodoo/odoo#155072
X-original-commit: aa8646281885167698e9f8b3b549b2c4e17dc2cc
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Commit [1] introduced default images changes for the website library.
The problem is that the ir.attachment definitions are in a non-updatable
environment by mistake (apparently since forever)... so they are not
updated after update/upgrade.
This commit moves the definitions to its own updatable file, in 17.0 and
above only (ignoring potential other changes that were made in 15.0/16.0
at the time but apparently led to no issue). But this is not enough:
upgraded users will still have those ir.attachment records marked as non
updatable and will thus not be updated. Meaning that the ir.attachment
record will still reference path to images that do not exist anymore
(since [1]) and thus not display anything in related snippets, or worse:
crash on some non-robust-to-404-images options (This will be made more
robust in another update).
Note that, at the moment, we cannot solve this issue by making the
/web/image route not return a 404 but a placeholder image in that case,
for technical reasons (even though it would be consistent as this is
what is done if you try to reach `/web/image/something_with_a_typo`).
It would also be annoying to solve this problem by adding a migration
script inside the Odoo repo itself:
- It would only work if upgraded users do a -u again (unlikely).
- That would mean an upgrade script rotting in the main repo forever.
Instead, this commit chose to restore the removed images so that
upgraded users will be able to use the outdated paths. In master, an
upgrade script will be made (in the upgrade repo) to properly update all
those attachment records and be able to finally remove those outdated
images. Note that this may also be fixed without upgrade script if
non-updatable records whose XML declaration is moved out a non-updatable
area become updatable (under discussion with the framework team... we
will see when this lands in master).
Steps to reproduce:
- Install a 16.0 with the website module
- Upgrade to 17.0
- Drag a "Blockquote" snippet on a page
=> Crash and the image is missing (in the DOM but invisible and
impossible to edit). Note that the crash itself will also be fixed by
the later update that will be done to make editor options more robust
to 404 images.
[1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757
opw-3693055
opw-3723895
opw-3744257
opw-3747348
opw-3749764
...
closesodoo/odoo#155015
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Part 1: _search_is_member
-------------------------
Separate query to fetch candidate channels because the sub-select that
`_search` would generate leads psql query plan to take bad decisions.
When candidate ids are explicitly given it doesn't need to make
(incorrect) guess, at the cost of one extra but fast query.
It is expected to return hundreds of channels, a thousand at most, which
is acceptable.
A "join" would be ideal, but the ORM is currently not able to generate
it from the domain.
`sudo` is added as well because the rules for the member don't need to
be checked as no information is leaked.
Part 2: clean rules
-------------------
The rule for reading "self" is included in the rule for reading other
members. It can be disabled for "read" to avoid duplicate.
It also checked is_member again, but is_self necessarily implies it.
Part 3: clean tests
-------------------
The opportunity is taken to fix the tests. The tests where considering
as "access error" when there was an assert error inside the test (for
example not finding the channel or the member), but those needed to be
considered as failure regardless of expected outcome of access check.
Extra mute loggers are added to clean the test output.
closesodoo/odoo#153697
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Usecase to reproduce:
- Create a picking with available quantity and another without
- Confirm both picking
- In list view, select the two picking and use the validate action
Expected behavior:
The first picking is validated and the second has been untouched
Current behavior:
The second picking is picked. That will prevent any further reservation
It happens because on multiple records the error message for empty
picking is bypassed and the picked is applied on it.
Close#153983closesodoo/odoo#155039
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previously, exporting BIS3 when there is a 0% tax in the invoice will
results in the XML showing warning of UBL-CR-601. But if we do not
include any TaxExemptionReason reason at all, a fatal error BR-E-10 will
pop up.
Here is the details of those 2 rules:
```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
<assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
exists(cbc:TaxExemptionReasonCode)">
[BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
"Exempt from VAT" shall have a VAT exemption reason code (BT-121)
or a VAT exemption reason text (BT-120). </assert>
and
(no context)
<assert id="UBL-CR-601" flag="warning" test="
not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
[UBL-CR-601]-A UBL invoice should not include the InvoiceLine
Item ClassifiedTaxCategory TaxExemptionReason </assert>
```
Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax)
in TaxTotal/TaxSubtotal/TaxCategory
Previously, the TaxExemptionReason will appear on both places.
This commit fixes that and adds a test to ensure that when a 0% tax is
present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory
closesodoo/odoo#155022
Task-id: 3703206
X-original-commit: 6c2f098f46c5d90d2384c596f4cef8fa874adbd5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Soukéina Bojabza