Address several design/ux issue related to badges.
In some cases badges are too small, in others the badge should be
clickable while in others should not.
In some circumstances informative components like small alerts should be
used instead.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit simplifies the editing process of the "Talk Proposal" page
by applying `row` and `col` classes.
This enables users to adjust vertical spacing conveniently using the
editor.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Address a minor layout issue on desktop devices.
Note: "Stable friendly" fix. The 'booth_category.description' field
output, for example, should be moved outside the `card-body` element.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_exhibitor, website_event_meet, website_event_track
Previously, to expand a collapsed track, users needed to click the icon.
This commit introduces a CSS workaround that allows clicking or tapping
on the entire track header instead.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit handle an issue causing the registration inner elements to
don't overflow as expected when multiple tickets are rendered on screen.
Note: This could probably be improved by review the overall modal layout
in order to make a different use of Bootstrap default classes.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit addresses various minor responsiveness and design issues in
the "event registration modal." Additionally, it modifies the condition
for rendering prices range and to display it if more than two
tickets exist only.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_booth, website_event_exhibitor, website_event_meet,
website_event_meet_quiz, website_event_track
This commit refines headings throughout the entire `website_event`
platform by optimizing font-size hierarchy, spacing, and white-space
management for improved consistency and readability.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit addresses a scenario where users may prefer lowercase titles
over the default uppercase ones.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
*: website_event_booth, website_event_exhibitor, website_event_meet,
website_event_track
This commits address several minor layout issues across the entire
`website_event` platform.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit removes the "Fold Tickets Details" editor option that's
non-functional because the corresponding template no longer exists.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Ensure consistency in the positioning of the website_event's modal
buttons to align with odoo's standards.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
This commit enhances the user experience by rewording editor options to
ensure predictability. Specifically:
- The use of the `o_we_sublevel_1` class was misleading as these options
are not tied to the main layout type.
- The term "Templates" was ambiguous, as the option actually renders
event's template badges.
task-3718417
part of task-3698364
Part-of: odoo/odoo#152434
Commit [1] made it possible to stay in the backend while refreshing the
page with F5 or CTRL+R when viewing a Website Preview. Pressing it too
fast when the page is still loading and the iframe isn't loaded yet
triggers a traceback.
This commit falls back to the default refresh in such cases.
[1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd
task-3795143
closesodoo/odoo#158314
X-original-commit: c81dfa7dda95a8d63b4abba9ce67d7f3e48af935
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Current behaviour before commit:
After selecting cells in table, moving cursor through
arrowkeys doesn't deselect cells.
Desired behaviour after commit:
Now cells are getting deselected.
task-3718716
closesodoo/odoo#158265
X-original-commit: 0e8865e06b3cb7e8ee1a2c4983d06baef5b30933
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Adnan Saiyed (adsa) <adsa@odoo.com>
- Remove context which came from the calendar action to only show short name in activity message
- Replace date connector with - as a / does not help to better understand the data given
closesodoo/odoo#158220
X-original-commit: 125793980e10f0c7d186f5662e4abbb3de3e212a
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Steps to reproduce:
- Create 4 products: Final product (FP), Product 1,2,3 (P1,P2 and P3)
- Set routes to manifacture on each product
- For P1, P2, P3 add a 0:0 reordering rule.
- Add a BOM for P2 with 1 unit of P1 as components
- Add a BOM for P3 with 1 unit of P2 as components
- Add a BOM for FP with 1 unit of P3 and of P2 as components
The MO overview of a FP shoud look like this :
FP
/\
/ \
P3 P2
| |
P2 P1
|
P1
- Create and confirm a manufacturing order for a FP
Current behavior:
As the quantity on hand is not sufficient to manufacture a FP,
manufacturing orders are automatically created for P3, P2 and P1.
However, the quantity on each of these MOs is of 1 unit.
Expected behavior:
Since 2 units of P2 and of P1 will be required to manufacture the FP the
quantity of their respective MOs should be at 2.
Cause of the issue:
Confirming the MO for FP will call the trigger_scheduler() on its raw
stock move:
https://github.com/odoo/odoo/blob/79813f08e5a2f0188ac7d184d000486f25319503/addons/mrp/models/mrp_production.py#L1291https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L495
In this method, we compute the qty to order for the orderpoints of P2
and P3. Since these ones are positive, procurement will be run for both
of these leading to the creation of 2 new MO's via the manufacture
route. The post process of the scheduler is then run
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L550
An override of this method in mrp will then find the created MO and
confirm these, triggering the above process once more but now for the
MO's of P3 and P2 rather than FP: we start by computing the qty to order
for the orderpoints of P2 and P1 to manufacture P3 and P2. However, to
compute this quantity, we look at the forecast of these quantities and
this is where the problem comes in:
https://github.com/odoo/odoo/blob/f3ef40da0406bb0fd683dce3a08739e247fd6dfc/addons/stock/models/stock_orderpoint.py#L284
With the orderpoint of P2:
- `virtual_available` is at a value of -1 since there is currently 2
stock moves taking this product (one to manufacture FP and one to
manufacture P3) and one stock move bringing one unit of this product
(the one coming from the MO of P2 we are currently trying to confirm)
- `orderpoint._quantity_in_progress()` has a value of 1 due to the MO
of P2 that we are currently confirming.
Adding these quantities to one an other, the forecasted qty of P2 is at
0. This is a mistake since the incoming stock move for P2 is counted
twice in the forecast qty: once in each term. As a result no new
procurement will be generated for P2 hence the issue.
FIX:
Since this `_quantity_in_progress()` seems to have been introduced to
improve purchase flows rather than to interact with manufacturing flows:
https://github.com/odoo/odoo/commit/943da6df0f1d39e8e10869b25c5ba8cc13a2aa54
We decided to ignore its contribution during our manufacturing flow for
the forecast qty to be correctly computed. This requires to ignore the
contribution of each mo triggering the scheduler and those that already
triggered the scheduler since the confirmation of the MO of FP.
Notes: The test sets a little more complex MO overview than the
above use case to be sure to catch corner cases situations.
opw-3689920
closesodoo/odoo#158217
X-original-commit: 4c0b9ef2ad75d3f831fce0abaa62a1d660ba5ca6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue: Currently if we have taxes for our Purchase no matter if we set
the tax to inactive or we archive it, we will have access to it on the
purchase_order_line.
Steps to reproduce:
- Install Purchase
- Create a new Tax and set it to inactive.
- Now create a new RfQ and in the lines add any product.
- Try to change the tax for this product.
Solution: since we need this weird behavior for the cases where the tax
was applied to a RfQ and afterwards this tax was archived for example,
we should implement the needed domain to the view so we cannot access
to apply it anymore after inactive but it will still be visible where it
was applied beforehand.
opw-3776871
closesodoo/odoo#158077
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
**Current behavior:**
Creating a fixed tax with the edi formats ubl_bis3 and nlcius_1
then creating an invoice with this tax tied to a product will
cause a traceback when a user tries to confirm the invoice.
**Expected behavior:**
The invoice will post as any other might.
**Steps to reproduce:**
1. Create a NL company with l10n_nl_edi accounting
2. Create a tax with the following field values:
*tax computation: fixed*
*affect base of subsequent taxes: True*
*base affected by previous taxes: True*
3. In the customer invoices journal for the created company,
go to the 'Advanced Settings' notebook tab and enable the
NLCIUS and Peppol options under 'Electronic Invoicing'
4. Create a new invoice with some product and attach the newly
created tax to it, then try to confirm the invoice to see
the traceback
**Cause of the issue:**
The edi format tags invoke different instances of the
get_invoice_line_allowance_vals_list() method. This method
returns a dict list where the dicts only sometimes contain the
key 'allowance_charge_reason_code'. A subsequent expression
expects this key in the dict which can cause a KeyError.
**Fix:**
Check instead for a 'charge_indicator' key, which is present in
both the ubl_bis3 and nlcius_1 val dicts, allowing the correct
total to be summed and reflected in the EDI document output.
opw-3680527
closesodoo/odoo#157495
X-original-commit: 06a3027ca9f421ccc0081e2c8a5ff538175ef334
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Create a leave spanning multiple days;
2. create a public holiday that falls inside that leave;
3. check leave in list view & form view.
Issue
-----
The leave's duration no longer matches between the two views. In form
view, the duration was updated, in list view, it remained unchanged.
Cause
-----
There's nothing to trigger a recomputation of duration_display when
adding/removing leaves.
Solution
--------
The `number_of_days` field is kept up to date by the usage of
`add_to_compute` when modifying leaves. The same can be done for the
`duration_display` field.
opw-3642500
closesodoo/odoo#158296
X-original-commit: 1327b8014df79a488b1f7c1b909944ac8faff426
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Issue:
------
The `partner_autocomplete` module is an automatically installed module.
This module is not included in the dependencies
and can therefore be uninstalled.
If `partner_autocomplete` is uninstalled and we go to a shared project
with a portal user for example, we get an internal server error,
as we don't have access to the `partner_autocomplete` files.
Solution:
---------
Remove the `partner_autocomplete` files from the manifest file
of the `project` module.
Note:
If the widget is not found (in the very rare case of uninstalling
the `partner_autocomplete` module), we will use the
default widget (and create a log).
opw-3774575
closesodoo/odoo#157965
X-original-commit: 65331aee3b7c74752aed23e136f08ff1fb5d282d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Since [1] when the social share widget was introduced, a hashtag is
generated from the name of the website that is found inside the page
title.
This fails when the page title is replaced through the SEO feature.
This commit prevents the failure but not extracting the website name if
it is missing from the title.
Note that the `registry.socialShare` fixed here is only used by the
forum post page in the whole codebase. It is different from the social
snippet. The social snippet is doing the same code (kind of duplicate),
but it does not care about removing the | right part. It means that if
you drag & drop the "Share" snippet in a forum post page (like in the
footer) and click on it, it will work since it does not try to split on
the title's pipe.
In master, we will evaluate if we should remove this
`registry.socialShare` and use the `Share` snippet instead.
Steps to reproduce:
- Install website_forum.
- Go to a forum post.
- Set SEO title to a value without `|` (pipe).
- Share to X.
=> An error popup was shown.
[1]: https://github.com/odoo/odoo/commit/1c91e27c8c8cb7492d26f03e27c4991b53a1675d
opw-3799914
closesodoo/odoo#158478
X-original-commit: f89f4a8f1ad0ee3fb62ba246ea17988955dbdc4b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
With this PR https://github.com/odoo/odoo/pull/129717 we fixed
multiple problems of the Swiss tax report but the 200 box is still
not correct.
Fix the computation of the box 200 of the Swiss tax report.
We remove 382 and 383 boxes that are for purchases and shouldn't be
included.
We add box 205 and 289 so that the box 200 somehow represent the "gross"
taxed amount, and 299 is therefore the "net" amount.
200 = 302 to 343 + 205 + 289
opw-3766215
closesodoo/odoo#158477
X-original-commit: b252f0fc87c5fa15d1abbe0686d4018085e5d8b8
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Removed background color of crm enrich mail messages, so that they look
good on both light and dark mode
Related task: 3541419
closesodoo/odoo#158475
X-original-commit: 26c7b2408c248b9e81ee3c383c8cf076bbc9c552
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Joris Makauskis (jmak) <jmak@odoo.com>
Before this commit, radio buttons in the offcanvas filters (displayed
on mobile) were not working as they should: clicking on the label
worked fine but the click on the radio itself did not trigger anything.
We impeach input's `pointer-event` so, the `<a>` becomes main and only
interaction
This commit also fixes an contrast issue in the tag filter in the
offcanvas
task-3649662
closesodoo/odoo#158350
X-original-commit: f1808866aaddf82452536edfa46c6906368bd0cd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Antoine Sougné (anso) <anso@odoo.com>
Steps:
- Install sales app.
- Create SO and add a product.
- Confirm that SO and create invoice and post it.
- Reverse that invoice via adding credit note.
- Go to portal view of that SO.
Issue:
- `Waiting Payment` badge is displaying instead of
`Paid` as invoice is reversed
Cause:
- Only to payment status added to display `Paid` badge.
Fix:
- Add `Reversed` bagde in portal and display reversed badge
when payment_state is in reversed state.
opw-3677622
closesodoo/odoo#158418
X-original-commit: a4ae44c81f2a6ccb57844415012a8818a08daa2c
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
we forgot to enable the feature in the description of project.update
model.
closesodoo/odoo#158257
X-original-commit: fedb0c6f4f79e762602185dee86ce8a558000783
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, when the current user did not have
`hr.group_hr_user` group and creates a timesheet for an employee in his
team, he could get a traceback before one field defined only
`hr.employee` model cannot be fetched in `hr.employee.public` by the
ORM. The reason is because when the user creates a timesheet in a task
without any company set, we will take the company of the employee set
on the timesheet to set it in the new timesheet, by doing that, the ORM
will prefetch the fields of `hr.employee` and returned the company from
its cache.
This commit makes sure we will not have any issue when we try to get the
company of the employee to set in the new timesheet if one field defined
in `hr.employee` is not defined in `hr.employee.public` and has to be
prefetched by the ORM.
Steps to reproduce (in 17+)
==================
0. install `hr_timesheet` and `pos_blackbox_be` modules.
1. create a user A with `hr_timesheet.group_hr_timesheet_approver`,
without any access to Employee app
2. create a project and a task without any company set (default value)
3. log in as user A
4. go to the form view of task created in step 2
5. add a timesheet and save the form view
Expected Behavior
=================
The timesheet should be added in the task and the form view should be
saved without any issue.
Actual Behavior
===============
A traceback is occured saying "The fields 'insz_or_bis_number' you try
to read is not available on the public employee profile"
opw-3769277
closesodoo/odoo#158111
X-original-commit: 6022e9fc7b8d58d88994c89cee1471475da4f011
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR contains a revamp of the digest email in the new "Milk" style replacing
the old purple with the new one. This has been adapted in all digest data too.
The images of the digest email's tips have been replaced by "milkified"
versions of them, already available on odoo cdn by the way.
Task-3338467
closesodoo/odoo#158351
Forward-port-of: odoo/odoo#157896
Forward-port-of: odoo/odoo#125432
Related: odoo/enterprise#58992
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: crm, digest, hr_expense, im_livechat, mrp, purchase, sale_management,
website
The images in the digest email are updated to have the look of the new
"Milk" Ui. We want to keep names unique, as they target different
versions. That way we can keep a v15 oriented gif for people using tips
in v15 for example.
The mobile phone image is hosted on odoo.com.
task-3338467
X-original-commit: odoo/odoo@3711d2b61b
Part-of: odoo/odoo#158351
The account move search was not enough specific to retreive only one
account move. The following `assert` sometimes failed because of this.
This commit reinforce to search to get only one account move
closesodoo/odoo#158327
Opw: runbot error 60338
X-original-commit: 78518f5dbf26680f678c6bbd950d60bb96eeedfe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This fixes an issue where access rules are checked on a new record: the
rule domains are evaluated with method filtered_domain(), and one rule
uses the operator 'child_of', which is implemented with a call to
search(). When used with a new record, filtered_domain() returns an
empty recordset instead of the record itself.
By design, the ORM doesn't check security on new records. A base
automation of type 'onchange' will run some server action on a new
record. The server action may still check access rights on the model,
but should not check access rules.
closesodoo/odoo#158309
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
In some edge cases the invoice date will differ from the accounting date. This commit makes sure that when this is the case the accounting date is shown on a posted invoice or credit note. This way it stays clear that the accounting date differs from the invoice date.
closesodoo/odoo#156315
Task: 3774329
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
- Create a request for quotation for a product with set vendor Taxes
- Create an alternative purchase order from that RFQ with Copy Product
Current Behavior:
The purchase order line of the PO associated with the created
alternative does not compute the taxes.
Expected behavior:
The taxes should be computed in the same way as if the PO was created
manually and then linked to the alternatives.
Cause of the issue:
When creating a PO manually, the taxes of each purchase order line
are computed when the product is set during the call of the
`onchange_product_id` onchange method:
https://github.com/odoo/odoo/blob/64c13193ae0fe23eb1b426f5bbcd8531e9a40967/addons/purchase/models/purchase.py#L1221https://github.com/odoo/odoo/blob/7ed0a773b6e0711b127f236ce665c35202d973bc/addons/purchase/models/purchase.py#L1055-L1061
By contrast, PO created from the `action_create_alternative`
generate each `purchase.order.line` using `Command.create`. Therefore
these lines will not trigger the onchange method and their taxes
will not be computed.
Fix:
To KISS, we compute the taxes of each line just after the creation of
the record using the `_compute_tax_id` method.
opw-3750719
closesodoo/odoo#158300
X-original-commit: 15799594bda41bdb4b65387aa5f0d46482cb91c1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here
task-3817495
closesodoo/odoo#158275
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
How to reproduce:
- install crm
- open a lead
- create an activity call or meeting (and schedule it in the calendar)
- mark it as done with a feedback
The activity log in the chatter contains the feedback twice and shouldn't.
The problem was caused by the synchronization of the event description with the
related activities. When marking an activity as done, the event description is
updated with the feedback which in turn update the activity note with the
feedback. When logging the activity done in the chatter, the note and the
feedback are logged leading to a duplicate feedback. We solve this by first
logging the activity done in the chatter before updating the event description.
Task-3653088
closesodoo/odoo#158268
X-original-commit: 0156204e465bc7f86643152cfff4d1aa33fd6935
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since commit [1], the new tiktok icon is added to odoo but the
conversion of the css class into an image is not supported.
This commit ensures that the conversion is correctly handled.
Steps to reproduce:
- Open the mail marketing app
- Create a new mass mailing
- Insert an icon in the template, for instance type /image in the text
and select the "Pictogram" tab
- Search for tiktok icon and insert it
- Send the mass mailing
- The icon will not be found in the mail
[1]: https://github.com/odoo/odoo/commit/515915b9closesodoo/odoo#158266
X-original-commit: 0fa2ce8212077facace67a0072aa4ddebc9b55f0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Issue addressed by this commit:
An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave.
How to reproduce the issue:
Install both hr_holidays and auth_signup modules.
Attempt to execute the _get_on_leave_ids method to identify users on leave.
Behaviour before this commit:
An "ambiguous column error" is raised due to the SQL query not specifying which state field to use, leading to confusion between the state fields in the hr_leave and res_users tables.
Expected behaviour:
The SQL query should clearly reference the state field from the hr_leave table, avoiding ambiguity and accurately identifying users on leave without errors.
Solution:
The SQL query within the _get_on_leave_ids method has been updated to use hr_leave.state = 'validate' for clear distinction, resolving the ambiguous column error.
opw-3770758
closesodoo/odoo#158261
X-original-commit: 0f6597e02c25993c85482febcbd000cfe3143d69
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
The push-to-talk extension service sends a message to the extension
when starting to check if it is enabled. If the response is received
before the RTC service is started, the answer is ignored, and the
service acts as if the extension were not available. This PR fixes
this issue.
closesodoo/odoo#158252
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PayPal refuses to take access_token name parameter and throws an error
to user that they need to log again. Since the Access Token is neeeded to
cancel transaction, it is renamed to return_access_tkn.
opw-3810686
closesodoo/odoo#158249
X-original-commit: e1ed847912b60bf09e13087963fad87afbed875c
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
* = facturx, ubl, ubl_bis3, ubl_cii
Problem
---------
Currently, the EDI use the commercial partner to craft the XML document.
However, this causes issues when users add, for example, an invoice
address to a partner. Indeed, the address of the main partner will be
used and not the invoice address. This caused issue; see the relevant
OPW-3624205.
Objective
---------
Make sure that the correct address is used when generating the XML.
Solution
---------
Make sure the commercial partner // partner value is used at the correct
spot.
- `partner` should be used for addresses
- `commercial_partner` for everything else.
OPW-3624205
task-3636315
closesodoo/odoo#158219
X-original-commit: 95d3a5ac16c341acc4b680f19e404a9f2334b582
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Steps to reproduce the bug:
- Install the "Blogs" app and go to the "/blog" page.
- Click on "Edit" to enter edit mode.
- Go to the "Theme" tab.
- Select the 4th color from the theme colors and choose "black".
- Save the page to exit edit mode.
- Perform a search in the search bar input that yields no results, for
example: "zzz".
- Bug: The message "No results found. Please try another search." is not
visible because it is displayed in white on the white background of the
dropdown.
A previous commit [1] had already addressed the issue for the "Search"
snippet that can be dropped into a page, but this fix wasn't sufficient
to solve the problem everywhere. Indeed, the text-muted in a dropdown
should be adjusted in all cases and not just for snippets; it's a
Bootstrap issue. The text-muted color should be adapted to the
background color of the dropdown.
[1]: https://github.com/odoo/odoo/commit/f9bf40cb53cf487c8736c1f565c2f0d3834acd5e
task-3662985
closesodoo/odoo#158203
X-original-commit: 46fcb3712f0ba68144b03ed23f52157d4dfc789a
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit:
The snippet menu in the Mail Body appeared on the top of the form,
causing misalignment.
Technical details:
- This problem was observed in the `view_mail_mass_mailing_form` form and all
other views inheriting from it.
- The fix involves adding the `o_mass_mailing_iframe` class using the
`iframeHtmlClass` attribute on the body_arch field.
After this commit:
The layout is now aligned.
Task-3603623
closesodoo/odoo#158201
X-original-commit: 5b1d901014294274548765216ca4693501649ee9
Signed-off-by: Vivek Pathak (vivp) <vivp@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This will fix the number of employees in the partner view and redirect to a kanban view of the employees.
The smart button on the partner view for the number of employees related to this partner now gives the correct number depending on the companies selected.
If multiple employees are related, the action shows a kanban view of those employees.
closesodoo/odoo#158146
Task: 3693173
X-original-commit: c1e979203ec82de2300ad2f8b10478e1504b1c7c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
stefanorigano (SRI)