Let's assume the following situation:
- an empty editable x2many list with date field (or any other
fixed width field) and optional fields
- add a record to the list, but discard it directly
- toggle an optional field
After those steps, the date field doesn't have its hardcoded,
absolute width anymore.
This rev. fixes this issue by clarifying the way the stored widths
are erased when the columns change, preventing to reach a corner
case in which we have stored widths, but we can't apply them, and
thus let the browser uniformly divide the space amongst columns.
Columns with an absolute width (e.g. '120px') must always have a
width of at least that value. When there are records in the list
the column's widths are computed by the browser according to the
content (in readonly). However, for some field types, the rendering
in edition is a bit wider (e.g. date(time) fields because of the
caret).
This rev. sets a min-width to those fields such that the rendering
is also correct in edition.
Before this rev., a grouped list view with all groups folded
behaved like a list with records w.r.t. the computation of column
widths, whereas it should behave like an empty list, as there is
no record to help the browser to compute the optimal width for each
record.
When there were records in the list (and the browser computed the
optimal column widths according to them), and the user removes
them, we want to keep the widths as they are instead of forcing
them according to the field's types.
Mainly, when adding the first record to the list, as this is when
we switch from forcing the column's widths (when there is no data),
to letting the browser optimally divide the available space.
Some other cases had to be handled, like the multi edition.
Having two attributes for this was probably overkill. We now have
a single attribute 'width' which can specify either a fixed width
(e.g. '120px') or a factor (e.g. '2.5').
On a list with no data, the width of each column is determined by
a heuristic. Before this rev., the heuristic was based on the field
type. It now takes the potential widget set in the arch into
account, and fallbacks on the field type.
This rev. refines the way we compute column's widths in editable
list views.
When there are displayed records, we let the browser compute the
width of each column (which is thus optimal with respect to the
content), and we then freeze those widths s.t. it doesn't flicker
when we switch a row in edition.
When there is no record, we keep the former heuristic based on
absolute and relative widths (depending on field types). However,
we set the same weight for all fields having a relative width (i.e.
all but boolean, date(time) and numeric), such that the remaining
space is evenly distributed between them.
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit cleans up website.visitor related views by removing unnecessary create mode.
It also removes the form view on the website.visitor.page model (="Visitor Page Views") as tree view contains all
necessary information and there is no point in creating/editing them.
Task#2057933
closesodoo/odoo#35978
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow publishers to add a comment on frontend reviews with ratings. Purpose
is to allow to give some feedback or context on published reviews.
SPECIFICATIONS
In order to answer to a rating message (review) of a course (eLearning) or a
product (eCommerce) we add a way to the publisher to directly comment a review
inside the website rating chatter.
Any publisher can add/edit/remove comment of a rating message from the website.
The goal is not to enter into a discussion but just to give a feedback. This
comment is not sent or propagated to anyone, just displayed for information
purpose.
In portal chatter
* add 1 button below a review "Comment" (for publishers of the website only)
* only one comment possible by review/rating
* when the comment is added, display
* author name, date, comment
* 2 buttons, only visible by the website publisher: edit and delete
LINKS
Task ID : 2026911
closesodoo/odoo#35956
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow publishers to add a comment on frontend reviews with ratings. Purpose
is to allow to give some feedback or context on published reviews.
SPECIFICATIONS
* rename / reorder some methods according to JS guidelines;
* split portal composer and portal chatter override to better understand
module organization and ease future code additions;
LINKS
Task ID : 2026911
PURPOSE
This PR rewords the mail template "slide_template_published", makes the
member of a course follower of the course, allow members to leave courses
and prevents the templates to crash on preview
SPECIFICATIONS
When a user subscribe to a course, the user is automatically follower of
the course in order to be notified when a new content is published.
The email that the members get when a new content is published on the course
is reworded and fixed to avoid preview crash.
A new widget is implemented allowing members to unsubscribe from a course
or to leave it directly from eLearning frontend.
LINKS
Task 1985511
closesodoo/odoo#35627
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Before it was not possible to leave a course.
- This commit adds a modal to give the members the possibility to leave
the course and also subscribe or unsubscribe to get notified or not.
+ Display a warning message when leaving if field enroll value is "payment".
task-1985511
This commit improves the email that the members get when a new content
is published on the course and prevents the template to crash on preview.
task-1985511
when a user subscribe to a course, the user is now automatically
follower of the course in order to be notified when a new content
is published
task-1985511
When we open a table, the option verify sync is called, and doesn't
always work because of a race condition when we chack the status of
connecting, and the icon that has already changed.
As it doesn't really check anything because we check in python that the
orders are synchronised, we removed it.
closesodoo/odoo#35949
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In the tour of pos restaurant, we are closing the pos that will redirect
to /web, and we won't wait this redirection. That will lead to a
remaining request taking too much time.
Since the refactoring, SMS is no longer in auto install. This is a shame
because we want to put forward the SMS features. In any case, the user can
always disable SMS from the General Settings if it is too invasive.
FP / AJU request.
Task 2057705
closesodoo/odoo#35946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
To correctly choose in which account a line should be posted,
we have to know if the partner is a customer or a supplier.
Specification
=============
Keep track of the number of account moves "in" and "out"
a partner has. These counts should be based on the posted
account moves. A customer that has been created from the
'Customer' menuitem will have a rank=1. When a customer
invoice will be created for him, the generated account moves
will be taken into account to compute its rank. The most
invoices we have for a partner, the higher his rank is.
Note: To avoid any concurrent update failures on the partner,
if one transaction has already locked a partner row, the count
update will be skipped that time.
This means the values may be approximative in the database!
The exact values will eventually be correctly computed at
the next successfull try.
Known limitation of this approach: The computation ignores
the set of currently selected companies. Actually, storing
context dependent values in the database is a bad practice,
and is avoided in that case by taking all the companies into
account.
Use the stored fields `customer_rank` and `supplier_rank`
to order partners when searching by name. This allows to show
best customers or best suppliers on top.
To choose if best customer or supplier are shown on top,
the context key `res_partner_search_mode` is used.
The context key can take two values: 'customer' or 'supplier'.
This decision partially reverts/revamps 8766f38 to only use
account moves instead of PO and SO
On actions showing partners, set a default filters to menus to
only display customers (customer_rank > 0) if the string is
"Customers", and only suppliers if the string is "Vendors" or
"Suppliers".
TaskID: 2049131
closesodoo/odoo#35942
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When you are creating an invoice from the POS, the report route is
called to download the invoice, since changes made in rev: 118190f3b3
The values for ids where empty, so we give them now the correct id list.
closesodoo/odoo#35926
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This is a performance optimization: modifying a regular record will not
trigger some recomputation on a transient record. Most transient
records are simply waiting to be garbage-collected, so there is no need
to keep their fields up-to-date.
closesodoo/odoo#35909
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As part of the back2basics, the stage messages were modified to be clearer
* when an opportunity is lost previously 2 separated messages where
created in the chatter (one for the reason, one for the active state)
now, one message is created with both infos;
* new message when an opportunity is restored;
There where also some fixes to typos, and an the probability of a lead
to be successful received a new title "estimated by Odoo".
Task 2026297
closesodoo/odoo#35308
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit provides hard constraints (SQL level) for expense to work in multi company
environement. This is related to a R&D task, the rest of the code need to be adapt, but
freeze is coming.
As expense implies accounting entries, it is required to generate them in the right
company, the company field should then be required.
Task-1999686
closesodoo/odoo#35953
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
- Before the change of `sudo` and `with_user` the code was non sense, it
was doing a `self.sudo(self._uid).check_access_rights('read')` which
was doing nothing.
But now with `with_user`, doing a `self.with_user(self._uid).check_access_rights('read')` breaks the
flag `superuser`.
Meaning that if the code was called using `sudo` it was bypassing the
ACL tests.
closesodoo/odoo#35896
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- With the new ORM optimizations, the cache doesn't depend on the
context and the key context that are really important for the
computation of a value must be explicitly set.
Setting `force_company` as a determinant will make sure that the
company on the environment is taken in account.
Babel is already taking the language into account while
formating a time delta into a readable string like '2 minutes ago'.
_format_time_ago was put in translate.py file to be able to use
the _ translate class. But it can be placed in misc like other
format function already using babel.
This fix the PR #34624
and is linked to Task ID : 2028059
Task ID: 2055847
Closes PR #35806
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fields supplier/customer was removed from the partner, then, they
cannot be used in the default for the views.
Avoid the next traceback in the next case:
'''raise ValueError("Invalid field %r in leaf %r" % (left, str(leaf)))
ValueError: Invalid field 'supplier' in leaf "<osv.ExtendedLeaf: ('supplier', '=', True) on res_partner (ctx: )>"```
1. Go to create a new payment for supplier
2. Try select the supplier
closesodoo/odoo#35743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The setup of IoT Boxes failed since the merge of the task about
barcode scanners: odoo/odoo#35084
We tried to get the list of available keyboard layouts from the IoT
Box. The request was sent from the server, which cannot reach the Box
because it's not located on the same server.
We now perform this task the other way around. When a device of type
printer is created on the Box, we send the list of available layouts
to the server.
TaskID: 1961025
closesodoo/odoo#35925
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit, a simple optimization was done: if a field was
modified in such a way that the new value is the same as the initial
value, then it is not considered changed.
However, with the new changes in the ORM, it may be an issue, because
doing so loses the intent of the user. If an onchange changes a field,
then the user changes it back, the server is not aware of that fact.
With this commit, we simply keep the field in the list of changes to
send to the server.
opw #2057230closesodoo/odoo#35890
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As f871908e86 wants to allow simple empoyee
to select any SO on which the expense should be reinvoice, we need a little
adjustement. Indeed, before this commit, the ir.rule of current user are
still apply (bad comprehension of `name_get_uid` parameter), so a salesman
will only be alble to reinvoice on its own SO while an employee can do the
same on any SO.
This commit fixes this strange use case with rco's advice to make this
mecanism work in a cleaner way.
To restrict this `name_search` done in `sudo`, we apply a context key, and
an hardcoded domain (combine with a AND) to minimize the divulgation.
Also, we want the saleman to be able to open and see the SO.
Task-1843241
closesodoo/odoo#35938
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit avoid searching into quants and stock.moves, the quantities
(available, forecasted, ...), for service product in order to speedup the search
on big recordset
closesodoo/odoo#35920
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The computation of kit quantities was not efficient. A loop on each product
of the recordset to consider performed. Each time a product was seen as 'not a kit',
a new computation on the complete recordset was done. This leads to a N^2 complexity
This commit only compute stock quantities for non kit product in one batch
For some reasons (probably missing sheet & group), the form view for the byproduct
wasn't displaying properly. This commit implement and force a cleaner view when
you're coming from the form view of the Bill of Materials.
TaskID: 2057347
closesodoo/odoo#35918
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This PR reverts the saas-12.2 editor by restoring the 12.0 editor.
The saas-12.2 editor was an intermediate work between the previous
editor of Odoo 12 and the new one slated for Odoo 13. It was unstable
but it was expected to be replaced by the new editor of version 13.
However, since the new editor has been postponed to Odoo 14, the
saas-12.2 one would have been staying in Odoo 13, which would have
been a nightmare to maintain. To avoid this outcome, we chose to
put back the 12.0 editor in its place.
This has the particular advantage that Odoo 13 will share the same
bugfixes as Odoo 12 and 11 as they all run under the same core
editor, while the saas-12.2 one would have been an entirely
different beast to maintain.
Despite its title, this PR is not a revert of PR 29775 per se, as
we are using the wysiwyg abstraction layer that was introduced in
that PR.
The goal of the wysiwyg abstraction layer is to provide an
interface for other modules that want to use the editor feature
such that the editor core itself can be changed without requiring
extensive changes in the other modules.
This PR uses the wysiwyg abstraction layer to restore the 12.0
editor with minimal changes to the modules that use the editor.
closesodoo/odoo#35677
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since we reverted the saas-12.2 editor in favor of the 12.0 one,
we faced a dilemna regarding how the editor iframe is handled in
mass_mailing.
The 12.0 version was using a special controller to get the website
assets required for mass_mailing while the saas-12.2 version used
a completely different mechanism that was, obviously, not handled
by the 12.0 version.
We did not want to reintroduce the old controllers who were
considered to be a hack to load the assets in the mass_mailing
iframe. However, we were very cautious about changing the editor
itself to avoid introducing new bugs in the editor core of 13.0.
The approach we chose at the end, is to use the loadAsset mechanism
introduced in saas-12.2 to load the necessary assets and inject them
in the mass_mailing iframe. This did not reintroduce the controllers
nor did it require to change the code of the editor itself. However,
it required moderate changes to the wysiwyg interface.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
These modifications crystalize the behavior of the old editor, even
if it makes less sense than the behavior of the saas-12.2 one.
In some cases, the only reasonable adaptation we could do for 13.0
was to delete the tests, as these tests relied on mechanisms of
the newer version of summernote introduced in saas-12.2 which
cannot be easily replicated in the older version from 12.0 that
we are reintroducing in this PR.
It is sad to see these tests go, but we knew this was going to be
something we would lose in reverting back to the older editor.
That being said, since these tests were not present back in 12.0,
we are simply back to the 12.0 state of things, not worse. Don't
weep for them though, they will be back in Odoo 14.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
This commit reverts the saas-12.2 editor by putting back the editor
of Odoo 12.
The saas-12.2 editor was an intermediate work between the previous
editor of Odoo 12 and the new one slated for Odoo 13. It was unstable
but it was supposed to be replaced by the new editor of version 13.
However, since the new editor has been postponed to Odoo 14, the
saas-12.2 one would have been staying in Odoo 13, which would have
been a nightmare to maintain. To avoid this outcome, we chose to
put back the 12.0 editor in its place.
This has the particular advantage that Odoo 13 will share the same
bugfixes as Odoo 12 and 11 as they all run under the same core
editor, while the saas-12.2 one would have been an entirely
different beast to maintain.
This is a partial revert of f2969923.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Summernote was updated alongside the new editor of saas-12.2. However,
since we are putting back the editor of 12.0, summernote needs to be
downgraded back to the version that was compatible with the 12.0 editor.
This is a revert of 17c6d005.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Aaron Bohy