The constraints could be bypassed if a user set a jourmal/account/location to
the pos.config and, then, modifies the location configuration.
Checking the value of current_session_id makes sure the constraints is triggered
also when the session is created.
Prevents workarounds such as explained at #26641
Revision on https://github.com/odoo/odoo/commit/ec8c505bc1c9ec21939e9ffef53a9cc6f63f30c7
The commit above changes the way threads are rendered: the template
now uses a thread object, instead of a list of messages.
However, it was not handling messages that have been filtered from
the searchview. As a result, it was not possible to filter messages
at all.
This commit re-adds the possibility to filter messages, by providing
information on the domain of the thread in the template.
Task-ID 1877502
Before this commit, the search option buttons were not
hidden when clicking on the zoom-in/zoom-out button next
to the searchview.
This is due to updating the control panel with the list
of buttons as the searchview buttons, instead of the
container. Since the visibility of the searchview buttons
is defined on the container, the toggler button and the
search view options lost synchronization.
This commit fixes the issue by providing the container
that is shared between search option buttons.
Task-ID 1877502
Before this commit, only thread windows in the backend had the
method `getID`. However, it should also be the case for the thread
windows in the frontend (website livechat), as the template of any
thread window makes use of this method.
Before this rev., there was a race condition making some tours
randomly fail on runbot, when the following steps occurred in that
order:
- load webclient
- as soon as the menu is ready and visible, click on a root menu
which thus leads to a doAction
- in the meantime, an RPC is done by the webclient to retrieve
the (optional) default action of the user (if there is no
state in the url, which is the case for tours in general)
- when that RPC returns, this action (if any), or the action of
the first menu is executed, thus leading to a second doAction
- the ActionManager using a DropPrevious, the first doAction is
dropped and thus the action linked to the clicked menu is
never shown, making the tour fail
This rev. uses the state of the ActionManager's DropPrevious to
prevent the default action from being executed if another action
is already being executed, thus removing that race condition.
Note that this fix is temporary, as the community webclient is
currently being refactored.
The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
Due to the route beginning with 'test: ', it was interpreted like a
protocol and on some OS (ubuntu for example), a xdg-open prompt pops up.
So, the window looses focus and some tests will fail because of that.
The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: for 10.0 up to not including 11.0 which is fixed by #26911
opw-1877663
closes#26912
This commits add a container to make row full width, it also use bs4 classes to
make the content centered.
It also clean useless DOM.
Task-1878245 (chatter)
As an `form-group` can contains element having `form-control` class and other
not having it, we should not force height on `form-group` elements.
Typically, we could have:
div.form-group
input.form-control
button
Forcing height only on `form-control` will make the input thinner than the
button.
Steps to reproduce the bug:
- Go to Timesheets > Settings and set Invoicing policy to “Approved Timesheets Only”
- Create a expensable product P with Type "Service", Invoice based on
“Timesheets on tasks” and Service Tracking “Create a new project but no Task”
- Create a new SO using P and confirm it. A project PR will be created
- Add a task TA to PR
- Add two timesheets(T1, T2) to TA, one for the current date(T1) and one for a future date(+1 month, T2)
- Go to timesheets and validate” the timesheet T1
- Go to the SO and now the delivered_qty is equal to 1, so create the invoice I
- Validate I
Bug:
T1 and T2 were linked to I instead of just T1 (because invoice based on
“Approved Timesheets Only”)
opw:1879051
We have JS which tooks care of customizing the color and background
options of .carousel elements so that the active carousel item is
edited instead. The recent snippet refactoring added those options on
.carousel-item elements directly, so that slide and carousel options
are separated in the customize menu. This however made the options
complex to use and some of them impossible to use. This also added color
and background options on non-snippet carousels like for the products in
the shop, which was not meant to be. This commit goes back to the old
system for now.
Note: using "[class*='s_']" as a selector to match snippets is not
correct as it matches the elements whose classes contains 's_'... and
in our case the body was matched because it has the class
'editor_ha*s_*snippets'. A proper way would be to use this selector:
"[class^='s_'], [class*=' s_']". But even then, this is not really a
good way.
task-1878245
The menu item dialog is an extension of the link dialog where all the
.form-group elements which contain a .link-style option element are
removed. A new link style option was recently added but with the wrong
class, preventing it to be removed for the menu item dialog.
task-1878245
By default, all btn colors are suggested in the link dialog (alpha,
beta, gamma, delta, epsilon, link, primary, secondary, success, info,
warning and danger). In lots of themes (and the default one), primary
= alpha and secondary = beta, which led to having two suggestion with
the same apparent color.
A new system was introduced to automatically remove the duplicates...
but this system also removed the button preview as it considered it to
be a duplicate.
This commit also adapts the preview to BS4.
task-1878245
The calendar view does not make many sense for timesheet. Moreover
recording timesheet from it is strange since there is no end date
on the timesheet model.
Removing this view avoids confusing for users.
Task #1883326
This commit redesigns all portal screens, improve bootstrap compliance
and increases maintainability. See sub-commits for details.
Closes https://github.com/odoo/odoo/pull/26849
* account, project, purchase, sale, website_crm_partner_assign
- Create a single template to be used for all doc's entry in order to
simplify maintenance
- Make the entire entry clickable using bts4 classes
- Fix an alignment issue between title and badge
Empty space were used to compensate the icons size.
Unfortunatly icons may have different sizes and the surrounding text
barely match the empty space provided, causing misalignment.
Frederik Kramer