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')]
workcenter overview kanban view card width is not same for all cards,
also kanban card overlap in grouped view, to fix this apply width on
o_kanban_record class instead of inline css, also apply width in
o_kanban_group to have same width for all cards in grouped view
task-2052465
closesodoo/odoo#35803
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
From the commit: 36b976ccee
A traceback is generated while printing BOM structure
report, which is fixed in this commit.
task-2024247
closes: #34899
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE
Currently mailgateway runner user is used to create most documents through
incoming emails. Purpose of this commit is to try to link document creation
and update to users, using the email to make the matching.
SPECIFICATIONS
New sudo implementation allow to bypass access rights while keeping effective
user as creator. Use this mechanism to create documents still using the
mailgateway runner user while linking creator to matching user.
Heuristic to use to match email_from and users
* if route is linked to an alias: check its owner record and check in its
followers;
* find users having this emails;
* if route is linked to an alias: use alias_user_id field;
* fallback on mailgateway user;
Other side effect is that creator and author of incoming email linked to the
new record will now better match the document creator when linked to an
existing user.
LINKS
Task 1919267
PR #30597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to lessen complexity of stack chain in mail main
methods. Removing decorators is a good start for this.
LINKS
Task 1919267
PR #30597
When the registry is not ready, allow modifications of the selections
The following use case must reset the values:
- removing a selection on a custom field via studio
- changing the static selection definition and updating the module
The value must NOT be reset when:
- trying to remove manually a base field
- updating a module without all override being computed yet
(i.e. install)
Fully replacing the selections in an override should not happen
Instead of relying on the context, check if the registry is ready
before marking the selections as to remove.
If a static selection is removed and the module updated, it will be
removed correctly during the _process_end method as the selections
will not be present in pool.loaded_xmlids
Before this commit, updating a module A was doing a SET NULL for
selection values added by a module B via a selection_add
closesodoo/odoo#35871
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
PURPOSE
Fix frontend rating and clean a bit module organization.
SPECIFICATIONS
Fix rating in frontend (website_slides, website_sale): rating is halved at each
update and new entries have no rating.
Also reorganize portal chatter overrides
* rename files to ease code reading and discovering;
* move assets in their own file to better understand modules;
* move rating widget in its own file;
LINKS
Task 2057301
PR #35870
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Linked to odoo/enterprise#5182
Add possibility to print receipts and orders on an ePOS compatible
Epson receipt printer located in the same local network than the
browser running the pos.
TaskID: 2033442
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#35829
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Updating a datetime field in a form view will fill the 'values' dict
with a string.
This commit casts the dates in mrp.production and mrp.workorder that are given to
their respective stock move into actual datetime object. This prevent any
converting error later in the process
Task : 2055912
closesodoo/odoo#35825
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE
Fix frontend rating and clean a bit module organization
SPECIFICATIONS
In order to ease understanding of portal chatter dependencies let us name
files according to guidelines. In this commit we rename a bit files in
website mail to understand which widgets and portal parts are impacted by
website mail bridge module.
Assets are also moved in their own file to ease module discovering.
LINKS
Task 2057301
PR #35870
PURPOSE
Fix frontend rating and clean a bit module organization
SPECIFICATIONS
Remove unused template to lessen noise in this module.
LINKS
Task 2057301
PR #35870
PURPOSE
Fix frontend rating and clean a bit module organization
SPECIFICATIONS
In order to ease understanding of portal chatter dependencies let us name
files according to guidelines. In this commit we rename a bit files in
website mail to understand which widgets and portal parts are impacted by
website mail bridge module.
Assets are also moved in their own file to ease module discovering.
LINKS
Task 2057301
PR #35870
PURPOSE
Fix frontend rating and clean a bit module organization
SPECIFICATIONS
Remove useless mail.channel data as it makes noise without any added value.
LINKS
Task 2057301
PR #35870
PURPOSE
Fix frontend rating and clean a bit module organization
SPECIFICATIONS
Currently when updating a review on slides, the rating value is divided
by 2 on each update as the rating ratio is not taken into account. In this
commit we correctly update the hidden input value during the start function
using the rating ratio.
LINKS
Task 2057301
PR #35870
How to reproduce:
- Install mrp & mrp_workorder;
- Open Manufacturing and plan a workorder;
- Go on the Work Centers Overview;
- Click on "WORK ORDERS" button -> You got a "Something went wrong !".
closesodoo/odoo#35900
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This merge commit provide the possibility for project user to select
a project on an expense. Selectable project are only the one with an
analytic account set. Setting the project will set the analytic
account, so posting the expense will create analytic entries, and will
finally appear on the project overview.
If the analytic account still match an open sale order (and if the
product is reinvoicable), a new SO line will be added on the SO (this
flow does not change here).
Task-1843241 (previsouly Task-1911581)
closesodoo/odoo#29638
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Since 12.0, we wanted the employee to select directly the sales order on which
the expense should be reinvoiced. The goal was to avoid employee to select the
analytic account (too technical and usually unknown for employee). Problem is
that we had to give read access to SO to simple employee, breaking the access
rules "See your own document".
As we want to allow all internal employees to determine if the expense should
be reinvoice and on which sales order it should be, we need to allow them to
select that sales order.
This commit allows user to search on SO (simply get their name_get), no information
more to avoid breaking "See your own document" for salesman. Falty ir.rule and
access rights are now removed.
We now clearly split the cost tracking and reinvoicing flow:
- the analytic account field (visible only with group 'analytic' as considered
as advance feature) allows user to track their expenses in some accounts.
- the sales order is displayed for users or approvers to reinvoice the expense.
As this operation implies the tracking, if the AA is not give, the SO will create
its own AA in which the expense will be tracked.
This SO field is only relevant when the product has a reinvoice policy, so we hide
it if there is no reinvoice policy defined.
Reinvoicing an expense has now a different flow from reinvoicing a "Vendor Bill",
which still do magic to determine the SO from the AA set on its lines.
Technical:
to allow user to select SO from a m2o dropdown, the `name_search` is done in `sudo`
for internal user. This is a borderline 'feature' of the system. A few thing show
that the system does completely supports this ("Search More" gives access error, ...).
We still keep this solution, as we don't want a sub group giving access to SO to all
employee (aka an option allowing people to break the sales rights).
Task-1843241
This commit makes the override of the `name_search` more
consistent the basic implementation of the ORM (using lazy
name_get and supports the `name_get_uid` parameters)
Task-1911581
This commit adds a missing `depends` on the `debit` and `credit` computed
field on analytic account model. Indeed, without that, the recompute is not
done when accessing thoses fields after adding lines in the same
transaction (like in tests).
Task-1911581
For historical reason (problably the inheritS between project and AA, removed in 12.0), portal
user can read Analytic Account. This makes no sense, as it is a purely internal resource
for companies. Removing the access rights don't change anything for portal user and make
those data secure.
Task-1911581
David Beguin