**Current behavior:**
Creating a new company and trying to switch to the l10n_ee
accounting localization package will result in a validation
error, preventing the installation.
**Expected behavior:**
The package should be installed and automatically activated for
the active company.
**Steps to reproduce:**
0. Install the l10n_ee accounting module
1. Create a new company such that no fiscal localization
package is active by default, then switch to this new
company in the selection in the top right
2. In Accounting settings, select the Estonia fiscal
localization package and save (this causes the exception)
**Cause of the issue:**
Certain tax accounts in the module do not have their names
fully updated. They all were labeled as "0% ..." instead of
their true percentages like all other tax accounts.
**Fix:**
Update the names of the offending tax accounts so that they are
fully reflective of their true %.
opw-3683538
closesodoo/odoo#154169
X-original-commit: 33d880cc733b90903e2facd21c134dbdc2e58de1
Related: odoo/enterprise#56693
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Steps to reproduce:
1- Install Field Service module
2- Create new task and click on products smart button
3- Hover over a product and click on the dropdown menu
4- Click on edit in the dropdown menu
5- Get back to the products page and check the quantity for the product you edited
Current behavior before PR:
When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated.
Desired behavior after PR is merged:
This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity.
opw-3689864
closesodoo/odoo#153293
Related: odoo/enterprise#56161
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
If product has no_variant attributes with 2 values and the first value was deleted,
it is still returning it in the product configurator.
Filter the template's value ids to return only active variants
opw-3570604
closesodoo/odoo#154278
X-original-commit: df15b25e8e36fdfde7644fc183daf1da7d9485c1
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Signed-off-by: Lina Eweis (liew) <liew@odoo.com>
Commit [1] added a rule whose intention was to unify the way our editor
labels look: capitalized. However, this is not working as intended for
translations as some languages have different rules for capitalization.
In the future, we will rely solely on the labels being written with the
intended capitalization in the first place (which is currently not the
case for dozens of English labels). As a fix, we keep the auto CSS rule
for English languages only. Hopefully, the amount of translations made
by translators being better than their auto-capitalized versions is
greater than non-capitalized English labels translated by mistake
without the auto-capitalization.
Note: this is the way python fields work too, they are not displayed
auto-capitalized in the webclient, although we want them to be.
[1]: https://github.com/odoo/odoo/commit/5db73c12d3ed14239dc81f60eec6c21d0f65af26closesodoo/odoo#153732
X-original-commit: 453b1e86840d81ffeff4d182b161b0ea50a38486
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Correct/improve the view of the point of sale configuration
by hiding certain unnecessary parts for certain user groups.
closesodoo/odoo#154359
X-original-commit: 1a2009387756f5bf41ed3c7a3ec3a892a1e4336a
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
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>
Ethan Vincent