Purpose of the task is, there is no easy way to request custom online
payments on sales orders or invoices. The only way is to create an
URL manually: /website_payment/pay?reference=inv-008&amount=123¤cy_id=1
So added menu 'Generate payment link' in action in sales order and invoice.
while making payment pass the partner so reconcilation account flow should not
break as partner_id on account payment is reauired to reconcile.
co-authored-by: sza-odoo <sza@odoo.com>
Task-1938635
Closes: #31575
Currently when payment is processed through the payment link by
public user then there is no details of partner(email, country etc..)
so due to that some payment provider(paypal, stripe etc.) produce
the traceback on public payment
so when generating link for the payment pass the partner on link so
where payment is processed by public user then it will get the customer
of the record as partner, so on behalf of the customer the payment is
processed.
task-1938635
Closes: #31575
Add an id on the timesheet tab on Task form view in order to refine
visibility behavior of this tab from another module (industry_fsm in
enterprise). We want to be able to hide this tab for FSM tasks.
Task-2052287
closesodoo/odoo#36015
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
The goal here is to share the same kanban between fsm and project. A few tweaks are also done to the project kanban.
As in fsm the kanban group by is different we still had to do a primary inherit in fsm.
related task 2009563
This fixes a traceback that was appearing when looking at projects reports. It was due to a typo in the name of the field to group by in a group-by
related task 2000719
Reintroduce remaining_value on the valuation layer. We thought we could
get rid of it and only use unit_cost but with tricky receipt value such
as 10 for three units it works indeed better.
Increment remaining_value when applying a landed cost, don't use this
field anywhere else than _run_fifo. It's a shame we have to edit in
place the value of a layer while we were able to keep them as they were
everywhere else...
There still an imprecision sometimes due to the representation of float
and their way through currency.round (see test_rounding_2) so we also
call currency.round on the computed field value_svl to get a real 0
value.
task-2057877
closesodoo/odoo#36013
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When we are running the tests on runbot, we get race condition when we
verify if the syncronisation is beeing sent, so we removed all of this
as it doesn't really verify if it synched or not, and we make a search
in python after tour execution.
closesodoo/odoo#36010
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are trying to resize and/or move a table in editing mode on the
floor plan, it doesn't work anymore, because the polling that will count
the orders by table will re-render the table after it has been selected
so the classes making it dragable are ot there anymore and you cannot
move or resize it.
Tu ix this behavior, we are not calling table order count when we are in
editing mode.
TASK-ID: 2057368
When you were trying to edit the table map of your pos, you were getting
a traceback because, it was getting information from a table that
is not in the list of table.
So we are now correctly set the table in the list when it is created and
duplicated.
TASK-ID: 2057368
Tracebacks caused by invalid values in invoice_line_vals.
Since accountpocalypse, 'number' became 'name', and the
invoice creation process in repair was forcing the repair name
as invoice name. To keep the visibility of the information that
a repair order was the source of the invoice, a field was added
in the form view.
TaskID: 2057443
closesodoo/odoo#35930
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
With this commit we add the possibility to save the db_uuid and enterprise_code on the IoT Box.
We check the current SSL certificate and if it is not authenticated or not up to date
we send a request to `https://www.odoo.com/odoo-enterprise/iot/x509`
with the db_uuid and enterprise_code to get the certificate, key, and domain associated with the client.
The IoT Box will be accessible in HTTPS according to the following domain:
`https://<ip-with-dashes>.<sub-hash>.odoo-iot.com`
`<ip-with-dashes>` being the ip address with dashes
`<sub-hash>` being a subdomain assigned by Odoo to a customer
Task: 1931770
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#35854
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
-There is no requirement to show production_id on scrap as it has already come
from a particular manufacturing order.
task-1959647
closesodoo/odoo#34201
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
-In the action menu, the manager has no rights to delete the scrap order thus
added the access rights for the manager in the main csv file.
task-1959647
With this commit we add the possibility to save the db_uuid and enterprise_code on the IoT Box.
We check the current SSL certificate and if it is not authenticated or not up to date
we send a request to 'https://www.odoo.com/odoo-enterprise/iot/x509'
with the db_uuid and enterprise_code to get the certificate, key, and domain associated with the client.
The IoT Box will be accessible in HTTPS according to the following domain:
https://<ip-with-dashes>.<sub-hash>.odoo-iot.com
<ip-with-dashes> being the ip address with dashes
<sub-hash> being a subdomain assigned by Odoo to a customer
Task: 1931770
Since
https://github.com/odoo/odoo/commit/e88fe6f380ed5682f2cedad16ba13ca43a3828c2
, the groups to have access to pricelists is `group_product_pricelist`,
not `group_sale_pricelist` anymore.
`group_sale_pricelist` is now a technical group enabling access to
advanced pricelist rules (percentage/discount).
When making a test import for new users, there don't be present
in DB, so the computation of the customer/supplier rank will raise
an error.
Manage the case when user is not yet present in DB.
closesodoo/odoo#35955
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>
During an HttpCase, when a browser_js test is finished, cookies are
removed to ensure that the next call will start on a clean base. From
time to times, when an HttpCase have multiple tests methods that call
browser_js, the user session of the previous test is being used.
With this commit, the session cookie is explicitely deleted and should
prevent that kind of problem. By the way, the browser's cache is also
cleared.
When issuing the first json command, it happens that the chrome process
has crashed. As a consequence, a log entry appears with saying that it
could not connect to chrome debugger.
After some investigations, it appeared that it was only happening with
google-chrome versions 75.0.3770.90 and 74.0.3729.169.
This error message was seen on the chrome stderr:
listp->slotinfo[cnt].gen <= GL(dl_tls_generation).
As a conclusion, it seems that we were hit by this issue:
https://github.com/GoogleChrome/puppeteer/issues/2207
While this commit does not fix the google-chrome issue, it adds a new
verification to check if google-chrome process is running before trying
to issue the json command. If it's not case, an error message is logged
with the error code.
After a browser_js, http requests threads are joined. If one of them
doesn't finish gracefully, a dumpstacks occurs.
As the dumpstacks call is in a loop, it can quickly polute logs. Even
more, a the dumptack may include threads that were not yet processed and
that will be joined in a future loop.
With this commit, dumpstacks will be called once and for all at the end
of the method, if at least one thread is remaining.
Furthermore, before this commit a sleep of 0.5 sec occured at most ten
times for each thread before considering it as lost. It means that each
thread is benefiting of the cumumulated time of the previous ones.
That's not fair.
With this commit, a default timeout of 10 sec is used for all threads.
The original warning is kept for each remaining request.
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>
Damien Bouvy