Steps to reproduce the bug:
Create 2 product (Finish product , RM product)
Create 1 Kit BOM for Finish product with 1 Component(RM Product) and quantity : 0.0860
Create SO for 10 Finish product and confirm SO
Deliver RM product : Quantity : 0.86 ( as per define ratio in BOM) -> validate
Bug:
Delivery quantity on SO line shows : 9 instead of 10
opw:2540671
closesodoo/odoo#72724
X-original-commit: 89aa85f32e0a87d537f4d9ed9c22955d3269ddd1
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Prior to this commit, the account move line was not correctly joined,
and put in relation with SOL. Furthermore, this table isn't use.
In this commit we correctly join the subquery, in this subquery,
we just try to avoid to take into account amounts that are related
to invoiced sale order lines.
closesodoo/odoo#72710
X-original-commit: b04465d3514fe5cd52b7994962fe4069933ae6fd
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Usecase to reproduce:
- Setup a maximal of 100units in a storage category
- Set the storage category on shelf1 and shelf2
- Create two putaway rule from wh/stock to wh/stock/shelf1 and
wh/stock/shelf2
- Create an immediate receipt
- Set 100 units of product on stock move line (should suggest shelf1)
- Put in pack
- Create a new stock.move.line in the receipt.
It will suggest the same location than in the first line despite the
location is the same. It happens because the check look only at quantity
reserved in the location but the user could have create new line without
quantity reserved.
This commit, take the maximum between the quantity reserved and the
quantity done to give an estimation of what could happens.
closesodoo/odoo#72689
X-original-commit: d9d98d4264295532f2248c6072aabbd72f32f054
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The selection of cards corresponding to already installed modules
is disabled. A disabled style has been applied to these cards and an
info icon added. On hover on this icon the user is informed that the
module is already installed on its DB.
- Modules that were preselected based on website type can now be
unselected by the user.
- Correct typo in description of feature_module_career.
task-2518565
closesodoo/odoo#72688
X-original-commit: ab364b06dbb20cce90c7caa8ca15d034e2dcb25e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Have something like:
```js
sprintf("my string %s", _lt("lazy translated"));
```
Before this commit, the lazy translated term was not formatted into the string.
This was because _lt returns an object containing a custom toString function, which was not handled by sprintf
After this commit, sprintf is able to handle lazy translated strings
closesodoo/odoo#72598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, "lazy translated" strings were implemented as
objects with a toString function. This is simple, but does not emulate
very well the real behaviour of a string.
In this commit, we create a LazyTranslatedSTring class which subclass
the String class, so all string methods will work as expected.
We also expose the _t function here, to make it more convenient for some
code to access the translations instead of depending on the presence of
an environment.
Purpose of the commit is to improve the usability and onboarding
of the project app.
So in this commit, done the below changes:
- Rename column "Kanban state" in list view screens
- Hide column "analytic account" when not needed
- Do not show "Internal" project
PS: Moved leave_timesheet_project_id into hr_timesheet and rename
it as internal_project_id and we used it in the domain in the
kanban/action to the kanban in order not to have it in the result.
closesodoo/odoo#68857
Taskid: 2451722
Related: odoo/upgrade#2479
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, for the db with old active tasks and many
projects and tasks. The report takes several hours to execute the sql view.
Because we take the create date of the oldest task as the begin date
of each generate_series to calculate the different group bys (day, week,
month, quarter and year) until CURRENT_DATE.
This commit hugely improves the performance of the sql view execution
for the burndown chart report.
closesodoo/odoo#72664
X-original-commit: 89726a22862cf14f7b88e130fb79ddc74bffff5e
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Nicolas Seinlet (NSE) <nse@openerp.com>
Co-authored-by: Thibault Libioulle (TLE) <tle@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
The amount of cash present in the POS may be incorrect
To reproduce the error:
1. In POS settings, enable "Advanced Cash Control"
2. Start a POS session
3. Make an order of 70$, payment in cash
4. Close the POS session (correctly set the closing cash)
5. Start a POS session, close it (correctly set the closing cash)
Error: Back to kanban view, the information about the POS are incorrect:
the cash balance is equal to zero, it should be $70
The value of the cash balance is computed in `_compute_last_session`:
https://github.com/odoo/odoo/blob/5ea1d31df9041ca7b25fbea6178e798e62bebca0/addons/point_of_sale/models/pos_config.py#L276-L291
This method gets the last session and extracts the information. However,
in the above case, there were no sales during the last session (step 5).
In such situation, the bank statement of cash is deleted. As a result,
in `_compute_last_session`, `last_session_closing_cashbox` will be
defined to `False`. This is the reason why the cash balance will be
equal to 0
The deletion of `cash_register` has been introduced in case the user
closes a session that does not contain any SO. This fix suggests keeping
such a bank statement and automatically posting it.
Linked to OPW-2507394
closesodoo/odoo#72663
X-original-commit: dae9ba62d98d4238600ccd637dd5e879f1cac903
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Since odoo/odoo@1971bf3 the customised dropdown in the pivot view (the one that opens its submenus horizontally) cannot open at all its submenus.
As the correct behaviour cannot be restored without reintroducing the +300 scss lines that has been removed, this commit applies a temporary fix that *changes* the design of this dropdown. Now, its submenus will open vertically, like for the groupby menu near the search bar.
The final dropdowns design is currently ongoing within the taskid: 2578926
closesodoo/odoo#72640
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
This could save some time when `_compute_quantity` is used thousands times in
request and there are thousands UOMs in the system
* if qty is zero, then result is zero
* if to_unit is the same, then result is `round((qty / factor) * factor) = round(qty)`
---
opw-2549026
closesodoo/odoo#72582
X-original-commit: a122db226cdf801675daaee5a69bcb47a47ab174
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When consulting a delivery slip, a portal user won't see the lots/serial
numbers used.
To reproduce the error:
(Need demo data)
1. Create a product P
- Product Type: Storable
- Tracking: By Lots
2. Update its quantity
3. In Settings, enable "Display Lots & Serial Numbers on Delivery Slips"
4. Create + Validate a SO:
- Customer: Joel Willis
- Lines: 1 x P
5. Validate the delivery
6. Log in DB with 'portal' (Joel Willis)
7. On SO, open the Delivery Slip
Error: The product's lot is not mentioned
Here is the condition to display the lot:
https://github.com/odoo/odoo/blob/c61db20204700a375f7005f50f95b44a60c3bb70/addons/stock/report/report_deliveryslip.xml#L77-L79
Problem is that portal users are not part of
`group_lot_on_delivery_slip`
When enabling the option, the groups are updated here
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L570-L576
`implied_group` (which is `stock.group_lot_on_delivery_slip` in our
case) is added to `groups.implied_group`
The variable `groups` comes from `classified`, which is defined thanks
to method `_get_classified_fields` (see L553 in above code block)
And here is an extract of how this method works:
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L460-L462
At some point, it checks if the field `group_lot_on_delivery_slip` has
an attribute `group`. In case `group` is not defined, the group
`base.group_user` is used. This is the reason why, by default, the
option is enabled for internal users only instead of all users.
Therefore, we just need to define the attribute `group` to the field
`group_lot_on_delivery_slip`
OPW-2558761
closesodoo/odoo#72656
X-original-commit: 475b35397b7254012a082a1206c478084c069857
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, the template of some dynamic classes (usually as WOWL to legacyAdapters)
were registered at each definition of the class which is potentially at every doAction/switchView
After this commit, they are all registered only once, as early as possible.
closesodoo/odoo#72476
Related: odoo/enterprise#19199
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, when clicking on menus or debug items or use menu items
the URL briefly changed pushing an unwanted history entry.
We do want those to be links (tag `a`) with an href to be able to open in a new tab.
But we don't want the current url hash to change because of it.
This commit fixes this.
on a legacy form view, do an action in target new
The view in target new should, during its onchange, trigger a ValidationError
Before this commit, the dialog_container was stuck in an error loop.
This was because the received error was never an instance of Error, rather it was
a legacy error event. So it was never transmitted upstream were the ErrorHandler could remove
the dialog in error from is dialog array.
After this commit, the ValidationError mesage is displayed.
This commit additionally fixes another issue:
An action in target main that failed to render erased the whole DOM. This is not what we want,
at least for now. Imagine a list view, open a record, this record fails to load. We still want to be
on the list view, not in a blank state.
Before this commit, the error service bound its listeners onto window.
This may create pollution when executing more than one test instanciating an error_service
After this commit, we bind the handlers onto browser, which is fully in our control in tests.
Open a action in target new that you'll know will fail to open.
Make sure you put an onClose callback when executing doAction.
Open another action in target new, that will succeed.
Before this commit, the onClose of the first dialog is executed, while it should not.
Indeed, if the dialog fails, the whole business flow is invalid altogether
and no more business operation (in the onClose) should be executed
After this commit, the onClose callback of the failing dialog is not executed.
Steps to reproduce the bug:
- Go to website app > configuration
- Set the visibility of all the blog to Website A (So that it's not visible on Website B)
- Go to the Blog menu of Website B
- A traceback is triggered
Problem:
The `all_tags` function calls an SQL query to get the tags related to the website blog
with a where condition based on the blog_id. But since there is no blog linked to the site.
The request fails and an error is raised.
Solution:
Do not load the tags, if there is no blog for the website.
Opw-2545315
closesodoo/odoo#72636
X-original-commit: 4d8fc86e4e6beb2171e3bebbabd532086d884d59
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
closesodoo/odoo#72548
X-original-commit: bfa7c9e78037cd0abda3e8f0a9a519a600988e9c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The company is needed in the context to get the paper format for
instance because of `get_paperformat`
X-original-commit: a1526eb4e5b1eb7cada603d7fcee7bb77c64bbac
Steps to reproduce the bug:
- Go to settings > create a new company :
- Choose the country : `Mexico`
- fill in the VAT field : ESA2005273X1
- save
- Validation error is triggered
Problem:
The Mexican VAT can be on the format: "MXESA2005273X1" or "ESA2005273X1".
But only the "MX .." format is accepted for the moment,
and it fails in the case of "ES.." because the function checks if it is a valid Espganol VAT number.
In the case of failure, we use the `partner.commercial_partner_id.country_id` to get the country code.
The problem is when creating the res.company, we also create a res.partner
with a few fields within `VAT` except `country_id` field
while we use it in the `check_vat` function : https://github.com/odoo/odoo/blob/7a7aacedde81998ec0f1a7f3283337236e56de42/addons/base_vat/models/res_partner.py#L167
Opw-2573557
closesodoo/odoo#72633
X-original-commit: a6a46c95e4947997892b21f407132574da1c7ff1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Add mapping rules to enable the electronic invoicing of document types
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" (60) and
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO B" (61).
closesodoo/odoo#72619
X-original-commit: 9fb221459e1137c0622c14a57ec408b3b5f65fe6
Signed-off-by: William André (wan) <wan@odoo.com>
The purpose of this task is there are several places where the
duration is expressed in hours even though the encoding unit
is in Days. This creates inconsistencies.
In this commit, we convert hours into days when the encoding
unit is in Days. Also, we changed the string of the fields
according to the encoding unit.
closesodoo/odoo#70512
Task-id: 2512950
Related: odoo/enterprise#18197
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, a traceback would occurs in sale_management calendar view when the user would try to display the popover of a sale_order.
```js
basic_model.js:2399 Uncaught (in promise) Error: for modifier "readonly": Unknown field state in domain
at Class._evalModifiers (basic_model.js:2399)
at calendar_popover.js:203
at Function._.each._.forEach (underscore.js:145)
at calendar_popover.js:180
at async Promise.all (index 1)
_evalModifiers @ basic_model.js:2399
(anonymous) @ calendar_popover.js:203
_.each._.forEach @ underscore.js:145
(anonymous) @ calendar_popover.js:180
Promise.then (async)
_renderEventPopover @ calendar_renderer.js:861
eventClick @ calendar_renderer.js:416
Calendar.publiclyTrigger @ main.js:6981
EventClicking._this.handleSegClick @ main.js:6462
realHandler @ main.js:385
```
It would happen because the domain of the partner_id is ["state", "not in", ['draft', 'sent']] but the state field is invisible="1" in the view.
state was absent during of the evalContext in the _evalModifiers function.
closesodoo/odoo#72617
Taskid: 2524993
X-original-commit: 0d636c0f8dbcfb4b7adda26c0edc02a12b0c7e44
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
When buying a product on website shop, after the payment with SIPS, the
page is redirected to an Error message: "We are not able to find your
payment, but don't worry. You should receive an email confirming your
payment in a few minutes. If the payment hasn't been confirmed you can
contact us."
To reproduce the error:
1. In Payment Acquirers, enable Sips
2. Go on website shop
3. Add a product to the cart, Checkout
4. Pay with Sips
- Visa card number: 4100000000000000
5. Back to Web-shop, if the payment has been successfully processed,
repeat steps 2 -> 4
Error: The message "Your payment has been successfully processed. Thank
you!" is not displayed. Instead, the message "We are not able [...] you
can contact us." is displayed.
This message is displayed when:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L65-L69
i.e., when the transactions list is empty. Here is how to get the list:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L38-L42
It uses the session of the request. The cookie `session_id` is used to
identify the current session. However, after the payment on SIPS, the
page is redirected to `/payment/sips/dpn` with a POST request. Since the
session cookie has the attribute `SameSite=Lax` and the HTTP request is
a POST, the cookie will be filtered out:
https://drive.google.com/file/d/1xfx3YWkfonO3nK-8Rew45uSoR4lkpjpY/view?usp=sharing
(Browser information: This cookie didn't specify a "SameSite" attribute
when it was stored and was defaulted to "SameSite=Lax," and was blocked
because the request was made from a different site and was not initiated
by a top-level navigation. The cookie had to have been set with
"SameSite=None" to enable cross-site usage)
As a result, the server creates a new one. This is the reason why the
transactions list is empty: the list is based on a new session.
Adding the attribute `save_session = False` to the route will prevent
the server from creating a new session cookie and add it in the POST
response.
OPW-2518377
closesodoo/odoo#72611
X-original-commit: 9637a287923c6b82acfd487ed32d6bbc1fdf74b6
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, the clickEverywhere test was run for the demo
user on all apps available for the admin. It thus crashed on the
apps that aren't available for the demo user.
closesodoo/odoo#72430
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, when we wanted to select first level menus
inside an app (i.e. menus available in the navbar), we could by
mistake select sub-menus if the dropdown was opened (e.g. if it
was previously tested). For instance, it happened in the 'Apps'
app. It then led to wrong index computation, and a traceback. As
a consequence, the nightly build failed as the clickEverywhere test
didn't pass.
Steps to reproduce :
- Install `CRM` and `Sales` modules
- Go to Settings, activate "External Email Servers" and
set an alias.
- Edit 'Sales Team Europe' : add an alias
(ensure alias end with the "External Email Servers" alias)
- Send a mail to the europe sale team alias email with a
base64 image in the html body
ex: <img alt="" src="data:image/png;base64,ABCDE123....789">
Issue :
- Traceback is raised.
("ValueError: Wrong value for ir.attachment.type: 'opportunity'.")
Cause :
Both `crm.lead` and `ir.attachment` have a `type` field.
When creating the thread, in this case of crm.lead model,
it will add the 'default_type' and 'default_team_id' to the
context.
The context will be inhrited and used on the creation of the
ir.attachment (in this case its the base64 encoded image
inside the body).
Since no `type` was provided while creating the ir.attachment,
it will set the type from `default_type` in context since
available.
Solution :
- Clean the context (in this case, it will remove `default_X` values)
when creating the ir.attachment .
opw-2551461
closesodoo/odoo#72613
X-original-commit: 4504c9d8069082c9542226fbafdbf309089cf7a9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the "Edit View" debug item only worked for
kanban, list and form views. For the other views, it opened a
blank form view. The reason is that for the other views, it didn't
correctly get the id of the view to edit.
Bug reported in the wowl-bugs pad
closesodoo/odoo#72523
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case.
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo#70645
ENT PR odoo/enterprise#18266closesodoo/odoo#70645
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Purpose is to avoid loosing frequencies and also avoid rebuilding the whole
frequency table. We choose to merge frequencies from team about to be unlinked
with "no team" frequencies.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case
LINKS
Task ID-2507750
COM PR odoo#70645
Fix a small glitch where archived ribbon is a bit bigger than its kanban
card, leading to a suboptimal display.
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
For the unit price (field l10n_latam_price_unit), we need the number
rounded based on the product price precision.
To compute it we use the method compute_all that rounds using the
currency accuracy, so to fix this we multiply and divide for
10^(decimal accuracy of product price) to get the price correctly rounded.
Steps to replicate the error:
1) In a base with l10n_ar localization installed change the decimal
accuracy of "Product Price" to 5 digits (keeping the currency
precision in two digits).
2) Create an invoice with a product with price $10.12345
3) Print the invoice and check the column price unit.
Before this commit, the price unit would be $10.12000.
closesodoo/odoo#72579
X-original-commit: 17e19c6bf787fd2bf77476ffcfa1d934058aa7ec
Signed-off-by: William André (wan) <wan@odoo.com>
Warn the user in case of unfilled or invalid google map API key.
task-2427575
closesodoo/odoo#72580
X-original-commit: f338d52e110bd6fa557169d370976ee35f5b56a5
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
As it is possible to hard-code the DirectLink URLs used by Odoo in the
backend of Ogone, some users might encounter payment issues after
migrating to 14.3+ if they did not replace those URLs by the new ones.
This commit adds back the URLs that were used by DirectLink prior to
14.3 and allows requests to target both the new and the old URLs.
task-2494916
closesodoo/odoo#72566
X-original-commit: 16ee2651ba7f537e3644da2fd80595896e3421fc
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Co-authored-by: Toufik Ben Jaa <tbe@odoo.com>
Before this commit, rainbowman message was displayed using
`t-raw` in template.
Now, the message is escaped by default and needs to be marked as
HTML to be displayed as well.
closesodoo/odoo#72392
Task-id: 2575435
Related: odoo/enterprise#19121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, the spaces in the template were transformed into
non-breaking spaces by the html editor while editing the html field
content.
The unordered list with icons as list item also failed to be compatible
with the editor.
With this commit, we remove the indents in the templates to prevent this
behavior.
It now also uses the css class defined by the editor to generate the check
lists.
closesodoo/odoo#72571
X-original-commit: ce9c39125da9ebe3e19dbb325fc4488a8b689ad1
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
It seems some terms are no translatable so purpose of the task is
to find those terms ans update to make them translatable.
So in this commit, translate the text attribute when the node is field
tag and this node contains widget='url' in its attributes. and
also make the project name as translatable.
closesodoo/odoo#71406
Taskid: 2487710
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: xavierbol <xbo@odoo.com>
In order to also match ir_http.py and qweb files inside auth modules,
the generic rules for those now also notify rd-security.
closesodoo/odoo#72537
X-original-commit: cf50e37992381d0db8ff886900e154d3f57eadd8
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Introduced with 7fb016f9966b
[0] access could crash, recordset could be empty after `filtered`.
Step to reproduce:
- Add admin group to website top level menu (Website > Debug > Menu)
- Try to access frontend as non admin
opw-2573763
task-2574346
closesodoo/odoo#72535
X-original-commit: 759d920d799d332220d86467d83aeb9334b61ce2
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Goffin Simon