Purpose
=======
Fix the traceback which was appearing when toggling
as done the content in the course template.
Specification
=============
The traceback happened because when all the content in the
section has been completed, we want to collapse the next section
automatically. However in this view the sections aren't
collapsable which resulted in calling methods on null HTML elements.
Fixing this by checking if HTML elements exists before trying to
collapse the next section.
Task-3449558
closesodoo/odoo#130633
X-original-commit: 51f82b306ed12dc2c8e32d2a0bd3052f8eed5d2a
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
When finishing (and succeeding) a certification in the e-learning module, you
can 'share' the content of the course by email.
But the "Send Email" button is unresponsive.
This is caused by having nested `<form>` tags: the one of the share modal is
inside the main survey form element.
To resolve this issue, we turn the `<form>` tag into a `<div>` tag in the
sharing template, as it does not need to be a form since it's never submitted.
Indeed, the sharing request is sent through attaching an event handler on the
"Send Email" button which still works fine after our tag replacement.
Note that this fix requires updating the module, but there is no (easy) way to
fix it otherwise, and we consider it acceptable as the impact is pretty low.
In addition to that, we also need to add a survey form JS override to correctly
attach the "ShareMail" widget when the screen is loaded to the "finished" page.
Indeed, as the survey form loads and replaces its content in AJAX rather than
fully reloading the page, we need to watch for the screen refresh and then
manually attach the widget so that the button handler is functional.
During FW to 16.4, we also fixed a small oversight of:
odoo/odoo@e0257347a7
Where we did not correctly add the "email_sharing" parameter when sharing the
certification content in the success screen.
Task-3360175
closesodoo/odoo#130613
X-original-commit: 337762b864d7b06abd7d1622083c5f00d7c7e7f7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The function `get_adyen_endpoints` was renamed to `_get_adyen_endpoints`
It was a typo in the method name, so it was not called and a traceback
was raised.
closesodoo/odoo#130591
X-original-commit: 0c3e1abdeb66805b79e07218c5d5dde89baeb25d
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: David Monnom (moda) <moda@odoo.com>
before this commit crm.iap.lead.seniority model is defined
twice inside the crm_iap_mine module.
after this commit, the duplicated model defintion will
be removed from the module
closesodoo/odoo#130620
X-original-commit: 3712256a298a79786f7bbff9a608dcdcc224ce44
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
**Sum of timesheets time different than what the timer displays**
Steps to reproduce:
1. Start a workorder timesheet, then stop it
2. Repeat the process multiple times.
Current behavior:
The error is based on a microsecond precision so you could need
to try multiple times before reaching the problem.
- The time displayed on the timer widget does not display the same as
the sum in the timesheet list.
- The difference between the start date and end date of a timesheet
is not always equal to its duration.
Expected behavior:
- The sum of duration should be the same as the one displayed on the
timer widget.
- The difference between the start and end date of a timesheet
should be equal to it's duration.
The computation of the duration of a timesheet will take microseconds
into account. It's not useful in the timsheets to save microseconds
as the precision is too high and as the user cannot change it manually
anyway.
Removing this precision (i.e. setting microseconds to 0) solve this
problem as it does not trigger rounding errors in a single timesheet
and thus in the total computation of duration of a workorder.
Also, there was a precision rounding error on the timer widget.
Time is saved as minutes in db, and displayed as seconds.
So 2s is 1/30 of min => 0,0333... min.
As multiplying this by 60 will return 1,99999 and as the timer was flooring the result,
there was some difference between the time recorded and the value displayed in the
widget.
enterprise : https://github.com/odoo/enterprise/pull/41727
opw-3241156
closesodoo/odoo#130618
X-original-commit: 0172395fa60c94150609bbbfe174d5eee44525fe
Related: odoo/enterprise#45109
Signed-off-by: Tiffany Chang <tic@odoo.com>
*: sale_product_configurator
Enterprise PR: odoo/enterprise#42551
Steps to reproduce:
1. Install website_sale
2. Create product P
- Go to Attributes & Variants tab
- Add a line
- Create and edit attribute "PILL"
- Display Type = Pills
- Add some attribute values
- Save & Close
- Add the attribute values in the list view
- Save the product
3. Go to website product page
Issue:
The pills have a visible radio button inside, requiring users to click
on the radio button to change the variant. In V15, there was no radio
button, and users could click anywhere on the variant container to
change the variant.
The change in behaviour happened because the jquery code for handling
button clicks has changed. In V15 jquery, clicking a button would
trigger a change event, which would then be captured by the owl event
selector `change [data-attribute_exclusions]`, and the
`onChangeVariant` method was called.
In version 16, jQuery no longer triggers a change event when clicking
a button.
Solution:
Hide the radio input visually, then convert the variant text to a
label. When clicking on the label, the corresponding radio input
is checked.
This means that the whole button is not clickable anymore, only the
text.
opw-3185147
closesodoo/odoo#130615
X-original-commit: dc7af6a4c555740b2c2b13efe57cd971e14dc67f
Related: odoo/enterprise#45103
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
When downloading images from Google, we check the headers of the request
to see if "image/" is defined in `Content-Type`. On some websites,
`Content-Type` is not defined, leading to a traceback because we try to
access the key in the dictionary.
opw-3349774
closesodoo/odoo#130612
X-original-commit: f6ecbbf7f72c61623a1f92571536289ffd6231b3
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Steps to reproduce:
- Install product_expiry
- Create Product P:
- Product type: Storable
- Inventory tab > Tracking: By Lots
- Check Expiration Date
- Expiration Date: 100 days after receipt
- Best Before Date, Removal Date, Alert Date: 10 days before
expiration date
- Save
- Products > Lots/Serial Numbers > New
- Product: P
- open Dates tab
There are two different usecases and issues starting from this point.
Usecase 1:
- Dates tab, delete all dates, save
- set the Expiration Date, all other dates are set
- without saving, update the Expiration Date again
Issue 1: The other dates don't update according to the new Expiration Date. This happens because neither if conditions in `_compute_dates` match the case where the product has an expiration date set, but it has not been saved to the lot.
Solution 1: Add an additional condition in the `_compute_dates` method where `lot.expiration_date` is set, but `lot._origin.expiration_date` is not set. This will ensure the other dates are updated correctly when setting the Expiration Date without saving.
Usecase 2:
- Dates tab, set an Expiration Date, save
- Without saving the record, update the Expiration Date several times, with dates in the future
Issue 2: The other dates (Best Before Date, Removal Date, Alert Date) will drift off further in the future, while they should always be 10 days apart from the expiration date. This happens because the new dates are being set relative to the actual value of the date, which changes with each successive update.
Solution 2: set the new dates relative to the value of the `lot._origin` dates, which remain constant between successive (saveless) updates. This will ensure that the other dates maintain a 10-day difference from the Expiration Date consistently.
opw-3374135
closesodoo/odoo#130599
X-original-commit: a275cbcd2d8a87bbd8cadf85c094625ebd8358c4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Markup("") on a HTML field should be counted as an empty field.
Check now the length of the value and assign false for HTML field
if we have an empty string inside markup.
This was leading to an issue where empty alert message were displayed
based on computed HTML field.
closesodoo/odoo#130479
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, if a website does not have a domain, nothing tells
the user that this is a misconfiguration that can lead to broken
behaviours. For example, here are the steps to reproduce:
- Have two website (X and Y)
- Website Y does not have a domain
- Tab 1 has Website X selected
- User opens a new tab
- Tab 2 has Website X selected as well
- User switches tab 2 to Website Y
- No redirection happens
- User switches back to tab 1
- User opens the HTML editor for Website X
- Website X content is displayed
- User saves
- Content is saved on Website Y
This is pretty hard to fix as a lot of the python flow for Website uses
`get_current_website` which will uses the session's "force_website_id"
in priority.
In any case, we consider having multiple websites sharing the same
domain (or having no domains at all) a misconfiguration. Therefore, we
should warn the user of so.
This commit adds a tooltip on the website switcher for websites that do
not have a domain set. It also adds a notification recommending users
close other tabs if they switch website.
opw-3374214
closesodoo/odoo#130448
X-original-commit: bc0c33e3d0026a14af40ed683fe27092a97e71a7
Related: odoo/design-themes#684
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this PR, the user during livechat embed tests was the admin partner while
it should be the public partner. This commit fixes the issue.
part of task-3332628
closesodoo/odoo#130429
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Prior to this, tax groups in Kenya where labeled "TVA".
The labels are changed for a version containing "VAT" instead.
task-3391884
closesodoo/odoo#127109
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Nothing will happen if you click on a product without image, sale comment
and attributes in selfOder if no table was selected before.
To reproduce the issue:
1. Create a product without image, sale comment and attributes (Fill in product name, price, availible in pos)
2. Open a new selfOrder page (without a table selected)
3. Click on the product
Issue: nothing happens, the product cannot be ordered. If no product meets
at least one of the three conditions (image, sale comment or attributes),
it will not be possible to select the table, and thus self-ordering will
be impossible. In fact the table selection only happens during the first
order.
closesodoo/odoo#130614
X-original-commit: 186d60e57da5a5b0182131a936838821a01a7a5f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit change /report/barcode/?type= to /report/barcode/?barcode_type
See ee324e8#diff-8f0bbb50491623995fba965c3d64585c6cbfdbbe519ec95473e472826d253826R1977-R1979
similar fix done previously in `l10n_sa`: https://github.com/odoo/odoo/pull/127222
sentry-3983735307
closesodoo/odoo#130604
X-original-commit: 93b6d3f0bad435a413b1b5b44445ddc4a6cd7852
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
To reproduce:
- Create a Distribution model, with an analytic distribution
and an effect on Partner A
- Create a Sale Order, for Partner A
- Confirm it
- Add a line on this Sale Order
=> The new line does not get the distribution of the model
It couldn't be done before 16.0 because a compute would trigger when posting the sale order, because date_order was used for the default rules, and so would trigger it at wrong times.
Distribution Models don't use this date anymore, so the compute won't happen at wrong times.
task-3355886
closesodoo/odoo#130597
X-original-commit: 22fd34b0d8b944a7afd031b894d750a8291d0aba
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Set "Cash Discount Tax Reduction" to "Always"
Crete the following taxes:
- fixed136:
- Tax Computation: Fixed
- Amount: 0.1360
- Included in price: False
- Affect Base of Subsequent Taxes: True
- fixed176:
- Tax Computation: Fixed
- Amount: 0.1760
- Included in price: False
- Affect Base of Subsequent Taxes: True
- 6%:
- Tax Computation: Percentage of Price
- Amount: 6
- Included in price: False
- Base Affected by Previous Taxes: True
- 12%:
- Tax Computation: Percentage of Price
- Amount: 12
- Included in price: False
- Base Affected by Previous Taxes: True
Create the following products:
- A:
- Sales price: 116.00
- Customer taxes: 6%
- B:
- Sales price: 0.91
- Customer taxes: 6%
- C:
- Sales price: 194.21
- Customer taxes: fixed136, 12%
- D:
- Sales price: 31.46
- Customer taxes: fixed176, 12%
Create a Payment Term "1/7 Net 30" with 1% discount if paid within 7
days
Create an invoice:
- Add payment term "1/7 Net 30"
- Create the lines
- product A, quantity 6
- product B, quantity 350
- product C, quantity 1
- product D, quantity 5
Save
Issue: An error will block the action
"""
The move (Draft Invoice (* 44)) is not balanced.
The total of debits equals $ 1,483.87 and the total of credits equals
$ 1,483.86.
You might want to specify a default account on journal "Customer
Invoices" to automatically balance each move.
"""
This occurs because we compute the balance amounts for epd without
rounding. Then in `needed` we sum up the amounts, ending up with 3 epd lines,
having respectively the following balance:
- 10.145 -> 10.15 after rounding
- -13.6601 -> 13.66 after rounding
- 3.5151 -> 3.52 after rounding
So, because of the rounding, we will have 1 extra cent in debit amount
and the invoice will result unbalanced
Fixing by rounding the partial epd amounts
opw-3327069
closesodoo/odoo#130596
X-original-commit: c9fc35ad5bb437c6e20ea4244178e4f15b7eeac3
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
If the user only has "Point of Sale" permission but not "Employees" permission, the image will not be displayed using the link "/web/image/hr.employee/${cashier.id}/avatar_128"
instead use "/web/image/hr.employee.public/${cashier.id}/avatar_128"
closesodoo/odoo#130566
X-original-commit: 152e1a360fad3de1bc5363bf476e26f48563e5c0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Those fields are no longer used since all client actions and the
studio report editor have been converted to owl.
Part of task~3439226
closesodoo/odoo#130462
Related: odoo/enterprise#45015
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
This field has been introduced as a fix in 15.0 [1] where views
were still legacy, and it hasn't been adapted in the forwardport.
So this commit converts it to owl as the support for legacy fields
is about to be dropped.
Part of task~3439226
[1] odoo/odoo#112520
Part-of: odoo/odoo#130462
Currently, the migration key is stored through a workaround as a config parameter,
because the behaviour needed to be changed in stable.
Now, several things can be fixed:
- `account_peppol_migration_key` is now a field on `res.company`, not `account_edi_proxy_client.user`
- `account_peppol_attachment_ids` can be removed as the specs changed and it's no longer necessary
- `peppol_proxy_state` can be removed as it's no longer useful after `enable_peppol` was added
- SQL constraints need to be changed to only include active users.
This allows users to deregister/migrate away from Peppol and then re-register later, with their previous edi user being archived
closesodoo/odoo#129595
Related: odoo/upgrade#4980
Signed-off-by: Laurent Smet (las) <las@odoo.com>
https://github.com/odoo/odoo/pull/112114 added a new component that extended the
Many2ManyAttendee component, including the setup() method. However, the extended
setup() method was not calling super. This commit adds the super call to the
component.
After the introduction of the new RelationalModel, the missing super call caused
a traceback when clicking on any calendar event.
task-3441130
closesodoo/odoo#130593
X-original-commit: c0856a6e1e8a740dbfeb9523616e4288119fb50e
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Move some helpers used in mail, phone_validation and sms modules directly
at BaseModel level. Those are used to find emails, partners, phone numbers
and countries on records when sending them emails, notifications and sms.
Improve default behavior of those helpers to cover most existing use case.
Remove overrides now covered by standard behavior.
Simplify phone / sms methods implementation. It was a bit messy with methods
of sms overriding methods from phone. All this code can be simplified now
that we have several years of usage in addons to see what people did with
those modules. Globally
* _sms_get_partner_fields is replaced by _mail_get_partner_fields;
* _sms_get_number_fields is replaced by _phone_get_number_fields;
* _sms_get_default_partners is replaced by _mail_get_partners;
Add a generic phone formatting tool on BaseModel allowing to simplify most
calls done to the phone_validation API. Remove custom definitions on some
models as it is now available directly.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#130468
Related: odoo/enterprise#45036
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
'_sms_get_default_partners' exists in SMS to find default customers to
notify when sending automated SMS. It can be replaced by '_mail_get_partners'
helper available on BaseModel in mail.
A specific case exists in calendar where it was overridden to avoid notifying
attendees that declined the event, notably for alarms. This feature has been
moved directly in the reminder sending method, to keep behavior coherent.
Test is updated accordingly, and is now really using the SMS mocks to simulate
the sending.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
In addition to finding the customer, sometimes we just want any partner on
a record, notably for VOIP. For that purpose we improve heuristic for
finding partner (fields or records). It introspects the model to find any
relational field towards res.partner. Note that as it is generic it does
not ensure the partner is a customer, just some partner.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Support by default 'phone' and 'mobile' fields if present on model as phone
fields to fetch when searching for a number. This allows to remove several
of unnecessary overrides always doing the same thing.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Move 'mail' and 'phone_validation' helpers directly at model level, allowing
to rely on those methods in all models instead of only when inheriting from
'mail.thread' or 'mail.thread.phone'.
Those helpers are used to find primary email, phone numbers or customers in
flows involving sending emails or SMS. A default behavior exists that is
generally valid for most models. Method can then be overridden to implement
their own custom behavior.
Future commits will improve them and remove duplicated computation between
mail, phone_validation, mass_mailing and sms modules.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
Probably due to a copy paste, _compute_sms_template_id on sms_template_id field
of alarm model is not correctly called. It refers to the mail template instead
of the sms one.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
In V14, the cardholder name is send, but not in V16.
closesodoo/odoo#130545
X-original-commit: b8d7d1a619c76e3ce0a50e9fc9251a33fc8ca52b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This PR will introduce multiple display improvements. Here is the list:
- In the accounting settings, the fiscal localization section has a button that
was oddly placed. This PR solves that issue.
- On the dashboard, when clicking the three dots on a card, the options "remove
from favorites" and "configuration" were not aligned.
- In ir_attachment, the label and field of "datas" will be aligned, and a gap
will be added between the icons.
- In the settings, the button links were inconsistent in terms of padding. This
PR resolves that.
- In the payment providers, two button links had text wrapping issues. By adding
Bootstrap classes, this has been resolved.
closesodoo/odoo#130522
Task-id: 3342969
X-original-commit: d4ba0c1f69212bfb0030036951c2888e935bbdf0
Related: odoo/enterprise#45060
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Exporting the EventConfiguratorRelationalModel and EventConfiguratorRecord
classes allows us to easily extend them into other modules. This will
allow us to add functionality to the event wizard of the sales lines without
doing tricks.
closesodoo/odoo#130521
X-original-commit: a597fb19b4bec4403f9f31eb141d3053c3b755cb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fix a minor issue introduced in this commit: https://github.com/odoo/odoo/commit/60465047df56c07e61623c1f7304fede28232581
The issue is that the left bottom section of the invoice layout is constraint on the left side, even if nothing is present on the right part. This caused an issue for example with the Mexican Localization where the text beside a QR code can not reach the full width of the page, making the QR code and the text on top of eachother.
task-3444692
closesodoo/odoo#130456
X-original-commit: 1bbd89cacbbd4fc600eb2da20577d6688392485b
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
1. Purpose: be consistent with the information indicated in the
description of the form view + add a way for users to analyze the margin
of their project is relative terms
- updates right-side panel > display the margin % under the margin
- apply the same color code and visibility conditions as for the margin
- The margin section is visible only if there are revenues and costs for
the current project.
2. Purpose: currently, SOLs and associated revenues are only taken into
account in the project updates right-side panel when it is set either on
the project, its tasks or its timesheets. This was designed this way to
manage the use-case where the AA of the project would be linked to
multiple projects. We wanted to avoid duplicate information.However, in
practice, it seems that the current behavior is confusing and is
generating a lot of questions from customers (according to our
colleagues at the support and the PS). IMO, the use-case where an AA
would be shared with multiple projects is not very common and we should
privilege the basic use-case.In addition, even if we have duplicate
information in case of a shared AA, it is still possible to have the
detail per project from the accounting app by setting a corresponding
analytic distribution.
- SOLs and associated revenues should be taken into account in the
project updates right-side panel if their SO share the same analytic
account as the project, regardless if the SOLs are set on the
projects, its tasks or timesheets, or not.
task-3330274
closesodoo/odoo#128439
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR refactors the patch function in order to simplify its code but also and most of all remove the `this._super` bound on each patched method call.
The patch function now supports the javascript keyword `super` to get the parent's property.
This removes constraints we had with `this._super`. We had to create a rather complicated intermediate function to bind `this._super` and this function was called each time before we called a patched method. It was annoying for debugging but necessary. Because of this intermediate function `this._super` was also had to re-bind each time we entered a patched method which was annoying with async method, we had to save the parent method in the patch before awaiting its execution. Finally, not a big issue but still, objects could not have a `_super` property as it would be hidden in the patch.
task 3410198
closesodoo/odoo#125716
Related: odoo/enterprise#43852
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, a patch was used to modify some classes in place
but these classes were declared some lines just before the patch.
This commit replaces those patches by mixins, it's a better way to
provide a same extension to multiple classes as the extension is
done by the language.
Task: 3410198
Part-of: odoo/odoo#125716
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
This commit refactors the patch function in order to simplify its code
but also and most of all remove the `this._super` bound on each patched
method call.
The patch function now supports the javascript keyword `super` to
get the parent's property.
This removes constraints we had with `this._super`. We had to create a
rather complicated intermediate function to bind `this._super` and this
function was called each time before we called a patched method.
It was annoying for debugging but necessary. Because of this
intermediate function `this._super` was also had to re-bind each time
we entered a patched method which was annoying with async method, we
had to save the parent method in the patch before awaiting its
execution. Finally, not a big issue but still, objects could not have a
`_super` property as it would be hidden in the patch.
task 3410198
Part-of: odoo/odoo#125716
*=sale_timesheet.
In this commit improve following UI in task analysis and list view,
- aggregate the sum of following fields in project.task list view, hours spent
on sub-tasks, total hours, progress.
- in project.task list view move 'id' after the 'state'.
- from task analysis remove the measure 'remaining hours percentage'
from graph and pivot view.
task-3330295
closesodoo/odoo#124396
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Add a new filter to the orderpoints view to allow filtering by vendor.
closesodoo/odoo#101090
Task: 2964309
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, there was no functionality to trigger replenishment before
min qty is reached. This commit adds a "Order to max" button to top of list view
of replenishment when orderpoint(s) are selected. This button will trigger
replenishment for lines where Max Quantity - forecast > 0.
Taskid: 2964309
Part-of: odoo/odoo#101090
This commit focuses on fixing the UX for managing avatars and badges
within `tagsList` in edition mode. The changes include:
For Avatars:
- Implemented an overlay effect on :hover, making it clearer which entry
is currently selected, providing a visual cue for users.
- The "remove" button now appears on :hover only, reducing visual
clutter and improving visual scanning.
For Badges:
- Added visual feedback when hovering the "remove" button, making it
more apparent and user-friendly.
task-3439555
part of task-3326263
closesodoo/odoo#130485
X-original-commit: 649a58cd88c4d74cdd62f47c1c0c354ced143481
Related: odoo/enterprise#45028
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since the relational model was rewritten (PR 114024), the record id
is no longer present in data. We must replace record.data.id with record.resId.
closesodoo/odoo#130466
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Chart of Account Update with their translations
2865568
closesodoo/odoo#130463
X-original-commit: efbd486e4c114cb9f6dff2bbbf9a2ff23212ca61
Related: odoo/enterprise#45016
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, an event listener was added on
several registries to copy the required registry for
mail tests. The registries should be copied once when
the test suite begin to avoid side effects in tests.
closesodoo/odoo#130461
Related: odoo/enterprise#45014
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The goal of this commit is to complete the list of activeFields for
an x2many in list mode when a record is opened with the fields present
in its form view. This ensures that there is always an activeField
for all the data in a record. Before this commit, when the x2many's
form view was not inline, when the form view was closed, the fields
not present in the list view no longer had an activeField, which could
cause crashes.
closesodoo/odoo#130453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
amdi-odoo