When configuring a Newsletter Block snippet to display a subscription
form, the option to decide whether a message must be displayed is only
available when "On Success" is set to "Show Message" through the button
beside that option.
Unfortunately, the general option for the "Thanks" message is not
disabled for other "On Success" values, for which no outcome can display
a message. Trying to combine these triggered an error.
This commit fixes this problem by hiding the "Display Thanks Button"
option when the "Form Subscription" template is selected.
Steps to produce:
- Install `website_mass_mailing`.
- Drop a "Newsletter Block" snippet.
- Change template to "Form Subscription".
- Click on "Subscribe" button.
- Change "On Success" to "Nothing".
- Click on "Display Thanks Button".
=> An error was displayed.
task-3748574
closesodoo/odoo#157739
X-original-commit: b090d68894fb96a73df230e021e516e6df22f40e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Previously, users were required to enter their PAN number even after manually
inputting their GSTIN, even though the PAN is inherently part of the
GSTIN (spanning from the 3rd to the 12th character). Furthermore, there was
no mechanism to alert users if the manually entered PAN did not match the PAN
segment within the GSTIN.
This commit automates the filling of the PAN based on the entered GSTIN. Now
upon entering a GSTIN, the corresponding PAN is auto-filled.
task-3767627
closesodoo/odoo#157689
X-original-commit: ffd2274498f1fbf0205e60f1b125134e4fede16e
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Earth Patel (eapa) <eapa@odoo.com>
__Current behavior before commit:__
When a sheet is deleted, `charts` from `OdooChartCorePlugin` are not
being updated.
Therefore, since the commit [`905d856`][1], `getOdooChartIds` returns
some chart ids that do not exist on any sheet anymore.
This induces a crash when opening a spreadsheet that contains such
charts.
__Description of the fix:__
Handle `DELETE_SHEET` event in `OdooChartCorePlugin` by removing Odoo
charts that don't belong to any sheet.
__Steps to reproduce the issue on runbot:__
- Insert a Odoo graph inside a spreadsheet (starting from any app)
- Add a sheet to it to the new spreadsheet
- Delete the sheet that contains the chart
- Leave the spreadsheet
- Go to Documents app and try to open the spreadsheet
-> Traceback
opw-3783745
[1]: https://github.com/odoo/odoo/commit/905d8565ad2fae3f7ff96606352ee3ab86ee78cbclosesodoo/odoo#157847
X-original-commit: d44c45234577d19a728e92368f224b0e0e59e853
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
-Step to reproduce: any custom model that inherit from mail.thread then
define a field user_id but with type is char and boom error happen at
method '_message_get_suggested_recipients' because it always expect
'user_id' to be a many2one field
closesodoo/odoo#157942
-solution: need to check the type of 'user_id' also
X-original-commit: 4aaab353da1c1ddde63f2aa1232394c0b4dd6f68
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- In 2024 the SRI changes income withholding taxes. We update minor data and create new taxes for the new percentages
closesodoo/odoo#157901
X-original-commit: c853409664e56a457e9e2619f43b9b4214da9820
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce [17.0+]:
- Create a website form of any type in which you have:
- One "Name" or other text field.
- One field with the "Date" type.
- One field "Email" with the visibility condition: "Only visible if"
a field of type "Date" "Is set".
- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.
Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.
After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component
(including the form date[time]picker fields).
One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.
The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.
[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
opw-3778129
closesodoo/odoo#157328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When you create or register a payment, the domain of the payment method
lines is based on a computed field dependent of the selected journal.
The issue is that the interface isn't blocked when waiting for the
onchange return. So if the user changes the journal, then select the
payment method quickly enough while the onchange is still pending, he
will be able to select outdated values.
It is a limitation of the js framework, so to avoid the user encoding
wrong datas, the fix here is to raise a `ValidationError` telling to
re-select the payment method.
To reproduce:
- create second bank journal, with outbound payment method lines having
different names than the ones of the first bank journal (in order to
distinct them).
- slow down the `_compute_payment_method_line_fields` method
- create a vendor payment, switch the journal to the one created and
select the second payment method (before the onchange ends).
- save the payment.
-> The payment has a payment method line from a different journal
opw-3587241
closesodoo/odoo#157872
X-original-commit: 65395bb670ec1dcf534588504057a03513cb94f6
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Arnaud Sibille (arsi) <arsi@odoo.com>
This change fixes the unexpected behavior of product image reordering:
1. Previously, when moving an image to the first or last postion, it was swapped with the first or last image. Now, it is inserted in the first or last postion, while keeping the relative ordering of the other images unchanged.
2. Previously, the main image could be in any position, but as soon as it was reordered, it would jump to the first position. Now, the main image is always in first position.
task-3581895
closesodoo/odoo#157866
X-original-commit: db9e32bbb105c5eeb74f72bfadb591e27253bf2b
Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
'false' is displayed in the popover next to the recipients in the absence of an email address as well as the title of the recipients
If the partner has no email, it should show something like "[name] (no email address)]"
test added
task-3787703
closesodoo/odoo#157850
X-original-commit: 40a2df25301daaf24c123e0b67bff408eb8cd897
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Zelong Lin (zel) <zel@odoo.com>
The s_picture snippet's image was not using the img-fluid class; which
means that if you removed the default img-thumbnail, the image could
overflow its container, especially if you replaced it with a custom
image.
The user still had the possibility to apply width: 100% to solve the
issue. This commit solves the issues by just adding the img-fluid class
for future s_picture snippets. Existing ones are not worth worrying
about: setting a 100% fixed width is an easy fix and a good practice
anyway.
task-3266862
closesodoo/odoo#157808
X-original-commit: 79208821fb60abe8f34dc45c2f282cdbf52c0d4b
Related: odoo/design-themes#784
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce issue:
1. Create a Product with Lots/Serials tracking
2. Create a BoM with an operation and add Product as By-Product
3. Create a Manufacturing Order using the BoM, click on Confirm then Plan
4. Go to Shop Floor, click on "Register [the By-Product]"
- Not the button with the units
5. Click on either "Import Lots" or "Generate Serials"
6. Enter a Lot/Serial number and click on "Generate"
7. Traceback error:
> loc_dest = self.env['stock.location'].browse(default_vals['location_dest_id'])
> KeyError: 'location_dest_id'
Explanation:
When going through the Shop Floor, the context is missing a lot of elements that are normally passed in the manufacturing order form.
https://github.com/odoo/odoo/blob/338173e231355d265ddc88bcef5e9b0a608e248e/addons/mrp/views/mrp_production_views.xml#L432-L437
Suggested fix:
`default_dest_location_id` is the missing element causing the traceback but `default_location_id` is also required to create a `stock_move_line`.
Fix in Community, test in Enterprise.
opw-3719439
closesodoo/odoo#155846
Related: odoo/enterprise#57789
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
- Go to website > Switch the navbar to "Hover" mode (see: `Submenus` >
`On Hover`).
- Create a submenu and drag it under a navbar menu item > The submenu
will always disappear before being reached after the hover.
Since Bootstrap does not provide a built-in way to use the "hover" as a
dropdown trigger, a custom implementation was used to handle the "show
on hover" scenario (see: `hoverableDropdown`). This code also relies on
the submenus being correctly positioned on hover.
Starting from [1], the public `menuDirection` widget was completely
removed (used to align website navbar submenus in an optimal way) and
was replaced by a patch that allows Bootstrap to position dropdowns
dynamically inside a navbar (using Popper).
A side effect of this patch is the use of BS default offset config to
set the positions, leading to a small gap that automatically hides the
submenus when hovered.
The goal of this commit is to prevent this issue by simply forcing
the offset to 0 when the dropdowns are inside a "hover mode" navbar.
[1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
opw-3766516
closesodoo/odoo#157804
X-original-commit: d52936f7bd396f370a2a09a699ab1e0c655eb020
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, when the automatic invoice setting is enabled, a
traceback would be shown when customers pay and the post-processing of
the transaction tries to create an invoice. The problem is that the
invoice is created in sudo, but it's unsudoed before logging invoices
in the chatter.
Now, the invoice will stay sudoed if the method is called in sudo.
opw-3700576
closesodoo/odoo#157779
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In a single database, you could have two partners who are called John Doe.
Before this commit, any statement line where the partner_name was set
with 'John Doe' would return the last one being created, due to the _order
attribute on res.partner model, even if the statement line was generated
from a payment of the other 'John Doe' (ie first one created).
With this commit, we ensure that the wrong partner is not selected, in
case we cannot differentiate one from the other.
closesodoo/odoo#157754
X-original-commit: 421a0ae53de8c947d68fb1c22066d4d73c1ce9b7
Related: odoo/enterprise#58699
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior:
The pos sale report is showing the wrong value in the "Total (VAT Exl)"
column. The value acutally shown is the total tax included.
Steps to reproduce:
- Create a product with a tax included in price
- Create a pos order with this product
- Validate the order
- Close session and print the pos sales report
- Check the value in the "Total (VAT Exl)" column.
opw-3684937
closesodoo/odoo#157753
X-original-commit: ba58ac0f86e10755f1ffbc80814c3722470517f9
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Currently, when the user and the target both are in multiple companies,
the profile button cannot be displayed correctly. Since the employee_id
uses `('company_id', '=', self.env.company.id)` rather than `in`.
This commit fixes the issue by checking employee_ids directly and if it
is found, the profile button will be displayed correctly.
We don't care about which employee_id is used if there are multiple,
since the user are in multiple companies as well. If looking for a
specific profile, the employee can be found in the HR application.
closesodoo/odoo#157741
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Before this commit, the product configurator dialog was not shown when
adding to the cart, a product with only no variant attribute values,
using the buy button on the '/shop' page.
Now, if the product has configurable attributes (custom attribute, no
variant, and dynamic attribute can now be selected), the product
configurator dialog is shown.
opw-3736469
closesodoo/odoo#157737
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce
==================
- Go to Accounting > Customer Invoices
- Open any record with no attachments
- Drag & drop a pdf attachment on the chatter
=> The PDF viewer is empty
Cause of the issue
==================
When uploading an attachment from the FileUploader, the parent view is
reloaded.
This is not the case when uploading an attachment from the dropzone.
opw-3748853
closesodoo/odoo#157232
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Description:
Add missing index on FKey `tax_cash_basis_rec_id` to speed up
deletion of `account.partial.reconcile` records during reconciliation.
It's `btree_not_null` as the relationship is sparse.
Reference:
opw-3649801
closesodoo/odoo#157696
X-original-commit: 3852da88bb48e6bd82618839b5b351246129ebf6
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Purpose
=======
The time off duration is set to 0 when the related contract is set
as expired, then we remove the end date and set the contract back
to running.
That's because the check was done before calling super, hence the
contract is excluded from the candidates because it is still expired
without end date, which would make no sense when trying to retrieve
the related calendar.
closesodoo/odoo#157681
Taskid: 3806342
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, ir.actions.report can be randomed orderer.
closesodoo/odoo#157616
X-original-commit: 1a2b83d8a4fc956e07d6009eb7fc308eb16eedd2
Signed-off-by: Raphael Collet <rco@odoo.com>
The `test_calendar_month_view_start_hour_displayed` makes sure that start hour is displayed in calendar month view.
The test was failing before 09:00 AM because after creating the event, it sets the start time to 10:00 without setting the stop time or duration.
So when creating this event before 09:00 with a default duration of 1 hour, the stop time would be before 10:00, and it would raise an error.
This commit aims to fix this issue by adding a step to set the duration of the event, avoiding the potential error.
fixes runbot-59850
closesodoo/odoo#157263
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
**Current behavior:**
When creating a new product template record, the tab title will
be *Odoo - False* until a new name is saved rather than
*Odoo - New*.
**Expected behavior:**
When creating a new record in a form view, the tab title will be
*Odoo - New* until the `name` field is filled out and the record
gets saved (at which point it will be *Odoo - <name>*).
**Steps to reproduce:**
1. Install `sale_management` and go to the product list view
2. Create a new product, observe the misnamed tab title
**Cause of the issue:**
In `product.template`'s _compute_display_name() method, some of
the default values can have a 'False' (str) value which will
evaluate to True (bool), setting the name to 'False'.
**Fix:**
Set the display_name field to a False (bool) value if the
current record does not have a name field set.
opw-3793588
closesodoo/odoo#157258
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce:
- Enable 2 step reciept in warehaouse settings
Bug1:
- Create and confirm a PO qty = 1
- Open reciept update qty to 4 and validate
- The internal transfer qty is updated to 3 (the difference)
Bug2:
- In inventory overview create a new reciept and mark it as todo
- Update quantity and validate
- Internal transfer is not updated
Root cause:
Initially in version 17 product_uom_qty was changed to indicate the demand
before the move is done and it indicates the acutual done qty when
the move is done.
After https://github.com/odoo/odoo/pull/130342
product_uom_qty will always indicate the demand qty,
and qty_done will always indicate actually done quantity.
Fix:
updating the quantity will create a new move for the difference that is
used to trigger new push rule and then merged back in the original
when merging product_uom_qty is not updated to keep track of the intial
demand but pending linked moves should be updated to reflect the new quantity
opw-3708740
closesodoo/odoo#156331
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Ensure an avatar is generated based on the employee/user name
if no image is provided at the record creation (for internal users only).
closesodoo/odoo#147446
Taskid: 3637523
Related: odoo/enterprise#58646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
[This other commit] introduced a method to serve Google fonts from the
local server. Then it has been back-ported to previous versions with
[this commit].
Unfortunately, the font was not identical when the user chose to load
the font from Google servers versus from the local server. This
discrepancy was due to a missing parameter when downloading the font
file to serve it from the local server. This commit fixes the issue by
adding the missing parameter.
Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins
=> The text style changes depending on whether you checked the "Serve
font from Google servers" option or not.
[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3
opw-3775683
closesodoo/odoo#157800
X-original-commit: be2d27e69d7928a46d49a7ef0a3c4b93932a36b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
During the copy of provider if the journal is set, it create a new account.payment.method.line, and if you change the company of the new provider you have an error when you try to create a new journal.
closesodoo/odoo#157767
X-original-commit: 0357c9ec749d893ba1d7913903fd0c45df400662
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Create an invoice to partner A, confirm
Create an invoice to partner B, confirm
From Invoice list view, select just one invoice and hit register payment
It will be possible to only select journals having inbound payment
method
Now select both invoices and hit register payment
It will be possible to select any Bank journal, even if both invoice
payments should be incoming
opw-3757686
closesodoo/odoo#157732
X-original-commit: 88f43a454f3cd9207aa62e2e58b67bcfdf0fcb59
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
[FIX] microsoft_account: accessing the url without any post data
When a user tries to access the URL directly, at that time the value of
dictionary `kw` is not available. So the error will be generated.
Error : KeyError: `state`
This commit will solve the above issue by raising the `BadRequest` if the value
of dictionary `kw` does not available.
sentry-4377121133
closesodoo/odoo#157720
X-original-commit: 382b64c2f14073cfff1a8ef9290b5c7834d52188
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
------------------
- Have Website and Mail Group installed
- Send Guidelines for a mailing list through the Website app
Issue
-----
{{ object.mail_group_id.name }} appears in the body of the "Mail Group: Send Guidelines" mail template instead of the actual mail group name.
opw-3778512
closesodoo/odoo#157772
X-original-commit: fe05e7c6acf02986a154af1235ac244a7686b30b
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
When the cookie bar is activated, the optional cookies are deactivated
by default, unless you click on I agree.
This causes issues regarding UTMs:
- You can have blocks to show only if an UTM cookies has been set
- UTM should be added on sale order for instance when reaching the
website through a link with an UTM and then buying something
Steps to reproduce (utm on quotation):
1. Install ecommerce
2. Go to Settings/Website
3. Activate Cookies Bar
4. Open a private tab
5. Go to /shop?utm_campaign=Sale
6. Click on I agree on the cookie bar
7. Buy a product
8. Go back to Sales App in backend
9. Find the last public user quotation
10. Go to other info tab
11. The medium field is empty
Steps to reproduce (utm based visibility):
1. Drag & drop a snippet on a page (let's say the /page)
2. Set that snippet visibility to "Visible only if utm campaign is
"Sale"
3. Repeat step 2 3 4 from above
4. Open /page?utm_campaign=Sale
5. You will see that the block is not shown despite accepting the
cookies and having the correct utm set.
Note: we don't want that clicking on I agree reload the page, it would
solve everything but would have poor usability.
Note that with the default cookies bar, you could still naviguate to
another page, and accept the cookies later, in which case the UTM would
never be set since they would not be in the URL anymore.
It's an acceptable limitation, if that's a real issue to someone, they
have to set the popup layout to a blocking one, not the small non
intrusive one.
Fix:
When closing the cookie bar, forcing the info in the URL to be stored in
the cookies if the key is a UTM.
opw-3681927
closesodoo/odoo#157711
X-original-commit: 8c31c2b08ed84ccdb97af628d9db7f6c67c6d830
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Antoine (ande) <ande@odoo.com>
Steps to reproduce:
- Create an empty database (without demo data)
- Install stock_account
- Go to Invoicing settings
- Select Austria as Fiscal Localization
- Go to Apps
- Try to upgrade stock_account module
Issue:
A traceback is raised.
The module tries to create the default stock accounts properties on
the main company, but they already exist, which triggers a violation
of the SQL unique constraint (ir_property_unique_index) of "ir.property"
on the combination of (fields_id, company_id, res_id) fields.
Cause:
When "stock_account" module is installed/upgraded, the default stock
accounts properties are created for the main company with forcecreate="True"
option, which means they will be created if their "xml_id" doesn't exist, even
if they are declared inside <data noupdate="1">.
In this case, they are created with their "xml_id" at the module installation
with the following values:
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: False
When the Austrian localization (or other localizations defining their own
stock accounts properties) is selected in the settings, these default properties
are deleted and replaced by those coming from the localization package with
some similar values but without "xml_id":
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: [depends on the localization package]
Then, when upgrading "stock_account" module, as the "xml_id" of the default
stock accounts properties cannot be found anymore, the upgrade process will
try to re-create them and will trigger the SQL unique constraint.
Solution:
Move the creation of the default stock accounts properties in a python function
to check if the default properties already exist based on the combination of
"company_id", "fields_id" and "res_id" fields and not based on the "xml_id".
opw-3682320
closesodoo/odoo#157703
X-original-commit: 7e710e4effae6dc812a9304090b5796b39fed640
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit, there was no message in the logs when the import of
a data module is finished. This commit adds a log info to state that the
module is now in the db.
closesodoo/odoo#157687
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
This change allows for locked purchase orders to be matched with OCR
closesodoo/odoo#157569
Task: 3798080
X-original-commit: 59fe446aee1ee6d634aa286adc261a3c7f547d14
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Joris Makauskis (jmak) <jmak@odoo.com>
Before this commit:
POS online payments uses the logged-in user or the public user,
even when a POS order customer might also be present.
After this commit:
We check the partner_id for POS orders and give it
precedence over both the logged-in user and the public user.
task-3805695
closesodoo/odoo#157562
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue
-----
In a POS session, some buttons of the numpad and some fields in the client editor form are not translated.
opw-3783252
opw-3756593
closesodoo/odoo#157509
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps to reproduce:
-----
1. Have lunch app activated
2. Settings > Technical > Scheduled Actions
3. Run manually a scheduled action to send an automatic email to a lunch provider with "send order by" not equal to email.
** Traceback error **
Changes
-------
The user will see an UserError instead of a traceback.
opw-3751229
closesodoo/odoo#157305
X-original-commit: 13792ee52f96d739ef1b7af0f1323906b1a39ee4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Steps to reproduce:
- Install timesheets
- click on all timesheets
- open search view
Issue:
- in search view 'my' filters block should be at the top of the list
Cause:
- misplacing of the name month filter causes the issue.
Solution:
- if we replace that filter below the group then the issue will be solved.
task-3772684
closesodoo/odoo#155714
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since this commit [1], the two searchbar snippets are broken.
The search bar input seems invisible because it shares the same color as
the default snippet background and has no border. This style matches the
search inputs used in apps (like the "/shop" search bar), which isn't
affected by the "Input fields" settings in the "Theme" tab.
To resolve this issue, this commit introduces a new option to choose
between the "light" style (similar to "/shop" search bars) and the
"default input style" for the 2 "Search" snippets.
The "default input style" is automatically applied when the "Search"
snippet (excluding saved snippets) is dropped to address the issue
caused by the light-on-light color scheme.
Steps to reproduce the issue:
- While in Website edit mode, drag and drop a "Search" snippet onto the
page.
- Bug: The input appears invisible due to the lack of a border and a
background color identical to the snippet's section color.
[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20
task-3662985
closesodoo/odoo#154435
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
In Knowledge, embedded views anchors have a `data-behavior-props` attribute
containing information on how to render the embedded view. That attribute is
sometimes updated, and during a collaborative session, receiving such an update
as a collaborative step would trigger a full sanitization of the embedded view,
possibly discarding some transient content that could break the view, even
though it caused no security issue since it is all rendered on a per client
basis (each client fully renders its own view).
The proposed solution is to sanitize only the attribute of the node and not its
content during `_safeSetAttribute`, which is reasonable, because the node
content is already sanitized recursively for `add` mutations.
task-3060490
closesodoo/odoo#157669
X-original-commit: d9e3d7bdb6e13e6049a86ed08160daccf0fcbcc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"
The design of the karma wheel is broken because the translation for "Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k xp pour passer au niveau supérieur"). While in French the text go outside the wheel and it appears clearly broken, it is also the case in English as the rank name is hidden due to the length of the text (for example when gaining one karma: 7.49k is displayed instead of 7.5k which takes more place).
To avoid modifying the template "profile_next_rank_card" that could break community overrides, we solve this problem in css by increasing the karma wheel size and the precentage of width occupied by the text inside the wheel. We also reduce the vertical margin between the rank name and the descriptive text and reduce the line height to avoid the text to overlap with the wheel. And if the text is still too large for some language it will be truncated and an ellipsis will be used.
Technical note: we do the change in website_profile.scss (and not in website_slides.scss) because it applies to both karma wheel: the one on course home page and the one in the profile page.
[FIX] gamification: fix incorrect next rank
How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"
The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be: 4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next level is doctor at 10k).
We solve that issue by fixing the method that determine the next rank (see technical note for more details).
Technical note: the problem occurs because the admin user has the rank 4 but its field next_rank_id is null while there is a level 5. In that condition, the method _get_next_rank returns an empty recordset while it should return the rank 5. We simplify that method to always return a rank if there is one suitable (if you reach the last level, there are no next level).
(Initial PR in saas-16.1: odoo/odoo#151372)
Task-3617054
closesodoo/odoo#157655
Forward-port-of: odoo/odoo#157585
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Olivier Dony