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
In this commit we have modified the planning explanation in the project settings
in order to accomodate the removal of tasks from the planning app
(see enterprise repo of the same branch)
task-2941828
closesodoo/odoo#98035
Related: odoo/enterprise#30404
Related: odoo/upgrade#3771
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the /website/add was always redirecting the requests
to the newly created pages. This way, the controller could be called
from a frontend 404 page (when clicking on the "Create page" button),
and from the WebsitePreview client action's "new content" modal,
introduced in [1].
This commit adds a "redirect" parameter to the controller that will be
used by the 404 page, to keep the same behavior for this use case. But
when called from the webclient, it will return either the id of the
created view (for *.js, *.xml, ... urls), or the new page url, so that
the webclient is not fully reloaded when it is not necessary.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#97408
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, following this flow on enterprise:
- Go to the webclient, on the homepage: '/web'
- Click on the website
- Click on the "contact us" menu
- Click on the browser's back button
=> The back navigation happens in the iframe, it's normal
- Click on the back button again
=> The url has changed for the webclient "homepage" one but the
WebsitePreview is still displayed.
This happens because the router service listens to the hashchange events
to communicate the webclient which component to display.
But with [1] it was decided to replace the regular webclient's router url from the
WebsitePreview client action with the frontend's url. As a result, the
'hashchange' is never fired when navigating back from the client action
to another webclient route.
To fix that, the 'popstate' event is listened at the client action
level. If the new url is a regular webclient's router one, an
'hashchange' event is triggered to continue the flow as if the browser's
url was never changed.
The same hook is used to revert back the original webclient route
/web#action=website.website_preview... when leaving it, so that the
router can replay it correctly when navigating back from another route.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97408
Before this commit, clicking on the back button in edit mode would
reload the page, but keep the editor open and lead to bugs.
Now, the WysiwygAdapter handles back navigation with an empty history
state. On the popstate event, triggered by a back navigation request,
the WysiwygAdapter will leave the edit mode with the leaveEditMode
method introduced earlier.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97408
Before this commit, the BlockIframe component was managing its
visibility based on the 'BLOCK'/'UNBLOCK' events. Also, it was possible
to continue to interact with the SnippetsMenu when the iframe was
blocked.
With the previous commit modifications, it is needed to block the clicks
and prevent interactions with the SnippetsMenu when reloading the
iframe. For that, the BlockIframe component is reworked: a specific
state for this component is added at the WebsitePreview level. This
allows to add a o_is_blocked class on the container which prevents the
clicks on the client action when it is blocked. Therefore, it is not
blocking only the iframe anymore, but the whole preview. It is renamed
accordingly.
The 'loaderDelay' parameter is dropped, as it was used only to show the
loader after the snippets menu transition. As now the snippets menu is
removed after the reload, it is not useful anymore.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#97408
This commit reworks the way the edit mode is left, from the client
action. It does 2 things:
1/ It keeps the SnippetsMenu as long as the iframe is reloading. Once
everything is ready, the SnippetsMenu is removed with a transition.
2/ It prompts the "Discard your changes" modal when switching language in
edit mode.
1/ Before this commit, the WysiwygAdapter was dismounted before
reloading the iframe. It was simpler this way, because the OdooEditor
has set some listeners on the editable document, which will crash during
a reload of the iframe.
Now, in a leaveEditMode method, the WysiwygAdapter will make a copy of
the snippet's menu html element, and display that skeleton while the
editor is destroyed.
It will also check if the editable is dirty and prompt a
modal to the user if needed, as it was before.
Some of the code to display that "fake" snippets menu is shared with the
Editor component which uses it to unmount and remount the WysiwygAdapter
while reloading the iframe (in a _getDummySnippetsEl method).
2/ With that, the quit method, passed as a prop to the WysiwygAdapter,
and played in the new leaveEditMode method, is updated with two
parameters: an onLeave function that will be played when the component
is unmounted, and a reloadIframe boolean.
As the WysiwygAdapter listens to a new 'LEAVE-EDIT-MODE' event using
these parameters, it allows for any website component to request leaving
the edit mode, with a reload or not, and execute an action after that.
This fixes [1], which was leaving the edit mode without going through
the WysiwygAdapter, and so, without checking if the editable was dirty
or not (i.e. without prompting the "Discard your changes" modal).
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[1]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
task-2687506
Part-of: odoo/odoo#97408
