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>
This commit fixes two bugs:
1) Wrong source location
Before this commit:
- Source location is incorrect after merging MOs and 3-step manufacturing is selected.
- Operation type is incorrect after merging MOs
After this commit:
- Set the source location from the correct picking_type's value while merging MO.
- Set the Operation type for the merged MO to be the same as the original MOs';
2) Traceback when splitting mo
Before this commit:
- When splitting a MO without a "responsible user" set then boom it's throwing traceback
After this commit:
- The "responsible user" is no longer required which matches the existing MO behavior
TaskID - 2754217
closesodoo/odoo#99374
X-original-commit: 67e3f2f66aeb1aa1a93ad5091af7c0375f6d9a93
Signed-off-by: Tiffany Chang <tic@odoo.com>
The FormView can autofocus a `default_field` if it exists, or, the first usable
field.
This commit moves the logic to the FormRenderer, has we need this feature in the KanbanRecordQuickCreate.
Besides, it makes sense for the FormRenderer to have that responsibility.
closesodoo/odoo#99297
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the dom ID of a field was not put onto the legacy fields'
focusable dom node. It prevented a form view containing legacy field to properly focus
the default_field.
After this commit, a legacy field's focusable element can be focused at the init of the FormView
Part-of: odoo/odoo#99297
Before, when the user dragged a card outside of a column
(e.g. whitespace to the right), the card was moved to the last stage
for which the event handler for the target was registered.
Now, we move the card only when the card drop is done inside a column.
task-2459381
closesodoo/odoo#98897
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before, the destination column while drag&drop was not highlighted.
Therefore it was not obvious for the user in which column the card
would be dropped. e.g. when the column header is not visible because
the user scrolled
Now, the destination column is highlighted when drag&dropping a card.
task-2459381
Part-of: odoo/odoo#98897
Before, it was possible to drag&drop an element from a point to another.
However it can be useful for tests to drag, make actions/tests
and then drop.
Now, the user can use the `drag` function and drop after with the
returned function.
Part-of: odoo/odoo#98897
Adds a setting to enable mondialrelay from the settings just like the
other shipping methods and a way to access the configuration of such
shipping methods more easily.
TaskId-2845799
closesodoo/odoo#98156
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Prevent archiving in-use mail servers by displaying an error message that
lists where it is still used, allowing to easily identify what need to be
updated before being able to archive the mail server.
Additionally,
- prevent the use of archived server as a fall-safe
- when duplicating a mailing with an archived mail server, replace mail
server by the default one
Detailed explanation:
1. A check has been added that raise an exception when trying to connect to the
smtp server or send an email when the server is archived.
With that solution,
- testing the connection of an archived server displays an error telling that
an archived server cannot be used.
- if a mail is still sent with an archived server, mail are in error :
"Connection failed (outgoing mail server problem)"
This fail-safe ensures that no mail will be sent through an archived mail server
and that the user will get some feedback about it.
The same fail-safe for the incoming mail server has been added.
Notes:
- the connection will outlive the archiving of a mail server still allowing
to send email through the archived server until the connection is closed. But
connection are not kept for long so this shouldn't be a problem.
- it cannot be tested because the connect method return immediately in test
mode.
2. When a mail server is archived, an user error is raised if it is in-use.
The implementation relies on each module to override the method
"_active_usages_compute" in "ir_mail_server" to complete the list with
user-friendly message describing the active elements that could send mail
through the mail server. This has been implemented for:
- l10n_it_edi: server used to send e-invoice
- mail: optional server configured for template
- mass_mailing:
-- default mail server
-- active server configured for mailing
Mail server are referenced in other elements but are not active anymore, it is
just for temporary or history purpose. Those references doesn’t prevent the
archiving of the mail server:
- mail_message
- wizard survey_invite and compose_message
- res_config_settings
Task-2821516
closesodoo/odoo#91240
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adapts the `mondialrelay_relay` widget to use wowl instead
of legacy.
closesodoo/odoo#99380
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, a legacy x2many field in list view mode didn't
display any columns.
The legacy_field compatibility layer passed the wrong views to the
x2many field. The x2many field was not receiving the arch that allows
it to generate its columns.
closesodoo/odoo#99344
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL disables view buttons that are missing attributes.
These buttons used legacy javascript, and were omitted from the accounting owl migration.
Activate those buttons.
closesodoo/odoo#99066
Related: odoo/enterprise#30815
Signed-off-by: William André (wan) <wan@odoo.com>
*: survey
This commit brings back the correct behavior on blur
to the progressbar field. It turns as a text value as
soon as the user has focused out of the input. It
also removes the wrong usage of the max_value option.
The behavior was wrongly adapted from the legacy
progressbar implementation. Tests have been adapted
to assert the correct behavior.
closesodoo/odoo#98902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* = test_website, website_blog, website_event, website_forum, website_sale,
website_slides
`_search_get_details` extension in other modules can now be performed with
fewer lines of code by updating a search type-to-model mapping, without the
need for method override.
This will also have the benefit of slightly reducing the call stack length,
avoiding some unnecessary `if` statements and list lookups at runtime.
Task-2957361
closesodoo/odoo#98423
Related: odoo/enterprise#30946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Have a date picker component in a dropdown (like in Add Custom Filter),
open the related bootstrap datepicker by clicking on the date picker
input and select a date: the dropdown closes. In this fix, we make the
dropdown stay open in that situation.
closesodoo/odoo#99345
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, Chatter in project sharing: the
'employees only' and 'visible' buttons are not toggled and both
are visible at same time.
So in this commit fixes the issue by making the 'employee only'
and 'visible' button as toggle button same as portal chatter.
task-2858336
closesodoo/odoo#99326
X-original-commit: eee722bb74db70a49ba88250afd0359c510e5ade
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
`_check_concurrency` was used to check if 2 people were modifying the
same record at the same time. It was doing so by setting a special
`__last_update` value inside the context that was later evaluted to
prevent some concurrency issues.
It was mostly unused, wasted a lot of cpu cycles and was not covering
all cases (e.g. pending write).
closesodoo/odoo#87756
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Before this commit:
changing header style, changes the alignment of the selection
After this commit:
Now after applying header on selection it doesnot changes its alignment.
Task-2641462
closesodoo/odoo#99358
X-original-commit: da8d2669b03e1016dc05f031a2a7ac840541962e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit when the portal user changes the stage of a task
to a stage with sms template, he got a traceback saying he has no access
to the `sms.template` model.
This commit fixes by checking if the user is a portal one to send the
sms in sudo when the write on the task is correctly done.
Steps to reproduce:
==================
1) install `project_sms` module,
2) create a project,
3) in the kanban of tasks for this project create 2 stages,
4) edit the last one to set a sms template,
5) share the project in edit mode to a portal user,
6) create a task with the quick create,
7) log in as portal user and go the project shared
8) move the task into the last stage.
Actual Behavior:
---------------
A traceback is occurred saying the portal user has no access to
`sms.template` model.
Expected behavior:
-----------------
The task should be in the last stage and the sms should be sent.
closesodoo/odoo#99363
X-original-commit: 9aa5e65273885001106a5fcc64677a284b77f61d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce the bug:
- install eCommerce module with assets
- go to any product page
- check the source code with https://validator.schema.org/
Notice that the 'image' and 'url' microdata tags have no base url,
so the engine assumes http://schema.org/ to be the base url. This
makes certain ad trackers such as facebook pixel unable to detect
the product being sold.
This commit adds the base_url field to both tags so that they are
correctly traced.
opw-2830058
closesodoo/odoo#99328
X-original-commit: 6817b964156938afb1f9ef261413e76ba256067f
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit adds a new feature to eCommerce: "Reorder"
The system administrator may enable the feature in the website's
settings.
It will add a new button on a completed sales order portal page to
reorder the same content.
Upon clicking the button a dialog will pop up to configure the different
product's quantities and display any error that would prevent a product
from being added to the cart.
If the user has something in his cart already a confirmation dialog will
be prompted asking the user if they want to clear their cart before
adding the products to the cart.
TaskId-2837571
closesodoo/odoo#96040
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
On the res.users form view, a smartbutton was created to
appear in very specific situations to inform on the user's
last connexion. Since its limited usage, that button is
removed from the view.
taskID 2958115
closesodoo/odoo#98470
Related: odoo/upgrade#3839
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* website_sale_wishlist
When request.website exists, it is supposed to be the same as the
get_current_website() result as that's exactly where it comes from.
The dispatcher, if the request is a frontend one, is setting the
get_current_website() result as the request's website.
closesodoo/odoo#98200
Related: odoo/enterprise#30691
Related: odoo/upgrade#3808
Related: odoo/design-themes#582
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Fix linter error
- Checking only "if group B" is the same as "if group B and if group A"
if group A implies group B, it is the case here, being a designer also
mean being a restricted editor
Part-of: odoo/odoo#98200
* website_event, website_slides
Note that `restricted_editor` is the new technical name used instead of
`publisher`
Before this commit, the `is_restricted_editor()` method was actually
checking for `designer` rights and not `restricted editor` ones.
Indeed, a restricted editor (previously publisher) never had the write
right on ir.ui.view.
Despite the method name being wrong, it was still correctly used where
we actually checked for designer rights and not publisher/restricted
editor ones.
Also, the method was checking for write access on ir.ui.view instead of
checking directly if the user had the related group.
While it wasn't really wrong, it was also including people who would
have the write right on ir.ui.view but were not part of the designer
group.
This doesn't really makes sens, as we don't want someone which received
that write right on ir.ui.view from another module (not related to the
website) to be considered as a website admin -> we don't want to show
them website admin UI and stuff like that.
The method could have simply be renamed to `is_designer()` and could
have just checked for `has_group(designer)`, but having such an helper
seems overkill, we would end up with as many utils as there is groups.
At the end, this PR:
- removes the confusing util method
- replace it by has_group checks
Part-of: odoo/odoo#98200
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
Zelong Lin