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>
3c28be1b33ea18be7280d9372ebd53a54140da86 enforced readonly by default on
computed and related fields, but some fields were not changed to be
readonly, leading the application to crash when editing them.
This commit fixes that by introducing new fields to write on instead of
the readonly ones.
Follow-up of task-2955927.
closesodoo/odoo#99253
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since odoo/odoo#96545 the number of half-days remaining were not
correct. It was showing the number of hours as days.
task-2964068
closesodoo/odoo#99055
X-original-commit: 8734ea55b4070fcc361d395923621bede94c1998
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In some situation, Chrome "loses" an already loaded lazy-loaded image
when it is moved across nodes in the DOM. This typically happens when
wrapping an image inside a link.
Note that the DOM is actually correct: if the page is saved it then
displays it correctly.
This commit detects if this problem happens when adding a link on an
image, and forces Chrome to re-display the image by re-specifying its
`src` attribute. No alternative solution was found.
Steps to reproduce:
- Use a brand new incognito Chrome window. (Make sure you closed any
previously opened incognito Chrome window before)
- Drop a "Text - Image" snippet.
- Save.
- Edit.
- Select image.
- Press "CTRL+K".
=> The image was not displayed anymore.
task-2962619
closesodoo/odoo#98889
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the website UI was moved to the backend, the edited page
is inside an iframe in Chrome. Conditions based on instanceof are not
reliable anymore: the element's type is specific to the document inside
which it was created. Because of this,
`targetEl instanceof HTMLElement` is `true` when the snippet was dragged
from the options menu - because both `targetEl` and `HTMLElement` are
the ones from the main document where the editor options panel is.
But it is `false` if the page was loaded because the `targetEl` is of
a type from the iframe's document.
We cannot use `targetEl.ownerDocument.defaultView.HTMLElement` because
the `ownerDocument` is the current one to which the target belongs - not
the one where it was created. So, a full condition would have to look
like this:
```js
(targetEl instanceof this.odooEditor.document.defaultView.HTMLElement
|| targetEl instanceof HTMLElement)
```
That is pretty verbose, so I check the `nodeType` instead.
Steps to reproduce:
- Use Chrome.
- Drop a "Text - Image" snippet.
- Save.
- Edit.
- Select image.
- Press "CTRL+K".
=> An `<a class="oe_edited_link">` is created instead of triggering the
image link tools - as if it was a text selection (except the text link
tool is not available).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2962619
Part-of: odoo/odoo#98889
Before this PR, disconnecting the websocket for a keep alive timeout
would skip the terminate method. When the loop would exit, gevent loop
will keep running and use the CPU up to 100%. This commit ensures the
termiante method is called when disconnecting due to a keep alive
timeout and solves this issue.
closesodoo/odoo#99308
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, the list view crashed when it was grouped if
there was a button column in between two "aggregatable" fields
columns. The reason is that "formatAggragatableValue" makes sense
only on field columns, and it crashes when called on a column of
another type. It was for instance the case in the Stock > Locations
list view.
closesodoo/odoo#99289
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before the form merge we had
```html
<o_action>
<o_content>
<o_form_view oe_form_configuration>
</o_form_view oe_form_configuration>
</o_content>
</o_action>
```
now we have
```html
<o_action o_form_view>
<o_content>
<oe_form_configuration>
</oe_form_configuration>
</o_content o_form_view>
</o_action>
```
So we have to adapt form_controllers.scss to match this new structure.
closesodoo/odoo#99280
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After https://github.com/odoo/odoo/pull/78439 and before this commit,
the `activeRtcSession` was a field of `callView` which is the same view
for all channels. Which means that setting an `activeRtcSession` would
display it for any channel instead of only the channel that hosted this
session.
This commit fixes this issue by moving the field to the `Channel` model.
closesodoo/odoo#99270
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Have a quick create view in kanban that has a legacy many2one
field (not yet converted to the WOWL framework for some reason).
Click on that many2one to see the dropdown of propositions.
Click on one proposition.
Before this commit, the quick create got closed, because we clicked
somewhere outside of it (the legacy dropdown).
This is a known, quite common issue in some other part of the codebase
(see d3662d370c).
After this commit, the quick create works as expected.
closesodoo/odoo#99241
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, there was no space between the author's name and
the message.
This commit fixes this issue.
closesodoo/odoo#99235
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Edit a domain in the debug text area of a domain field in debug mode
was possible but the value displayed in the text area was reset to the
value displayed in the part above. For instance, starting with a domain
field value like "[('id', '=', 1)]" then editing it in the text area to
be "[('id', '=', 3)]", the value for the domain field would be correctly
updated but the value displayed in the domain field would be the initial
value "[('id', '=', 1)]". We fix that by making the DomainSelector
component accept an extra prop "debugValue" to be displayed in the debug
area instead of the prop "value" if it is defined.
closesodoo/odoo#99207
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Setting [(1, "=", 1)] as domain in the debug text area would make crash
the DomainSelector component because the sub component ModelFieldSelector
would not accept 1 as a fieldName prop due to its props validation. We
fix that by converting 1 to a string.
Part-of: odoo/odoo#99207
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Before this commit, the required attribute has no effect on the x2many
fields. It will always be valid unless one of its records is invalid.
Problem:
In some cases, we would like to be able to make some x2many fields
required. For example, many2many_tags should be invalid if it contains
no records.
In legacy, if a field is required, then it has the responsibility to
evaluate if its value is valid. To do this, each field contained the
isSet function which returns true if the value is set.
In our new architecture, it is the model that evaluates if the value of
a field is valid based on the field type. It is therefore no longer
possible to customise the evaluation of the validity of a field based
on the FieldComponent.
Solution:
This commit will reintroduce the possibility to customize the evaluation
of the validity of a field based on the FieldComponent.
To do this, we add the possibility to define a static isSet function
on the FieldComponent. If this function is present, it will be used
to evaluate if the field value is set or not.
closesodoo/odoo#98873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Barad Mahendra