The icon that is displayed in the employee kanban view is determined by the
field hr_icon_display, computed in the method _compute_hr_icon_display. This
method is overridden in multiple modules such as hr_holidays, hr_attendance
and hr_homeworking.
Currently this field has a state to show no icon (presence_undetermined). In
this change this state is extracted into the a separate field
show_hr_icon_display with the default state of hr_icon_display being
presence_to_define. In this way a module such as hr_attendance, which only
overrides _compute_hr_icon_display to show the default icon for everyone as a
default, now only needs to change this separate field and does not need any
knowledge of what other states exist. This reduces coupling between modules.
Have a list view (new RelationalModel inside a WOWL list view) that has
a legacy many2many tags field in its arch.
Try to add or remove some records from that many2many.
Before this commit, there was a crash, because the legacy field wrapper
doesn't use the model the right way for that case.
After this commit, there is no crash.
closesodoo/odoo#99431
Signed-off-by: Georis François (fge) <fge@odoo.com>
Currently, when creating an invoice from factur_x XML, the vendor is
identified by sequentially checking (in this order) the following
information :
- VAT number
- name
- email
However, when we generate a factur_x XML, we do not include
the partner's email address. This means that in some cases, two odoo
databases are not able to communicate bills/invoices properly.
This commit brings back a behavior that was unintentionally removed in
https://github.com/odoo/odoo/commit/d25fdafcd8eb4cfef14c2ef7ed8ad7785dd01b55
opw-2909408
closesodoo/odoo#99263
X-original-commit: 51609d19177c080835116f0ad9c04c33536d926a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Before this commit, if a text-muted on a setting (a description of the
setting) contains fields or HTML tags, the highlight generated wrong
texts.
Now, we highlight the text in an iterative way, taking care to only
highlight the text.
closesodoo/odoo#99205
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When searching a text of a hidden field (for example, "gate"), the
setting itself will not be shown, but the group title, and the app
Search Header will be shown.
This issue arise because, we use an if condition with all the label of
all the fields (hidden or not) in the group (or app) to decide if the
group title or the app header will be showed.
Now, we modify this to hide (d-none) the group title or the app header
if there is not a settings below them.
Part-of: odoo/odoo#99205
Tax Report _compute_from_amls_grids query calls
two method overriden in pos_account_reports.
The resulting query contains EXISTS subqueries on pos_session.move_id
and pos_order.account_move. Because these two fields are not indexed
by default, the cost of the query can skyrocket in large databases,
leading to slow tax report generation.
closesodoo/odoo#99095
X-original-commit: 51e607a70be804b0cd614cccc36ea0145c934676
Signed-off-by: Rémy Voet <ryv@odoo.com>
As message_notify can be done on empty recordset, message.res_id and
message.model can be Falsy. During filtering on rating messages, we need to
prevent the code to crash when filtering on those two properties and filter out
messages that are not linked to any record.
Task-2850521 (Knowledge: trash management)
closesodoo/odoo#99436
Related: odoo/enterprise#30908
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = bus, hr_holidays, test_discuss_full
- use channel member instead of partner for typing
- use channel member instead of partner for all other return values from server
- remove temporary partner hack in livechat and keep public partner
- remove some obsolete convert data
- adapt format methods accordingly
task-2664853
closesodoo/odoo#98923
Related: odoo/enterprise#30760
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since d7716f071d, the onchanges to create the stock moves in mrp
production have been replaced by computes.
There was a hack in the create() method to trigger the onchanges in case
of import. As those onchanges do not exist anymore, this hack needs to
be remove too.
The compute methods are called naturally in imports.
closesodoo/odoo#99434
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since 3a145216a6a6fb259c5afef6175669c8a65ba39f, partner_info value
was changed but not it's usage.
This commit also simplify the code for better understanding.
closesodoo/odoo#99422
Task-id: 2954397
X-original-commit: a667179e43ab00a8384b75923769782f1836c24b
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
This commit removes all custom codes to create a QRCode to get the link
of the Timesheet Awesome App, the link is sufficient to download the
mobile app.
closesodoo/odoo#99362
Related: odoo/upgrade#3840
Related: odoo/enterprise#30942
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Passwords are something we know that need to be exact. So, the regular
behaviour where double spaces are changed to single ones and spaces are
trimmed at the start and end of the string is not a good idea for
passwords in general. Not that a lot of people put double spaces or
space in the start or end of their passwords, but it happened and it is
possible. So, if password is True on the field, it does not make any
sense to trim it and let's support that in the web client (as the web
client does the trimming) instead of putting trim=False on all password
fields in the Python, risking to forget it for the next password field.
closesodoo/odoo#99088
Signed-off-by: Josse Colpaert <jco@odoo.com>
As required from Singaporean tax regulation, we need to add Box 5 on the tax grid to make sure the amount is correctly mapped in both boxes.
2854163
closesodoo/odoo#98950
X-original-commit: be3c30f304c91c2689bd907cf32108a401ea7a9f
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commit aims to make the BinaryField and PdfViewerField appear and
act the same way as they did before their conversion to Owl.
This mostly consists of a few tweaks in the conditional rendering of
certain elements in the template, and the rest of the changes are meant
to clean and simplify the values the component is working with.
closesodoo/odoo#98251
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit allows the 'editInput' test handler to also handle inputs of
type "file". To do so, the value must be a file (or a list of files),
and the handler has been refactored to accept a certain given value only
if its type allows it.
Part-of: odoo/odoo#98251
* Local variable 'filtered_self' might be referenced before assignment
* confusing use of `order` from the previous for loop, support multi recordset
in the method instead.
closesodoo/odoo#98068
Related: odoo/enterprise#30408
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
By default, a related field dependencies are the fields in his relation
path.
But for non stored UX fields, the field should only be recomputed when
values editable in the view are edited.
Example:
On a given model:
product_id = fields.Many2one(...)
product_type = fields.Char(related='product_id.type')
The product_id field can be changed on the model view, but not the
linked product,
so there is no need for the orm to search records whose product_type
must be invalidated
when the type is changed on a product.
To avoid this 'useless' search, we can manually restrict the field
dependencies:
product_type = fields.Char(related='product_id.type',
depends=['product_id'])
Part-of: odoo/odoo#98068
make it clear it's expected to be called from the frontend, prefixing it
with action_.
Also split the method to have an utilitary method recomputing all prices,
to use in the tests and/or business code (without the chatter message).
Part-of: odoo/odoo#98068
As for the show_update_fpos field, do not store this simple UX field.
We only want to highlight the pricelist modification when it happens (to
allow prices recomputation), no need to store it undefinitely.
Part-of: odoo/odoo#98068
Some countries, such as mexico, require a seller to be able to
generate an invoices from a ticket from a sale done in a shop,
even after a few days.
This change aims to allow this, by allowing to create an invoice at
a later date after the POS has been closed.
This is done by partially reversing the POS closing entry, and then
generating an invoice the same way it would be done at the POS closing.
The customer can scan a QR code if enabled in order to request the
invoice by himself, requiring him to fill a for to give the customer
information required for the invoicing.
Allows to fill additional fields dependent on the localization that are
required to be set on the partner or the invoice.
Task id #2946604closesodoo/odoo#97675
Related: odoo/enterprise#30599
Signed-off-by: Laurent Smet <las@odoo.com>
This commit removes code related to refunds that are not implemented in
this version of the Mercado Pago integration.
closesodoo/odoo#92848
Related: odoo/documentation#2149
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit improves the payment terms by:
- making the payment terms lines editable on-the-fly removing the need for a wizard
- refactoring the computation of the payment terms
- adds new demo data for payment terms
- adds an example section where the user can test and preview the due dates and amount of its payment terms
- adding a new parameter "Display terms on invoice". If set, the payment deadlines and respective due amounts will be detailed on invoices.
The refactoring:
- adds a field `months` (months to add after the invoice date)
- adds a field `end_month` (if True, switch to the end of the month after having added months or days)
- renames the field `day_of_the_month` to `days_after` (days to be added after the switching to the end of the month, only if `end_month` is set)
- deletes the field `option` which was too restrictive
- modifies the calculation of the payments terms taking into account these new fields
This allows some combinations that were not possible before.
Example: The French payment terms "30 jours fin de mois le 10" (which should be interpreted as "10 days after the end of the next month") can be encoded as
```
months = 1
days = 0
end_month = True
days_after = 10
```
Task id 2852814
closesodoo/odoo#91490
Related: odoo/enterprise#29661
Related: odoo/upgrade#3524
Signed-off-by: Laurent Smet <las@odoo.com>
This commits fixes the behavior of the confirmation dialog.
When a user dismiss a dialog using the close button or the
ESCAPE key, it should expect to execute the cancel action,
if any had been given to the dialog.
The behavior was missing, and the dialog was simply closed.
Tests have also been added, since this core component didn't
have any test since its introduction.
closesodoo/odoo#99418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current taxes computation method defined in account_edi has been moved to account on account.tax to be usable on any models.
closesodoo/odoo#99401
Related: odoo/enterprise#30967
Signed-off-by: Laurent Smet <las@odoo.com>
Prior to this commit, the space between messages where too large and
created inconsistencies.
This commit fixes this issue.
closesodoo/odoo#99396
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, we were using `bg-secondary` which was dependent on
whether we used community or enterprise style, and `bg-black-75` which
is legacy and not available on the discuss guest page.
This commit fixes this issue to make the colors consistent across those
cases.
closesodoo/odoo#99393
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The dropdown is positionned from the left, with comming from bootstrap:
- left: 0; # from CSS [OVERRIDEN]
- right: auto; # from CSS
- left: 0px; # from JS
- transform: translate3d(123px, 0px, 0px); # from JS
the 123 pixels is the offset to the left border of the parent component.
This is working in left-to-right, but in right-to-left, only the CSS
style is reversed and we get:
- right: 0; # from CSS
- left: auto; # from CSS [OVERRIDEN]
- left: 0px;
- transform: translate3d(123px, 0px, 0px);
Since the result is `right: 0; left: 0px` the size of the dropdown is
set to 100%, but this is not taken into account by Popper.computeStyle
which will have a 100% parent width Popper set at the position of the
small width Popper.
Graphical example:
```
[----------------------] # width of the page
[---] # popper in LTR
[---] # popper in RTL with fix
[-------------] # popper parent size
[-------------] # popper in RTL without fix
```
as shown, without the fix, the popper content might overflow outside of
the page, and the content aligned to the right unseen).
opw-2926863
closesodoo/odoo#99355
X-original-commit: a883d0de0336c85ebab411ec42ae0e9936b5195f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
On Chrome, have a field that supports autofill (you have to have set up an adress in Chrome first).
Click on that field, and apply the autofill proposition.
Before this commit, there was multiple crashes, roughly one for every handler of event `keydown`.
This was caused by the fact that the autofill feature triggers keydown events without the field `key`.
(https://bugs.chromium.org/p/chromium/issues/detail?id=581537, I could not find a better ticket).
This seems to be a bug on Chrome's side, since the spec doesn't mention that field may be unset (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key).
After this commit, there is no crash.
closesodoo/odoo#99348
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The purpose of this commit is to prevent saving to a form view
if you have created and edited a new invalid record in an x2many.
How to reproduce
- go to a form view with an x2m
- create a new record with at least one required field empty in the x2m
- edit another field than the required one
- click on the save button
Before this commit:
- The view is switched to readonly mode and the new record is deleted.
After this commit:
- The view stays in edit mode, the new record is not deleted and
a notification indicating invalid fields is displayed.
closesodoo/odoo#99288
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This PR:
- adapts the following fix [1] in master branch, as the former has been fw-ported until saas-15.3 included
- improves the dates utility functions (parse/format) by removing the timezone option, which is difficult to understand and has proven to be error prone
- changes the records fields value/raw_value properties in kanban templates, in order to ease their usage
[1] odoo/odoo#98413
Linked PR: odoo/enterprise#30780closesodoo/odoo#98980
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit will make date(time) raw_value an ISO string
instead of a native JS Date.
- Before this commit
In kanban templates:
- the raw_value property of a record's date/datetime field is
a native JS Date object.
The problem with raw_value is that JS Dates toString
method depends on the system locale and timezone.
In the code base, the usage of raw_value for date/datetime fields
usually parse the raw_value into a luxon DateTime object
in order generally to display it in a specific format, or in order
to compare it to another luxon DateTime object (e.g. the now instant).
- After this commit
The raw_value property of a record's date/datetime field
has become an ISO8601 string, instead of native JSDate toString
format (which I recall depends on system's locale and timezone).
The ISO8601 format is easier to work with.
Part-of: odoo/odoo#98980
The goal is to improve the dates utility functions (parse/format) by removing the timezone option, which is difficult to understand and has proven to be error prone.
- Rationale
When manipulating DateTime objects on the JS side, associated timezones
must be always coherent.
Until now, there were several code parts that had to check the DateTime
timezone and handle things differently in a case or another.
This sometimes lead to wrong code.
E.g. there was a bug in the DatePicker component because the DateTime
object it receives in props is in local timezone, but once it updates it
through the parse utility, the new object is in UTC.
- After this commit
The DateTime objects you'll get through deserialization or parsing are
always set in the user's local timezone.
The formatted strings you'll get through formatDate and formatDateTime
utils will always be expressed in the user's local timezone.
The formatted strings you'll get through serialization utils will always
be expressed in UTC.
- serializeDate and serializeDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the server expressed in UTC
- formatDate and formatDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the user, expressed in the user's TZ
- deserializeDate and deserializeDateTime
- expected input: a date(time) string provided by the server, in UTC
- outputs: a DateTime object in user's TZ
- parseDate and parseDateTime
- expected input: a date(time) string provided by the user, in its TZ
- outputs: a DateTime object in user's TZ
- Other changes in this commit
As the timezone option has been removed from parsing/formatting utils,
all their usage had been adapted in the codebase.
The large diff in dates_tests.js is because some tests were reorganized,
others were removed/adapted/joined.
A test has been removed from daterange_field_tests.js, because it has
no sense: it displays a date field as a datetime, but a date field does
not have any time information.
Part-of: odoo/odoo#98980
Co-authored-by: Julien Mougenot <jum@odoo.com>
Reproduction:
1. Install Timesheet, and load demo data
2. Mimic a timezone in browser (Chrome): Right click->Inspect->Sensors,
in the Location-> choose Other…, type “America/Puerto_Rico” in Timezone
ID, refresh the page
3. Go to Timesheets->Timesheets->All timesheets, choose pivot view
4. Add custom filter, Date is between 1st/Aug/2022 and 5th/Aug/2022,
apply
5. The filter result is correct but the tag in the search bar is “Date
is between 31/07/2022 and 04/08/2022”
This also happens to other fields with type Date, but not Datetime. For
example, in Accounting->Reporting->Invoices Analysis->Pivot view, the
same issue happens with Due Date filter. For Datetime field, it doesn’t
have the issue, for example in CRM->Sales->My pipeline, change to pivot
view, the custom filter for Assignment Date doesn’t have the time zone
issue.
Note: reproduction usually works during the daytime in Brussels.
Reason: miswriting when rewrote custom_filter_item from V14 to V15. The
value pushed to descriptionArray should not be changed on time zone.
Fix: in parseField and formatField, use default formatters/parsers options. Add test for the Date filters.
Related PR: odoo-dev@aeb8e49?diff=unified#diff-6d9230cfcd007b087b2851cbf0b4a33b26dc3c91087853da6fe7ce8c2b60e42f
Reference code in V14: https://github.com/odoo/odoo/blob/14.0/addons/web/static/src/js/control_panel/custom_filter_item.js#L170-L173
opw-2941231
Part-of: odoo/odoo#98980
Co-authored-by: Liu Jinjiu <jili@odoo.com>
These commits improve the newsletter snippet by adding a template selection to it.
One can now choose between email / sms / form templates.
The first two are composed by a unique input to allow the user subscribing with its email or mobile phone.
The last allows the user to fill up a form more thoroughly and to select more than one mailing list to subscribe to.
it's also possible for one to create a subscription form by using the form snippet directly.
Task-2672194
closesodoo/odoo#79582
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit adds the possibility the create a subscribing form from the
form snippet, it creates default inputs automatically.
LINKS
Task-2672194
Part-of: odoo/odoo#79582
PURPOSE
This commit adds a new bridge module that allows one to select the SMS Template
for the newsletter block snippets that allows the user to enter his mobile phone
and get the latest news via mobile text.
LINKS
Task-2672194
Part-of: odoo/odoo#79582
PURPOSE
This commit adds a template selection to the newsletter block snippet to
allow one to switch between email, mobile (added with a new module) or
form template.
LINKS
Task-2672194
Part-of: odoo/odoo#79582
PURPOSE
This commit moves the mailing list option of the editor to the parent
block to ease the configuration of a newsletter snippet.
LINKS
Task-2672194
Part-of: odoo/odoo#79582
Follow-up of https://github.com/odoo/odoo/pull/98160
PR above made single app im_livechat tests sometimes fail with
following error:
```
TypeError: LivechatController.livechat_init() missing 1 required positional argument: 'channel_id'
```
This comes from RPC `/im_livechat/init` in frontend, which must
provide `channel_id` but somehow doesn't sometimes.
This only happens with `test_im_livechat_support_page`, sometimes on runbot.
Task-2969488
closesodoo/odoo#99385
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Rob Coekaerts