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>
When a picking type is duplicated, the sequence was by default copied into
the new picking type. This behaviour has become misleading since the sequence_id
is shown only on debug mode. We now simply prevent sequence_id of being copied.
TaskID: 2057311
closesodoo/odoo#35908
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
An Inpayment Slip with Reference (ISR) subscription number is provided by the bank or by Postfinance
ISR When the ISR subscription comes from Postfinance it is a direct
subscription.
ISR (bank) When the ISR subscription comes from a bank it is the bank subscription
toward Postfinance.
Having the subscription number on res.bank has 2 drawbacks:
If you have multiple accounts at Postfinance
or
If you have multicompany and each company has a Postfinance account
you won't be able to emit with different ISR subscriber numbers.
This also renames the fields to be accurate on the meaning.
An ISR reference is a Payment reference that will apear on the invoice.
It is better to name it subscription number.
closesodoo/odoo#35873
Signed-off-by: Josse Colpaert <jco@openerp.com>
One cannot override the attribute `selection`, and list selections can only be
extended with `selection_add`.
Adapt the bad extensions to be consistent with the new warnings
closesodoo/odoo#35663
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When extended with the selection_add parameter, a singleton (value,)
where `value` appears in the overriden selection, can be used.
The new values are inserted in an order that is consistent with the
overridden selection and this list.
selection = [('a', 'A'), ('b', 'B')]
selection_add = [('c', 'C'), ('b',)]
> result = [('a', 'A'), ('c', 'C'), ('b', 'B')]
Aaron Bohy