Make the set() of module sorted, aka a list.
We can be pretty sure that nobody relied on the order of this set before
since it was completely underterministic. Therefor this change should
not break anything and make the testing on runbot more consistant.
This is mainly following the issue with the sql-injection testing
failing randomly with the order of the modules.
closesodoo/odoo#154324
X-original-commit: bbe33a1260ab3bfe97caa1197adbf00c661ddfb4
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Since 4da8c6ebca, the lot creation when filling a stock move line is
done via the stock quant "pick from" field. We thus don't have the
'active_picking_id' key that was set on lot_id field to check if the
user can create or not new stock lot for a particular picking.
This commit add this context key back on the stock move line one2many
for it to be available at the stock quant creation.
closesodoo/odoo#152915
Task: 3670447
X-original-commit: ce4f6f668cf8308b4b9af14ffc74f0df6428a771
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
- set a leave type and an accrual plan based on hours
- create a new accrual allocation on those leave type and accrual
- change the date_from so that some hours are accrued
- set a custom amount
- save or validate
- the value should fall back on the initial amount
This fix should allow to keep the custom amount set by the user.
task-3615695
closesodoo/odoo#144306
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This commit follows [1], which attempted to fix CORS errors
occurring when we access the `cssRules` property of stylesheets,
to detect scss compilation errors and display a warning to the
user.
[1] doesn't seem to be enough, as we faced another source of CORS
errors. Indeed, in non-secure http, the error is raised even if the
origin is the same.
We never want this access to crash anyway, as it's a nice to have
feature, and if reading `cssRules` is forbidden, there's nothing
the user can do anyway. For those reasons, we decided to simply
protect the code with a try/catch.
[1] odoo/odoo#152696
opw 3746910
closesodoo/odoo#154347
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce issue:
1. Select a Contact
2. Click on Smart Button "Loyalty Cards"
3. Create a new Loyalty Coupon
4. Save
5. Receive an error:
> The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.
>
> Model: Loyalty Coupon (loyalty.card)
> Constraint: loyalty_card_program_id_fkey
Explanation:
The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the case of the issue, for example, the model is `res.partner`.
https://github.com/odoo/odoo/blob/a3201d636505dc1976d3f0ee7f8cbf65d2488966/addons/loyalty/models/loyalty_card.py#L27
Suggested fix:
The creation of `loyalty.card` from `res.partner` Smart Button is not intended, therefore we will remove this option and set the Smart Button as invisible if `loyalty_card_count` is null.
opw-3707588
closesodoo/odoo#154258
X-original-commit: 8645874ec0e7ae81f032231be4908e173d2a4043
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
This commit addresses an issue introduced after the Analytic
distributions changes in v17 where printing expense reports with
cross-analytic distribution raises a traceback.
Given that analytic distributions offer limited value on printed expense
reports and considering that no other printed reports in Odoo currently
display the analytic distribution, they have been removed.
task-3722135
closesodoo/odoo#153569
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Current behaviour before commit:
In v17.0 and above trying to open emoji-picker
throws traceback. This happens because not able
to find input element inside onPositioned method.
Desired behaviour after commit:
Now there is no traceback when opening emoji-picker.
task-3729610
closesodoo/odoo#153186
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode)
and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs').
'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10.
task-3626894
closesodoo/odoo#151314
Related: odoo/enterprise#55218
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit
===============
Global discount with Tax effect been developed in such a way that it calculates
discount based on tax groups and brings correct tax liabilities to comply.
Where in it drops lines with minus in invoice form, While doing E Invoice in
India - Government portal not entertain product with minus lines to reduce
liability.
After this commit
===============
Refactored invoice form for E-Invoice in India post-global discount
implementation. Adjusted discount sign to address the government portal's
restriction on negative lines. The fix ensures the portal now accepts discount
lines, aligning with regulatory requirements.
closesodoo/odoo#146163
Task: 3454674
Signed-off-by: Josse Colpaert <jco@odoo.com>
Ensure the country is set on the customer and supplier for Peppol Bis 3
to avoid errors like "[BR-11]-The Buyer postal address shall contain a
Buyer country code (BT-55). [BR-57]-Each Deliver to address (BG-15)
shall contain a Deliver to country code (BT-80). [BR-09]-The Seller
postal address (BG-5) shall contain a Seller country code (BT-40)."
closesodoo/odoo#154233
X-original-commit: 8a764c82816bf55d8bdf44a38b8b69998f6acb4b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be
prefixed with a 2 letters code representing the country of the partner.
Currently, filling a VAT without this country code will lead to the
error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax
representative VAT identifier (BT-63) and the Buyer VAT identifier
(BT-48) shall have a prefix in accordance with ISO code ISO 3166-1
alpha-2 by which the country of issue may be identified. Nevertheless,
Greece may use the prefix ‘EL’."
On the other hand, some extra-european countries use Peppol Bis 3 but do
not prepend their VAT with the country code (i.e. Australia). To allow
such cases, we automatically add the country code when it's missing.
To prevent regression, we also add a contraint mimicking the schematron:
we check that the final value of the PartyTaxScheme/CompanyID is
prefixed with a 2 letters code. This way, the constraint is independant
from the code.
X-original-commit: b1ab100046db4ee65bed482c1abbf951190f8921
Part-of: odoo/odoo#154233
The model `l10n_pl_tax_office` has a group to be able to access it.
The Many2one that refers to it, `l10n_pl_reports_tax_office_id`,
does not.
Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust
Linked to runbot error 24602, 24721
closesodoo/odoo#154294
X-original-commit: dba837afe72c9e8b3e3f8e9615ddb923227d3af0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer.
In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation:
- Create a new transfer for each date_deadline
- Merge the move with distinct date_deadline
Usually, it makes sense to not merge moves with distinct date_deadline, but it also makes sense to not create a new resupply transfer every day.
So for now, we treat this situation as a limitation, but we still provide a workaround:
By adding a system parameter, we give the possibility to the user to ignore the date_deadline when merging moves.
## HOW TO REPRODUCE:
- Create new Warehouse 'Warehouse 2' WH2
- Create Custom Route to resupply 'WH/Stock' from 'Transit' From 'WH2/stock' (see screenshot)
- Create product P1 (storable, with custom route selected)
- Create reordering rule on default warehouse, with min=1, max=1, route=custom route
- Create Sale Order for 10 units of P1, confirm => New Receipt from 'Transit' -> 'WH/Stock' generated
- Wait 1 day (alternative is to increment the Lead Time on the Stock Rules).
- Create Sale Order for 10 units of P1, confirm => Same Receipt used, 2 lines are present.
OPW-3633551
closesodoo/odoo#154276
X-original-commit: 8bed8f89cf2faf635f3148a747429241cbdfe460
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Before this commit:
- When coupen code template is selected and we drag text block then
text will not be visible because of bg color as the background color
and text color are same.
After this commit:
- Now in coupen code we can see text in text block.
task-3514347
closesodoo/odoo#154137
X-original-commit: 6cf35c7e192eacdffcec08b176325504e51b2aa2
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Issue:
------
On the calendar application, it is not possible to create a 15-minute event
directly from a selection using the mouse.
An event with a default duration of one hour is created.
Cause:
------
The fullcalendar library detects two events:
- a date selection
- a click
The date selection is correct, but the size of the "rectange" is the same
(15 minutes is the smallest unit in terms of size).
As a result, a click using a default time is detected.
Solution:
---------
We can use `preventDefault` to block the second event (the click)
because the event is the same.
Note:
-----
This fix is safer than patching the `FullCalendar` library
(which may change in future versions).
opw-3743945
closesodoo/odoo#154135
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Steps to reproduce:
- Calendar > create an all_day meeting with an additional attendee
- Save > Edit > change starting date to a later day > traceback
Cause of the issue:
The write call of the method _onchange_date is applied to a pseudo record.
However, the write method expects a record with an integer id to
correctly _send_mail_to_attendees down the line.
Fix:
Since we don't want to send_mail_to_attendees anyway, we skip this part
of the write method using the already existing contextual escape
'is_calendar_event_new'.
opw-3733753
closesodoo/odoo#154091
X-original-commit: f206781b3f4cababa4e69c8c9586f0f5406acc83
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Before this commit, `.bg-view` was set to `.o_notification`. This was
creating an issue in the front-end where `.bg-view` doesn't exist,
making the background of the notification transparent and ultimately
causing readability issues. Issue introduced in [1].
This commit changes the way we apply the background from a utility
class approach to a SCSS approach. That way, we can easily override
in `website.scss` with the `$body-color` of the website.
task-3716367
[1] 4e1f0b8ea522accae4860937c2fb3815281e8483
closesodoo/odoo#154081
X-original-commit: f8f8d2905db633cfaaa93b6cd163f4ab55dc4c8f
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
-------------------
1. Install sale_project with demo data
2. Create a user with no access rights other than Project/User
3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update
4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More'
This will give an access rights error.
The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leading to an access right error.
This commit adds two sudos to avoid that error.
closesodoo/odoo#154271
X-original-commit: 8750b94c53c6ab58567873b0745fa6d9a18c97d0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit
=============================================
Before if all the lines were of service the error was displayed in a banner
after error in response was received, but now before sending request the lines
are checked if at least one line is of product and error is raised.
Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2closesodoo/odoo#154290
X-original-commit: 831d318a2993e8c4ac92739bf3604ad04dec924f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Since 16.3, opening the web client on the Odoo backends results in two
subscribe events being sent through the bus websocket.
Discuss listens to the thread changes to know when the subscription
should be refreshed. In order to do so, the last subscription that was
made is kept. This issue is that this subscription is empty in the
first place so the first evaluation always considers the subscription
should be made.
In order to fix this issue, this PR refine the condition to determine
if the subscription should be renewed:
- The last subscription is different from the last one
- The user joined a channel after the bus initialization
- The user left a channel after the bus initialization
In order to test those scenario in a reliable way, this PR also
backports odoo#147455
closesodoo/odoo#154170
X-original-commit: 109b45f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Description:
When searching with a domain that contains a relational field whos
comodel is `res.users`, with a *pathological* domain of `not ilike`
`'some_string'`, the ORM will call a `_name_search` on `res.users`
with no limit to resolve the leaf when calling `_where_calc`.
The current implementation in the `web` module overrides the
`_name_search` to implement a spec to propose the current user as a
first suggestion, but to do that it first execute the query
(the list conversion), and then manipulates the list of ids to insert
the current user first. (1c2ce8c213)
On large databases with many `res.users`, where the condition matches all
users besides 1, this is a probably Seq.Scan on the `res_users`
table. Then this gigantic list of `ids` will be injected by the ORM
into the main query to satisfy the original domain. This incurs not
only bandwidth costs, but also usually leads to bad plans, ending up
most likely into a Seq.Scan on the original table.
The worse of it, in the case of a `web_search_read`, there is a
`search_count`, so this whole fiasco is repeated once more.
The nail in the coffin, is that the result isn't even needed, when
resolving a comodel's `_name_search`, we care about the subset, the
internal order is irrelevant.
Solution:
The ORM calls the `_name_search` without a limit, while in general the
`name_search` is called with a limit from the front-end, therefor we
can use it as a discriminant -> If no limit, don't suggest `uid` first.
Affected versions:
saas-16.3 -> master (saas-17.2)
Reference:
task-3610657
closesodoo/odoo#154149
X-original-commit: 83aa46a4ab88c0226b1aa1dc36671d3208a0835a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Prior to this commit, automatic printing was only functional when
a printer was configured with the Point of Sale. It did not support web
printing. This commit rectifies this issue, allowing automatic printing
to work seamlessly with or without a physical printer setup, supporting
web printing.
opw-3706400
closesodoo/odoo#154066
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Description:
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in
case of `auto_join=True`), which is inefficient, as the `id` can be
retrieved directly from the current `model` table, instead of going
to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule`
of the `comodel` is applied, which is not the case when directly
referencing the `field` from the `model`. So in some cases using an
explicit `.id` would be a wanted, if the intention was to apply the
`ir.rule`.
Fix:
Remove the `.id` from left leafs of domains that if the field is
stored, and the `comodel` doesn't have `ir.rule` associated with it,
or the `ir.rule` application is redundant/not needed.
task-3735923
closesodoo/odoo#153464
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Current behavior:
When you make an order in the PoS with different lots for the same
product, the lots are not correctly selected in the picking. And only
one lot is affected by the order.
Steps to reproduce:
- Create a product with tracking by lot, and 2 lots with some quantity
- Create a PoS order with 2 lines of the same product, and select a
different lot for each line
- Validate the order
- Close the PoS session
- Check the picking, and the lot quantities
Note:
This partly revert this part of commit :
https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-0ef4eb66998f308afe5f09748bc2af04ad79e9647507c25fe9007e03a79a1249L265-L303
And also make sure that the original created line quantity is set to 0
so that the each lot has a line, and the total quantity is correct.
opw-3621363
closesodoo/odoo#148517
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
1. Make sure to return archived users in partner format.
2. Remove the condition to check for archived users in suggestion code.
The condition made no sense since the refactoring (that's the opposite
of what we want, and it didn't compare the partner records correctly).
The feature is broken since https://github.com/odoo/odoo/pull/133065/
because it "fixed" the way records are compared. Making the condition we
don't want in the first place actually working and excluding OdooBot
(instead of allowing it).
3. Since archived partners are displayed anyway since the refactoring,
and nobody complained, let's consider it a wanted feature.
Archived partners are given lowest priority and moved to the bottom.
task-3747277
closesodoo/odoo#154078
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Open any course.
- Open full-screen window.
- Click on exit fullscreen
- The progress bar color is mixed up with the background.
Issue:
In Odoo primary color is changed from v17.0
Solution:
Applied bg-info class to progress bar for better visibility.
Task-3721175
closesodoo/odoo#152815
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the current system, the order widget experienced undesired updates to all order lines when a new product with the same attribute was added. Our recent changes address this issue, ensuring that existing attribute values remain unaffected by the addition of new ones.
Moreover, we've refined the display of attribute information. If an attribute is designated as "never," it will now be incorporated into the order line note. Conversely, attributes with different settings will continue to be displayed in their usual format.
closesodoo/odoo#152213
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit:
-On inserting icon in note, it replaces another icon.It occurs because
`isEmpty(block)` returns true, when block element was font-awesome, which
causes the code in `insert` method to remove current node, resulting in removal
of previous icon.
After this commit:
-Now icon is added without replacing the another icon.
task-3482264
closesodoo/odoo#152929
X-original-commit: 9a9487752131fddaf9ff163cb22226b256cef81d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Currently an empty section is not considered empty text.
As the web editor sometimes uses them, it is relevant to consider
them when asking whether some html will appear empty.
Currently, even completely removing the website description of an
exhibitor in website_event_exhibitor from the backend does not make
the 'missing description' tooltip appear in the front-end
task-3607615
closesodoo/odoo#154097
X-original-commit: 7dc376d4d2d2b4000de0da7573c30e4508f32318
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Steps to reproduce
------------------
* install `l10n_ch_reports`
* switch to a Swiss company
* enable "QR Codes" in Settings > Accounting > Customer Payments
* create and confirm two invoices for a Swiss partner
* on the invoice list view, select and attempt to print the two invoices
at once
You should be met with traceback.
opw-3697569
closesodoo/odoo#154063
X-original-commit: b6cb6b3ecd80d8c919790cc3178dfcb62f6f49fb
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
**Issue Description**:
From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately.
**Steps to Reproduce**:
1. Open `Project` app.
2. Enter any project, then navigate to any task.
3. Within the task, go to `sub-task` tab.
4. At the top center of the page, click on 'Sub-task' smart button.
5. Then, create a new sub-task using the 'New' button.
6. You will observe that the sub-task is immediately assigned to a project, which should not happen.
**Proposed Solution**:
By removing the passing of the default_project_id variable from the context when open a sub-task action, we ensure that sub-tasks are not automatically assigned to a project, as intended.
opw-3708537
closesodoo/odoo#154101
X-original-commit: c45ac4c9584f961ea0cdedffdf2b4bbe9058e8d9
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Ilya Rudy (ilru) <ilru@odoo.com>
Steps to reproduce:
1- Install Members module while Accounting is uninstalled
Current behavior before PR:
When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module 'group_account_user'. This issue happened after this commit https://github.com/odoo/odoo/commit/f6c60e497520d7916937f4a2a57ed3f8c2e1049b#diff-65a587634b23c60ecc8eea20881920a50eddbc569aa5d0381705b7405e918e2e
Desired behavior after PR is merged:
Now the Members module has the access right group of Invoicing module 'group_account_invoice' which is the only dependency module that Members need. So it will be visible and accessible from the dashboard once installed
opw-3627010
closesodoo/odoo#154070
X-original-commit: d0bd175e10f72649bcd310d6d5b068dc6bfd2b5f
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
When installing the Odoo Debian package on Bookworm, under certain
conditions, the following bug may arise:
`Warn: Can't find .pfb for face 'Times-Roman'`
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059326
As this bug is not yet fixed on the Debian side, this commit is a
workaround.
closesodoo/odoo#154017
X-original-commit: 70e192137e9b603c502aea878313cd7611fe0337
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
- Install `event_crm` module
- Create an Event with a company
- Go to `Events > Configuration > Event Lead Rules`
- Create a new rule and set no company
- Try to set the event created above for Event field
Issue:
Event created not displayed as possible value for the Event field.
Cause:
Because we have `check_company=True` set on `event_id` field, the
field will be filtered based on the `company_id` field, and since no
company is set on the rule, events with company will not be listed.
Commit that introduced the issue: https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed
Solution:
Revert to the previous behavior (remove `check_company=True` from
`event_id` field and use a domain instead).
opw-3715864
closesodoo/odoo#154009
X-original-commit: 13cb20dafb6dd473fe71b605a2adf70fa0ac368e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Switch to a language where removal strategy name is translated
(FR in 17.0)
- Edit product category and set a translated removal strategy
- Update on hand quantity
Bug:
User error removal strategy not implemented
the removal strategy name is used in the code to identify them
when changing the name through translation it is not recognized anymore
Fix:
use the untranslated term when checking the strategy type
opw-3697462
closesodoo/odoo#153970
X-original-commit: 210f0d1c56dab45b2a00f86e1c7d836f558e6feb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Desired behavior after PR is merged:
Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search.
opw-3713519
closesodoo/odoo#153682
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Since PR #137969, the `save` button is no longer available in schedule activity
wizard.
This PR makes `schedule` button available for call activities like other
activities (except meeting), so user can create a call activity without going to
calendar view.
Also, we have to consider `has_error` in creating activity so if there is an
error, user couldn't access to `schedule` button. This field is correctly placed
in `mail.mail_activity_schedule_view_form` view but not in the inherited view
in `calendar`.
task-3668732
closesodoo/odoo#152893
Signed-off-by: Maryam Kia (maki) <maki@odoo.com>
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to
"Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and
thus are skipped inside `computeReportMeasures` unless they are passed
in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is
passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure.
This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
closesodoo/odoo#153967
X-original-commit: 76178cd61ba10ff29b24183edb550c54b319a230
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This fixes a bug where trying to set the default name value
of an expense report when created from the expense tree view
would traceback.
Step to reproduce:
- Create 2+ new expenses having the same payment_mode
(E.G. 'own_account')
- Clear the date field of an expense so at least one of the expense
has a date and one has no date
- Press the 'Create Report' button on the expense tree view
Current behaviour:
Traceback due to bool > Date comparison
Expected behaviour:
We fallback to a default name when two sheets are created.
We do not set a name when only one shert is created.
task-3725176
closesodoo/odoo#153943
X-original-commit: ddb3b825a7bec28975052f858ea1512a7cf16f08
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Steps to reproduce the bugs:
- Install the e-commerce on your website.
- Go to the "/shop" page.
- Click on "Edit" to enter edit mode.
- Click on the "Customize" tab.
- Choose "Cards" for the "Style" option.
- Enable the "Product Description" toggle.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to exit edit mode.
- Bug 1: The product description and the price in the product cards are
not visible.
- Bug 2: The scrollbar below the category buttons has the same color as
its background.
- Click on the "Mobile Preview" button in the backend navbar.
- Click on the "Filters" button on the page to show the offcanvas.
- Bug 3: The text color in the offcanvas is not visible and the
background color of the inputs is the "body" background color instead of
the "offcanvas" background color.
opw-3570774
closesodoo/odoo#153930
X-original-commit: add2b9273e90e3940ee52eee4ff42afa46c18a20
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_sale
Steps to reproduce the first bug (popover):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Click on the "Add to cart" button.
- Hover over the cart in the navbar to make the popover appear.
- Bug: All the popover texts are not visible because they are white and
the background is white.
Steps to reproduce the second bug (extra price badge):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Bug: The text of the "extra price" badge is not visible because both
text and background are white.
These two issues existed because the text color of those elements
depended on the body's background color. With this commit, the text
color for those elements is now determined by their respective
backgrounds.
This commit is a follow-up to this commit [1]. We also add the handling
of the text-muted color to ensure it remains visible if a modal has a
dark background while the body background color is light. Before this
commit, we only handled the opposite case (dark body and light modal).
This commit also fixes the text color of the button in a file input of a
form when the background color of the <body> is dark. Similar to the
other elements fixed in this commit, the text color of this button could
be invisible because it was the same color as its background.
[1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7
opw-3570774
X-original-commit: 0c2806576e85106d06f4275c9204e664f69793d8
Part-of: odoo/odoo#153930
flvr-odoo