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
Before this commit:
Conversion of list element to paragraph block was not possible, as Text from
command-list was only changing the tag of a selected element, not the list tag.
After this commit:
Now list element can be converted to a paragraph block when the Text block is
selected.
Task-2826472
closesodoo/odoo#99325
X-original-commit: 96ac829e0dc512350f5a828702c20d44219cc933
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Non total order can lead to randomized order in some case, making some
test behaviour random and/or difficult to debug.
Adding some fallback 'id' order shouldn't hurt
closesodoo/odoo#99324
X-original-commit: 6e40e5fe775273a2d3a968ac113cbeb578318dd1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The new structure of X2manyField stores ListRenderer in its components.
PortalUserX2ManyField is not using that structure properly. Therefore,
PortalWizardUserListRenderer it is not found nor used correctly.
This commit correctly places that List Renderer in the components.
Task-2968411
closesodoo/odoo#99320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The test is currently disabled on runbot and breaks every night. Update the
counter to check if it is still random.
Task-2925606
closesodoo/odoo#99305
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the legacy implementation of FieldMany2ManyTags, we instantiated
a FieldMany2One with the attrs of the many2many field node. As a
consequence, the FieldMany2ManyTags honnored its own options and
all options supported by the FieldMany2One.
In the new implementation, before this commit, we lost the support
of the Many2ManyField's specific options, in particular "no_create"
and "no_create_edit". This commit fixes that issue.
With this commit, the FieldMany2ManyTags also takes into account
the "can_create" attribute that is automatically set to "0" by the
framework if the user hasn't the required access rights.
Note: Many2OneField options is a mess, it would be nice to
refactor and simplify them in the future.
closesodoo/odoo#99283
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
3c28be1b33ea18be7280d9372ebd53a54140da86 enforced readonly by default on
computed and related fields, but Activity/note was not adapted to be
readonly, leading the application to crash when editing a note.
This commit fixes it by introducing a new field to write on instead of
the computed one.
Follow-up of task-2955927.
closesodoo/odoo#99310
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
These are buttons that happen to be inside dropdowns so the
preventDefault must be done in that case otherwise the selection of the
user is lost and the edition command cannot work.
Steps to reproduce:
- Select some text
- Try to use the justify buttons that are inside the text alignment
dropdown in the toolbar
task-id 2964314
closesodoo/odoo#99300
X-original-commit: 8a124a9342fc0f7091b78b45d9b7fe13db472927
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Lucas Perais