The default value for failure_type was the 'NONE', instead of being
simply False/NULL. This represents a significant waste of tablespace
with no added value.
Switching to true NULL value for representing the absence of error
also save some precious time during database upgrades on databases with
large numbers of emails.
While fixing the values for failure_type, also fixed a few typos and
untranslated strings.
See original feature at 133eeb1bbf
This commit changes two things in the time range menu
appearance:
- the order of range options
- the spacing between them (now two different groups
are separated by an empty lines)
Some tests had to be changed accordingly.
This commit fixes a bad behavior of the pivot view. By the
past, if there were no data to present in the pivot view, no
information on the pivot view configuration was returned by
the get function. This does not cause problems to the pivot
renderer (by design) but causes problems elsewhere, for
instance in a dashboard view that contains a pivot view.
Indeed, at each update, the dashboard view reinstantiates its
subviews, so that information can be lost if a subview is of
pivot type.
The _mergeData function used in pivot view comparison mode
was not designed to accept the absence of the __count key or
null values for measures in the objects returned by a 'read_group'.
The absence of the __count key would result in a traceback and null
values for measures into wrong calculations (infinities).
One could ask why null values did not cause problem before.
The simple reason is that the formatters used to format cell values
render a 'null' value like they render a zero.
This fix makes explicit that null values have to be considered
as zeros and avoid in that way Infinity values when computing
variations.
The search view in mobile mode has been redesigned and looks a bit different
from the search view in desktop mode. This commit adapts the time range menu
appearance in mobile mode.
Exporting data of a pivot view in comparison mode ends in a
crash. The root cause is that _t was replaced by _lt
so that some strings were replaced by objects with a toString method.
This does not cause problems when rendering a pivot view since
both QWeb or JQuery call that method. The function _exportData does not.
This commit fixes that situation and adds a test of _exportData.
The buttons 'Flip Axis', 'Expand All', and 'Download xls' are
now deactivated when no data are displayed in the pivot view
(those buttons are useless in that situation).
In Employees views, selecting New Hired filters leads to an access error
with a simple user.
With this commit, this filter is limited to the corresponding users
group.
Backport of 804b9b7c5e
In Employees views, selecting New Hired filters leads to an access error
with a simple user.
With this commit, this filter is limited to the corresponding users
group.
Closes#26747
The res.users class contains special fields that bypass access rights.
These are designed to allow a user that does not have the possibility to write
on res.users to modify their own fields, such as the mail signature.
Create and write are overriden to make it so, however the check_access_rights
isn't.
Since this method does not work at field level but at model level, there is no
easy way to resolve the incoherence.
Uploadding an image to a signature would add an attachment to the signature;
before being created, an attachment checks if the user has the rights to write
on the target model. The incoherence thus make it fail.
We add a special case when creating an attachment so that a user can write on
itself.
opw 1871243
- Activate lots and SN
- Go to Inventory > Inventory Adjustments
- Export a record
- Select the field 'Inventories > Lot/Serial Number'
The `name_get` of the field is exported, not its XMLID.
This is because the parsing made in order to limit the depth of export
is made on the label, not on the field name.
Actually, it is not clear WHY this limitation exists, but we keep it for
compatibility purpose.
opw-1877092
When a column is created in the kanban view, the context of the window
action is fully given but it may contain default_{field_name} context
keys that are intended for the action model.
eg. on a product.product view we could have {default_type:'product'} in
the context, if we grouped by company_id and created a new company, we
would the context is propagated and we would try to set type='product'
on the company (which causes an error).
Without the change, the added test fails with:
default_* should be removed from context, actual: "true", expected: "false"
opw-1879064
closes#26676
Revision on https://github.com/odoo/odoo/commit/017e71322b6b7f0c232f0d66ba659a5972fc3534
Commit above correctly fixes an issue with 'Edit View: X' menu item
in the debug manager, in which the name of the view was missing.
To do so, it lets the controller be aware of the name of the view,
so that it can be used in the template of the debug menu.
However, we think there is a much better solution to fixing this
issue: since the debug manager has knowledge of the view action,
we can extend this object with the name of the view.
This is exactly what this commit does: extend the action view object
so that it knows the name of the view. That way, the template is much
more readable, as `view.displayName` is more meaningful than
`controller.viewName`.
Task-ID 1878254
Steps to reproduce the bug:
- Let's consider the today date = D
- Set on your preference a timezone which has another today date = D+1
- Go to CRM > Configuration > Activiy types > Call
- Set 0 as # Days
- Go to CRM > Pipeline > Click on a lead
- Schedule an activity of type = Call
Bug:
The Due Date = D instead of D+1
opw:1877217
Make some changes which are needed for theme migration.
- Theme colors as user colors fallback only (not hard choice)
- Review option dependency system
Revision on https://github.com/odoo/odoo/commit/f7fbe8adffb1ee585c8171f6c86d38145c11848d
The commit above wrongly assumes that the object 'view' is an instance
of the view class. As a result, the property `display_name` was undefined.
This commit fixes the issue by letting the controller remember the name
of the view in a similar was as the type of the view. That way, the name
of the view can simply be retrieved from the instance of the controller
class.
Task-ID 1878254
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
In 10.0 this was not necessary since the default values were sanely set
when the editor was inside the DOM. In 11.0 the editor is not in the DOM
when this is being done and the info was wrong (eg. NaN for text size).
With this commit, we don't steal the focus and get the default like it
was done in 10.0 instead.
fixes#26366
opw-1874880
closes#26582
Steps to reproduce the bug:
- Create a user U with manager inventory access rights and no right in sales
- Create a SO and validate it, it will create a picking P
- Lock the SO
- Log with U and try to print the delivery slip of P
Bug:
A access right error was raised.
opw:1878504
If we do:
- one change that will be saved in history
- go back to the document before any change
- do other change
we can easily get in a state were the history is no longer recorded.
The history is kept like this:
- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved
so for example if we start without change (at originalState):
{pos: 0, aUndo=[], toSnap=null}
Then we do two changes (change1, change2):
{pos: 2, aUndo=[originalState, change1], toSnap=change2}
If we make an undo, we will get to:
{pos: 1, aUndo=[originalState,change1,change2], toSnap=null)
If we make another change (change3):
{pos: 2, aUndo=[originalState, change1], toSnap=change3}
So the history after the position is removed.
But when we get back to the original, the state would forever be:
{pos: 0, aUndo=[originalState], toSnap=change85}
because when doing a change, the code only removed history from the
max(pos, 1) index.
opw-1870119
closes#26701
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes#26701
Be in a grouped kanban view with progressbar with limit 10:
- records 1 to 10 are loaded on a column
- do "Load more..." on a column => records 11 up to 20 are loaded
- do "Load more..." 2nd time => records 11 up to 20 are loaded
- do "Load more..." 3rd time => records 11 up to 20 are loaded
- ...
While in reality it should be:
- do "Load more..." 2nd time => records 21 up to 30 are loaded
- do "Load more..." 3rd time => records 31 up to 40 are loaded
- ...
This was caused by the progressbar reloading the column's group. This
set the loadMoreOffset to 0 thus forgetting the current state.
Without the change, added tests failed with:
records of column are loaded => actual: "1,2,2", expected: "1,2,3"
opw-1878359
closes#26628
This is necessary to make it among the first of the "assets frontend"
inherited views, and specifically make it appear *before* the one from
website. Without this, SCSS styles may be randomly broken if the
original installation order of `portal` and `website` was reversed
(e.g. for older databases).
The recently introduced `activity` view (see rev. odoo/odoo@1de9496 has not
received all the consideration it deserves as a real view type (no RNG, not in
the valid view `type`, no doc, etc.). It was currently only working based on a
`_get_default_activity_view` method.
Even if the RNG is currently really basic, its grammar could evolve in the future.
This was causing an issue when opening Studio with this view as a default view
with an invalid type was created.
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
With a fixed price delivery method, the error message was not displayed when
the address doesn't match.
Inspired from function base_on_rule_rate_shipment
The error message was not clear enough.
opw:1879204
When fixing calendar search for recurring events we assumed that
no autojoin field will be used in this search.
The filter unread messages is based on message_ids from mail thread.
The solution here is to redefine this field in calendar to remove the autojoin.
When creating a new user, the linked partner may not yet have an email address
(not mandatory field).
When logging in for the first time, after some time an error comes up
"Unable to post message, please configure the sender's email address."
While the user should set up an email, this popup coming from no specific action
is confusing.
With this patch, the message will be posted as the system (which has an email)
The user will be warned of having no email when trying to reply.
Closes#26601
Olivier Dony