Steps to reproduce
==================
- Install Expense (hr_expense)
- Use a small viewport
- Go to Expense
=> The status bar overflows
opw-3704233
closesodoo/odoo#156114
X-original-commit: b1c91dded0a11c870f1618869a7810317ea05643
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
When QWeb templates became cached and compiled in [1], the list of
default cache key elements did not contain `inherit_branding_auto`
(but it included the old `inherit_branding`).
Because of this the cache was shared between restricted editors and
public users, which could lead to problems such as missing the branding
on edited fields.
Steps to reproduce:
- Use a single browser instance and do not log any user out.
- Start with `website_sale`.
- Make "demo" user a restricted editor and a sales administrator.
- Connect on 127.0.0.1 as "demo" and go to a product website page.
- Go to 127.0.0.2 as a visitor and go to the same product page.
=> The product name field of the visitor page was branded.
If you swap the last two steps, the "demo" user's page lacks the
branding.
[1]: https://github.com/odoo/odoo/commit/7ede9bcb2de9d52994b3a6fcb84edc3f81d60284
task-3482439
closesodoo/odoo#156146
X-original-commit: 821888023db462d522c5d6de84fcab80a81c2713
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the commit [1], a new element called "o_header_hide_on_scroll" was
introduced in some header templates. This element has the feature of
gradually decreasing its height as you start scrolling the page until it
completely disappears. To reduce the height of this element without
leaving its contents fully visible (because they maintain their height),
we added an "overflow: hidden" property on it. However, this "overflow:
hidden" introduced a bug fixed by this commit. Due to this, the
dropdowns within the "o_header_hide_on_scroll" element, like "user menu"
dropdown or "language selection" dropdown, became invisible.
Steps to reproduce the bug:
- Go to Website edit mode.
- Click on the header.
- Choose the "Menu - Sales 2" template from the options.
- Select the "Fixed" Scroll Effect from the options.
- Click on the "User Menu" dropdown in the header.
- Bug: The dropdown menu does not appear. The same issue occurs if you
type something in the search bar; the dropdown with the results does not
appear either.
To fix this, we don't apply "overflow: hidden" on the
"o_header_hide_on_scroll" element when the page hasn't been scrolled
yet. And if the page has been scrolled just a bit and the user clicks on
a dropdown or the search bar, we scroll the page to the top first, and
then display the dropdown menu.
This commit also add a test tour to prevent the bug from reappearing.
[1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb
opw-3698887
closesodoo/odoo#154979
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Description of the issue/feature this PR addresses:
In the kanban view of all applicants within the recruitment module, an issue
arises when applicants attempt to upload documents.
Current behavior before PR:
upload button is hidden while uncheck the settings from Documents for
Recruitment.
Desired behavior after PR is merged:
upload button is visible while uncheck the settings from Documents for
Recruitment.
Fix:
The PR addresses the problem by modifying tree view of ir.attachment and
default_res_model in the context. This adjustment is crucial as the current
setting results in an incorrect model name, preventing the display of uploaded
documents in this model.
task-3579833
closesodoo/odoo#155958
X-original-commit: 0bd4a6ed4732156ab37bc555ea5228ca752dfced
Related: odoo/enterprise#57840
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Before this commit:
===================
If there is an order with a total amount of 0 in kiosk mode, then after the cart
page it is redirected to the home page without printing a receipt.
After this commit:
==================
with this commit, if an order amount is 0 then it will redirect to the
confirmation/receipt page like a normal order with the amount without
redirecting to the payment page.
task - 3773450
closesodoo/odoo#155826
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Fix import of invoices with fixed taxes, discount and quantity > 1.
When exporting the UBL xml, we compute the fixed tax amount of the line
and create a charge on the line with this amount (e.g. see the test).
When importing this xml, we read the charges with code 'AEO' on each
lines and use the `amount` and `name` to search the fixed taxes on the
database. This issue is that we do not take the quantity of the line
into account: if we have a line with quantity = 2, and the fixed tax
amount = 1, the xml indicates a charge of 2. When we import the line,
the amount of the fixed tax to be searched should be 2 / quantity = 1.
In addition, add an test for the export and import of a line with
quantity > 1, a discount, a fixed tax and a regular tax.
opw-3717306
closesodoo/odoo#155613
X-original-commit: a1bcdc28973f712e608c6ab8067f58a2ba69ea95
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Problem
---------
Due to commit 8d77045b46, restrictions
were added to taxes that were used in transactions. However, this
behavior worsens user experience; users that would like to modify a tax
would have to duplicate it, update the duplicated version and modify
the tax usage where necessary.
For such reason, this process is being reverted (we keep the tracking of
the modification).
The tracking of repartition lines now also includes the sequence of the
lines since it is not restricted anymore.
Furthermore, `_message_log_repartition_lines` has been updated to log
messages when new repartition lines are added or repartition lines are
removed. It also has been update to track changes of lines by comparing
their position in the tax (rel. sequence) and not their IDs. Doing so
allows to remove unnecessary logging when, for example, users remove a
repartition line and immediately add a new one similar to the one
deleted. It also allows to not log reordering event of two similar lines.
original-commit: 8d77045b46
task-3450002
closesodoo/odoo#155055
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Current behavior:
When adding a product with a multi selection attribute, the attribute is
not displayed in the product configurator popup. This only happens when
opening it on a mobile device.
Steps to reproduce:
- Add a product with a multi selection attribute
- Open PoS
- Add the product to the order
- The attribute is not shown on the product configurator popup
opw-3711164
closesodoo/odoo#154893
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit adds the module pos_razorpay to add a new payment
method of razorpay to point_of_sale.
closesodoo/odoo#153627
Task: 3691186
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Since PR #152893, `mail_activity_schedule_from_chatter` test was failing on some
runbot builds. The problem is, the `timeout` to make sure the activity
type input is ready (has its data) to click again, is not enough for all builds.
Instead of using timeout (which is not same for different builds), we can add an
extra step to check if the activity id input has its data after clicking on
dropdown, to proceed to the next steps.
fixes runbot-57738
closesodoo/odoo#156030
Signed-off-by: Maryam Kia (maki) <maki@odoo.com>
Commit [1] refactored the tabs snippets options, in doing so, it
introduced a selector which could also target a tabs snippet from within
its own tab. This leads to very weird behaviour on clone.
Commit [2] introduced a new MultipleItems abstract option, and with it,
added a selector which could cause the same issue as above.
This commit fixes that by using replacing the selectors to only select
the panes of the parent Tabs snippet.
Steps to reproduce:
- Create a new web page
- Add a "Tabs" block
- Put some text in each tab in other to identify which text belongs to which tab
- In the first tab, add a new "Tabs" block, so that you will have tabs and sub-tabs
- Put some text in sub tabs in order to identify which text belongs to which sub tab
- try to add a new tab in your main tab block
=> look at the beautiful mess it creates.
[1]: https://github.com/odoo/odoo/commit/7572cc150d5469af92138533a024cffbd57d878e
[2]: https://github.com/odoo/odoo/commit/ebfa28638b47a7be45b96d561bdf144c3487f366
opw-3730155
closesodoo/odoo#156023
X-original-commit: 6c72f256691251108ab7a560b38c070a1bcf21f4
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Currently, on raspberry pi 5 our dislay interface is invading the logger
with errors due to the absence of both tvservice and the required
vcgencmd methods to identify the connected displays
While searching for a solution we can avoid the excessive log errors by
protecting the subprocess calls.
When using vcgencmd, the python wrapper of vcgencmd raises a
subprocess.CalledSubprocessError.
The tvservice does not exist on new rpi models so there is no need to
protect it
While the errors will still be present in the logs for a fresh image at
the moment,
once an rpi5 is connected to a database, it will receive the code from
this PR and will handle the exceptions more gracefully
task-3771334
closesodoo/odoo#155882
X-original-commit: 9dbcc7249d23fba36287c09c15252451ab6d0d87
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
-User might not know what they going to type in, this commit add a
placeholder in the input of industry selection to give a hint for user
when in website creation
closesodoo/odoo#155862
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce
==================
- Install Timesheets
- Login as Admin
- Edit the access rights of Mark Demo:
* Timesheets: "User: all timesheets"
* Employees: "None"
- Logout and login as Demo
- Go to a project task
- Switch to the Timesheets notebook
- Add a new line
- Click on the employee field > Search More
=> An error occurred
Cause of the issue
==================
The hr.employee.public model is an SQL view of the hr.employee table
with differents permissions.
Since the user doesn't have the hr.group_hr_user group, the model
hr.employee.public should be used and not hr.employee.
Since [0], the model is switched depending on whether the user has the
appropriate group.
The EmployeeFieldRelationMixin is used and defines a getter for the
relation. That relation was not propagated to the Many2OneField.
Solution
========
Pass the relation to the many2OneProps.
---
[0]: https://github.com/odoo/odoo/pull/136786
opw-3765393
closesodoo/odoo#155743
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Before this commit, the POS receipt was added to the bottom of the
page after printing. In some browsers, this caused overflow and made
the POS interface scrollable.
With this commit, we fix this issue by changing the position of the
receipt container to 'fixed'. This prevents the receipt from affecting
the layout of the page after printing, thus avoiding the overflow issue
and keeping the POS interface non-scrollable.
opw-3775808
closesodoo/odoo#156025
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
If booth exists for this event, bot will discover it via crawling.
Don't need to ask to crawler to check for each event if a booth exists.
closesodoo/odoo#156022
Signed-off-by: Jérémy Kersten <jke@odoo.com>
User settings is used to store user's preferences, in web we use it
to store the home menus apps order and in mail for various settings like
push to talk key, discuss sidebar preferences, etc.
Before this commit, the `setUserSettings` method from the user service
overrided all the previous key that has not been changed because it
kept only the changed keys returned by the backend.
Leading to preferences being lost during the session when reordering the
home menu apps.
With this commit, we keep the previous keys that have not been changed.
Steps to reproduce:
- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
"id": 1,
"user_id": {
"id": 2
},
"is_discuss_sidebar_category_channel_open": true,
"is_discuss_sidebar_category_chat_open": true,
"push_to_talk_key": false,
"use_push_to_talk": false,
"voice_active_duration": 0,
"volume_settings_ids": [
[
"ADD",
[]
]
],
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
"voip_username": false,
"voip_secret": false,
"should_call_from_another_device": false,
"external_device_number": false,
"should_auto_reject_incoming_calls": false,
"how_to_call_on_mobile": "ask",
"is_discuss_sidebar_category_whatsapp_open": true,
"onsip_auth_username": false,
"livechat_username": false,
"livechat_lang_ids": [],
"is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
"id": 1,
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```
closesodoo/odoo#155902
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Prior to this commit, enabling auto receipt printing resulted in the QR
code not being printed on the receipt. This was due to the QR image
being fetched post printing. This commit addresses the issue by first
loading the QR code image, then sending it to the printer, ensuring its
presence on the printed receipt.
opw-3763169
closesodoo/odoo#155354
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
- Open POS session
- Sell a consumable product in POS (no invoice)
- Close session
Bug:
an expense entry is added to the Account move
opw-3705156
closesodoo/odoo#153657
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, there could be race conditions in which a channel
could be removed while the call was still loading, this commit prevents
this issue.
task-3660964
closesodoo/odoo#149034
Signed-off-by: Thanh Son Dodeur (tso) <tso@odoo.com>
Issue:
=====
Clicking on hex color or rbga in colorpicker will reselect the inital
selected text and not the value if hex or rgba.
Steps to reproduce the issue:
=============================
- Create a note , type anything and apply custom color
- When clicking on the hex color code , the cursor is alwyas set back to
the text.
Origin of the issue:
====================
The behavior was introduced by
https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3
In the click listener, we always reset the comuted selection wich
reselects the original text. When clicking on empty space on the
dropdown menu, it happens too but it doesn't matter since the menu
closes anyway, but clicking on text input fields that you want to update
will be a problem since the menu doesn't close but the text get
reselected.
Solution:
=========
To overcome the problem of resetting when clicking on the dropdown, we
first check if the click is on the colorpicker or not, if Yes do nothing and
skip this.
task-3648629
closesodoo/odoo#155947
X-original-commit: 2c0a68df214f69b3d459507a6ce867620bf0513f
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added
on the partner. These fields are used to fill the `<cbc:EndpointID` node.
Before that, we had to map every localization specific field to this
node. For instance, with the norvegian "Bronnoysund" field (see: [1]).
To ensure the node was filled, a constraint was checking the existence
of this field.
Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer
have to require the bronnoysund to be filled.
[1] https://github.com/odoo/odoo/blob/saas-16.1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L119
opw-3763725
closesodoo/odoo#155901
X-original-commit: 6827d6a5d0c213f11cae92655cfe015cae56b8fa
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Before this commit, the bg-primary class was overwriting the bg_color
set by the user after saving changes as it has the !important tag.
Steps to reproduce the issue:
1. Go to Shop page on website
2. Enable edit mode
3. Pick a product and create a new Badge (ribbon)
4. Change the background color and save changes
-> color reverts to bg-primary
This commit fixes this behavior by adding the !important tag to the
bg_color so that it properly overwrites the bg-primary color.
opw-3734598
closesodoo/odoo#155274
X-original-commit: 9ee115b58342b3e0dbc11081e7ff752c10f8bfa9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Simon Goffaux (sigo) <sigo@odoo.com>
When a company's annual inventory day is selected which is higher
than the number of days in that month, there are already safeguards in
the feature to ensure the latest day possible for that month is
selected. Unfortunately the related test forgot to take this into
account for leap years, so this commit modifies it to test for this
expected safeguard.
closesodoo/odoo#155987
X-original-commit: 91a6b994455b288e20c688c4e88d7d2aa5cb6f0b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts
for localizations that were so far missing them. However, the mechanism
for specifying the default tax closing accounts changed in 16.2: they
must now be specified on the tax groups. This was not correctly done
in the fw-port, so we fix this in this commit.
closesodoo/odoo#155911
Taskid: 3524378
X-original-commit: f522550e083af22e63d219124273b47e0fcb7bbd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
This commits removes the state validation for `l10n_in_edi`
for overseas partner and now state will be only required
for e-invoicing for partner having country `India`
closesodoo/odoo#155940
X-original-commit: 209829ed6724d73c5550b911cb4225071bb7c1a3
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Not a guaranteed fix (not reproducible 1500 attempts), but applying
standard fix for `step` failing to use the new step helper.
runbot-54560
closesodoo/odoo#155925
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
In case of exception of type KeyError during the formatting with Babel
instead to raise a Traceback, we first retry with the en_US locale.
Babel fixes each week new bug of formatting like the one in the test,
but we cannot bump our default babel version since it is not in the
stable Ubuntu 22 so it is a best effort fix that will not hide all bugs
but is better that nothing.
https://github.com/python-babel/babel/pull/827closesodoo/odoo#155909
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since the PR [1] changed the rendering engine of qweb, the default
"selected" value set on selects field on the form snippet were lost once
the page is saved.
This commit builds upon the changes made in [this commit] by reinstating
the default "selected" value.
Steps to replicate:
- Go to Website -> Edit.
- Drop a Form snippet onto the page.
- Click on the 'Company' field.
- In Field > Type, opt for "Selection".
- Choose option 3 from the options list to establish it as the default.
- Save the modifications.
Issue: The expected default value for the selection field is not
retained after saving.
[1]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b
task-3767819
closesodoo/odoo#155838
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a crawler (eg Googlebot) come to visit your website, it grants you
a limited amount of time and ressources, it's called "Crawler budget".
If you have millions of URLs, it won't go through each one of them in a
single go.
The best you can help those crawler, the better. The sitemap `lastmod`
attribute, despite not being fully respected and trusted by crawlers, is
one of the way you can still try to help them.
For website.pages, it's already done. But for controllers, it's not an
easy thing to do as we have no way to automatically figure what are the
relevant records/fields to look at to know the last update date.
For instance, on the event pages, some pages content are mostly stored
inside an `ir.ui.view`, but the title, hours etc are part of the event
itself.
We can't just say "we take the last write_date of the record", it's
wrong in 2 ways:
- The first one I just explained where we wouldn't be able to easily get
all the elements part of the page rendering and would miss a possible
element write_date, leaving an outdated date in `lastmod`.
- Then, there is another issue (which is more problematic in stable):
the `write_date` is often updated for non website related purposes.
For instance, on /partners/<partner>, we wouldn't be able to use the
write date on odoo.com as the partners shown there (having a grade)
are update every weeks in average, because of many fields, for
instance: commission_plan_id, partner_weight, grade_id, ...
Still, there is a quick win possible in stable about forum posts which
are not impacted by the 2 issues explained above:
- The `write_date` doesn't seem to be updated too frequently for
(sitemap) irrelevant reasons. We can ensure to show a date which is
only modified when the forum.post page really gets a modification.
- All the forum.post information displayed on the page are stored inside
the forum.post itself.
This commit is thus adding the `lastmod` on forum.post URLs in the
sitemap in hope of not making Google waste time on (very) old posts.
Note: we don't use the `last_activity_date` as it wouldn't be updated in
case of the post `content` or `name` being modified for instance,
which would be wrong.
Some metrics: On odoo.com, out of the 83499 forum posts having a
`last_activity_date < 2023-10-01`, only 2335 have a `write_date`
after `2023-10-01`. It means that those two fields are actually
giving almost the same results.
Using `write_date` is thus the best choice: not impacted by the
issues mentioned above and cover all relevant record change, as
opposed to `last_activity_date`.
Note: the `lastmod` has to be trustworthy and correct, if you set wrong
or outdated info inside it, Google won't trust you/it anymore.
closesodoo/odoo#155197
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The live chat should always be on top of other elements: some sites
that embeds it use z-index for various purposes. Currently, the live
chat does not uses z-index, thus is it can be hidden by other
elements.
This PR sets the z-index to the largest value handled by the browser.
opw-3732033
closesodoo/odoo#155903
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On the analytic widget, when putting an Analytic Account, a floppy disk appear
on top of the wizard.
This button is used to create a new analytic distribution template. It is
confusing for users that thinks that the purpose of the button is to save the
analytic distribution.
This PR will replace the button to be a link called "New model".
Also, this pr will fill some field (partner_id, account_prefix and product_id)
if there are populated.
closesodoo/odoo#155611
Task: 3736786
X-original-commit: c44367a2f67f305052d28a3b9e313ad63ff46907
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
How to reproduce:
- Install CRM with demo data
- Configure one activity type to keep done activities
- Go to CRM and chose a kanban column with a green status (only planned
activities for that state)
- On a lead of that column, add an activity of the type chosen above with a
deadline in the past
- When going back to the kanban view, that column has the overdue status (red)
- Mark that activity as done
- Reload the kanban view
The kanban column has still the status overdue (red) while there are no more
overdue activity in that state.
With this fix, after reloading the kanban view, the header displays the correct
status summary. In the example above, the kanban column header is green.
While adding test, we have noticed that the 2 methods _read_group_groupby and
_search_activity_state were computing the activity state differently leading to
inconsistency. Actually, the newly added test was failing because the
read_group was returning 2 overdue records while only one was. We correct this
here as well by using the same computation in the 2 methods.
Technical note: archived activities were returned when grouping by
activity_state because that part was done in SQL and not taking into account
the recently added active field. While adding it in the "_read_group_groupby"
method, we also add it in "_search_activity_state" to avoid the same problem
when searching on activity_state.
Task-3732333
closesodoo/odoo#153274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if a SelectionField was used in a kanban view
alongside the HandleField (enabling re-sequencing, i.e. drag&drop),
the "select" element couldn't be edited. This is because the d&d
feature calls preventDefault on almost all "pointerdown" events
occuring in the card, and the "pointerdown" event is the one that
opens the select.
There's no usecase in 17.0, but there's one in master, in the
product document kanban view.
We fix this in 17.0 which is the version that introduced the kanban
version of the SelectionField.
closesodoo/odoo#155827
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, using context key `force_price_include=False` had
different interpretations in different methods
In `compute_all` its semantic was forcing the "price_include" of taxes
to be False
In `_compute_amount` it was ignored (as only value "True" was overriding
anything)
To add to this incoherence, compute_all does use
`force_price_include=False` when calling `_compute_amount`.
This commits brings semantical coherence to the `account_tax` methods by
keeping both interpretations of the context key the same: an override of
price_include, whether its value True or False.
This fixes a ticket in which the client uses that override to inverse
the computation of `price_unit` from a tax-excluded counterpart.
owp-3770871
closesodoo/odoo#155813
X-original-commit: 9b852b29e94bf0522f1b041caf12fa648ceb13c6
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps
-----
1. Create a loyalty card program awarding 1 point per $ spent;
2. make sure "Show points Unit" is enabled;
3. give yourself a loyalty card with 267.39 points on it;
4. create a product with a price of $0.89;
5. go to website and add it to your shopping car;
6. go to checkout.
Issue
-----
> You have 268.28000000000003 Loyalty point(s)
Cause
-----
The number comes from the `_get_real_points_for_coupon` method, which
uses `float_round` by way of `res.currency`.
The `float_round` function isn't suited for raw number display, as it
can make tiny rounding errors due to floating point arithmetic.
Solution
--------
Add a `_format_points` method to `loyalty.card` which will return a
string using the same format the `points_display` field uses.
opw-3705546
closesodoo/odoo#155652
X-original-commit: 767405a6fe8cea0407632acb57aae8bf25d8c001
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Versions
--------
- 17.0+
Steps
-----
1. Use iOS app;
2. click on red dot on top;
3. click check in.
Issue
-----
Nothing happens.
Cause
-----
The iOS app cannot request the user's location.
Commit 1acd0b6c5d attempted to fix this by
first checking whether `navigator.geolocation` exists, but the cause
is likely with its `getCurrentPosition` method instead of its existence.
Solution
--------
Instead of checking for `navigator.geolocation`, use `isIosApp` to skip
the geolocation part when using the iOS app.
opw-3734385
closesodoo/odoo#155588
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Add a hook to prepare attachment values needed for attachments creation
during the pdf report generation
closesodoo/odoo#155518
X-original-commit: 9dd56a625f2b613a68746a80ee552bffbeb87455
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
1. Install l10n_mx
2. Go to Accounting > Reporting > Trial balance.
3. Click the COA SAT(XML) export button.
4. Warnings are raised.
Problem: the report should work out-of-the-box on new databases.
Cause:
1. Some tags are missing on auto-generated accounts.
2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit.
This PR migrate the incorrect data and add a default naive computation of the tag on newly created accounts.
opw-3283746
closesodoo/odoo#155762
Enterprise: https://github.com/odoo/enterprise/pull/57531
X-original-commit: c7b971d5540f86f987fdaeada9481d6f46d41c49
Related: odoo/enterprise#57732
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce the issue:
- have an employee with an allocation with an end date
- remove the employee's calendar
- go on his dashboard
- his remaining leaves amount is 0
This commit implements a new method on the resource mixin to fetch a calendar
for the record even though it might not have one. The default behaviour is
to fall back on the company's calendar to ensure a value.
This is overrided in the `hr_contract` module so that the calendar of the
contract is prioritized.
task-3609738
closesodoo/odoo#155753
X-original-commit: ff58269600da857e46f83d9be94049e3f8a84294
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
In case where display_name is null, the widget contact crash
- AttributeError: 'bool' object has no attribute 'split'
On odoo.com we have around 3K of partner that have name with null value.
So calling so widget Contact on linked res.users will crash since the
display name is False
closesodoo/odoo#155735
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Current behaviour
- when we access the daterange picker it was observed that the apply button
appeared flatter and was not vertically centered.
Expected behaviour
- add h-100 on buttons container to ensure they are vertically centered and no
longer appear flatter
- add close button in which action is similar to pressing ESC or clicking
outside the popover
Task-3624556
closesodoo/odoo#148812
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_hr_recruitment
In order to improve the accessibility of the website pages, an
`aria-label` attribute has been added on some social media anchors to
avoid a warning of type `Links do not have a discernible name`. The
`options.js` file has also been adapted in order to correctly set the
`aria-label` attribute of added social media anchors.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
In order to improve the accessibility of the website pages, an
`aria-controls` attribute has been added on `tab` elements of the
"Accordion" snippet to avoid a warning of type `Elements with an ARIA
[role] that require children to contain a specific [role] are missing
some or all of those required children`. Indeed, as explained in
[the tab role documentation]; "An element with the `tab` role should
contain the `aria-controls` property identifying a corresponding
`tabpanel` (that has a `tabpanel` role) by that element's `id`". The
`_createIDs()` method has been adapted in order to handle the update of
the `aria-controls` attribute at the update of the `tabpanel` id.
[the tab role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role#description
Part-of: odoo/odoo#140453
The goal of this commit is to add a default meta description on website
homepage and "contact us" page in order to improve their SEO and avoid a
warning of type `Document does not have a meta description`. Of course,
it is still meant to be overridden.
Part-of: odoo/odoo#140453
The goal of this commit is to add an `aria-label` attribute on the
"extra item" anchor in order to improve the accessibility of the website
pages and avoid a warning of type `Links do not have a discernible
name`. However, as the logic responsible of the creation of this anchor
is in a non lazy loaded file, the translate function `_t()` (located in
a lazy loaded file) can not be used to translate the value of the
`aria-label` attribute. To solve the problem, this value has been put in
the `data-extra-items-toggle-aria-label` attribute on the header. The
translated value is then extracted and added in the `aria-label`
attribute at the extra items button creation.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
Hubert Van De Walle