Before this commit, when we create a new object (e.g. task, product, ...),
the part of the form for the chatter was blank.
After this commit, it displays the chatter with a single temporary message
'Creating a new record...'
This message is only visible by the user that is creating the task, and goes away
when saving the newly created task. Any interaction with the chatter (buttons and
widgets at the top of the chatter, including the message itself) are disabled, so
that no interaction from the user is possible.
Before this commit, when grouping a kanban by date with a modifier
e.g. crm.lead grouped by create_date:month
A traceback was thrown on the python side bacause create_date:month was literally not a field
After this commit, the progress bar in that situation displays well,
at the price of copying bits of the read_group infrastructure
OPW 785021
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
Currently the image field rendering in QWeb using the /web/image
controller is done in web_editor. However there is no link between
the web editor and the rendering. The rendering can therefore be moved
directly in web.
During the move two options have been added to the rendering of image
field :
* qweb_img_raw_data: fallback on standard base64 behavior that is
otherwise impossible to achieve;
* qweb_img_responsive: True by default, add the img-responsive
class that is not always requested;
Thanks.
With the new views, we stopped using the browser timezone to
display the dates in Odoo, and we used the timezone defined on
the User profile instead. When loading the webclient, the
timezone offset was put into the session and used to display all
dates. This wasn't a good idea.
The given offset was computed for the current time, meaning that
it may be incorrect for specific dates (e.g. with the daylight
saving, the UTC offset of today is not the same as 6 months ago).
Moreover (but less likely), as the offset was stored in the
session, it wasn't recalculated afterwards. So if the offset
actually changed during the session (e.g. from or to daylight
saving time), the displayed dates were incorrect until the user
reloaded the page.
With this rev., we don't retrieve the offset from the server
anymore and we use the browser timezone again (like before the new
views). However, we keep the computation of the offset (on the fly)
in the session, so that it can be mocked in the test environment.
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
Planners should only be visible for "base.group_system" user group (admin settings) because there are links to install apps etc. For now missing access rights messages whenever you click a settings link.Only for admin and not by company.
Admin and the user who has "base.group_system" rights can see the planners.
This is done in order to enable the tour service only for the
superuser. Commit 6ef1644a7b changed the meaning of `is_admin`
to achieve this but broke the fact that some features of the debug
manager are available to admin and not only to the superuser. Anyway
a `is_admin` key should mean that the user is in the admin group.
We could have checked client side that the uid is equal to 1 but
adding a `is_superuser` key is more elegant and easier to grep.
Also fix the only occurence of a uid check in the weblcient.
This reverts commit 6ef1644a7b.
The tour mechanism displays a tour if the `session.is_admin` key
is set to True. For this key to bet set to True, you need to be
in the system group.
Default options adds the system group to any created user, however as
there aren't any ir.model.access rule defined on the `web_tour.tour`
model, when you try to login as this created user, you get a traceback.
As the only way to reach a `web_tour.tour` record is to have the
superuser_id, update the `is_admin` condition accordingly.
This commit introduces a mechanism to add information into the session
from a different module, without having to fetch it manually with a rpc.
This is intended to be used with small pieces of info required at the
start of the web client, such as currency informations.
To add information to the session, one can simply inherit from ir.http
and modify the session_info method.
Alexandre Kühn