Activate option to pay invoice on the portal
Activate an acquirer with the mode: handle payments in Odoo
Make an invoice for a partner
Access that invoice through the route with the access_token
You should not be logged in !
Try to pay, with stripe for example
Before this commit, there was a cryptic error syaing that the credit card ID was invalid
This was because the transaction token was created on the public user
While we tried to access it as the invoice's partner
After this commit, there is no error as the transaction token is on the invoice's partner
OPW 2034691
closesodoo/odoo#34919
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit extends the changes introduced by 88de93114 to adapt
Odoo payment flows to the switch in transaction signature done
by Authorize.net.
The initial fix was not sufficient for flows that mixed redirection
payment flows and server-to-server flows (e.g. paying a quote with a
card that gets saved then using the token to pay for a subscription).
The problem comes from the fact that the server-to-server API uses
the API Transaction Key and API Login ID as credentials to authenticate
requests; there is no need for a signature since this data is never
publicly exposed on the website and a MITM is mitigated by the fact
that it would need to be done between the Odoo server and the
Authorize.net servers (both of which use https in a normal deployment)
which is admitedly more complex than doing a MITM on a Starbucks wifi.
On the other hand, the 'redirection' flow will include all transaction
parameters as inputs in an html form, therefore the signature is
required to ensure that the values have not been modified by a website
user or a mitm.
Since both flows can coexist on the same configuration, we cannot use
the same field depending on the payment flow configuration - we need
both fields to be stored for the provider.
This commit therefore has to introduce new fields on payment.acquirer
record that can store the signature key for authorize in addition to the
usual authorize fields. Instead of adding a new module, this commit uses
non-stored computed fields that will generate System Parameters entries
for any acquirer of the 'authorize' kind when set through the interface.
closesodoo/odoo#34670
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
If "Recurring Cost Amount" is set on a frequency and the date field
"Contract Expiration Date" is not set, the configuration makes no sense
since we would have an infinite cost, and infinite fleet.vehicle.cost
records and so on which is not possible.
With this changeset, the expiration will be required if there is a
recurring cost set.
opw-2036071
closes#34883
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Enable "eCommerce Categories" in the website shop customize menu, select
a category, sort by catalog price, filter on an attribute, the category
is lost.
When you sort the records, the url changes from `shop/category/x` to
`shop?category=x`. As the attribute form is a plain get action, the
elements from the query string are lost.
We include the category in an hidden input so it is used by the get.
opw-2032477
closes#34603closesodoo/odoo#34877
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
There was an error in this tax's repartition. A tag was wrongly added to its base.
closesodoo/odoo#34245
Signed-off-by: Josse Colpaert <jco@openerp.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
We suspect a wrong snippet custom javascript code.
see: https://github.com/odoo/odoo/pull/34188closesodoo/odoo#34871
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Let's assume a form view with a readonly many2one field with a
default value. When creating a new record, the user can click on
the many2one value, which should open the related record in a form
view (stacked in the breadcrumbs).
Before this rev., this didn't work: we actually came back to the
previous view/action in the breadcrumbs, when trying to open the
related record.
closesodoo/odoo#33172
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
In a graph view in mode 'pie', a matching of dates was
attempted each time a comparison and a grouping of data
using the same date/datetime field was done.
Unfortunately, since the read groups results are ordered using
the order of groupbys, the matching was not sensible in case
the date/datetime field was not the first groupby.
We thus restrict the matching to the sole case where it is
sensible. More work should be done to have sensible matchings
in all situations.
closesodoo/odoo#34379
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The elements style was set globally and thus used to modify
the style of any chart in Odoo after the first loading of a
graph view. For instance, the charts drawn in
sale_subscription_dashboard are not the same before and after
the first loading of a graph view. This is fixed by this
commit.
when image field cannot load an image, it will default to the placeholder image.
If this placeholder image also cannot be loaded it was creating an infinite loop errors
After this commit, we only show one error if the original image cannot be downloaded
and if the placeholder cannot be downloaded, we don't show anything else.
closesodoo/odoo#35226
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Steps to reproduce the bug:
- Create an invoice I
- Set the invoice date in the past and add payment terms
- Validate I
- Create refund from I
Bug:
The invoice date is set as today but the due date was set in the past.
opw:2033438
closesodoo/odoo#34748
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
During checkout, the user can create a new billing (only for public user as it
will create a 'normal' `res.partner`), a new shipping, edit its billing (that
will edit himself) or edit its shipping address.
All those cases will go through the exact same methods, public user and logged
in user included.
This previously led to multiple issues and multiple fixes to correctly set
`company_id` and `website_id` on the address (res.partner).
See 44372471ef that fixed the `website_id` part.
See 3a0f05f33 that fixed the multi-company behavior, but needed 2ba71140 to not
modify the company of an already created partner, but was still incomplete as
after that fix a logged in user would still have the admin (sudo) company
instead of the website one as supposed.
This commit will fix that bug and add some tests for all mentionned issues.
Fixes#28853
Backport from odoo/odoo#34596closesodoo/odoo#34689
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When a pl promo code is applied, the code is shown in the promo code input.
Before this commit, if the user clicked on "Apply" (so with the same code) it
would remove the pl as it would go in the `if` condition that is supposed to
handle empty code modo to reset pl.
Coming from #34633closesodoo/odoo#34734
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Forward port of a8dfc7fb73
Before this commit, when a transaction has as status 'authorized', the
transactions' confirm page gives an error : 'Oops! There was a problem
with your payment.'
Now, the page gives the same message as when the transaction has the
status 'done' : 'Your payment was successful! It may take some time to
be validated on our end.'
opw-1984325
Prevent singleton error when validating stock.picking with option cancel_backorder
in case there are multiple backorders involved by displaying all the backorder's names separated by commas.
opw: 20337021
closesodoo/odoo#34709
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Have a Tax 24%, included
Have account.voucher with a line reading:
`Price: 64.93; Tax: 24% Incl`
Validate the voucher
Before this commit, the account.move.lines created were wrong and unbalanced
as the amounts that should have been affected by the tax included haven't been
After this commit, the move and its lines are correct and balanced
OPW 2031751
closesodoo/odoo#34784
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Backport of https://github.com/odoo/odoo/pull/34132
The test case of alipay payment is going to failed due to:
1) Now the redirect_url from the return_url is removed in commit :
https://github.com/odoo/odoo/commit/0aefe72b773a21bdd38fdc86779d3030bd5127c6
but it's still it's there in test cases so removed from test case.
2) To make the transaction done it must be in draft, pending or authorised
state but in first test case payment process the transaction state is set to
cancel and in another payment process use the same transaction again to set
it success so before use the same transaction again just set the state to draft.
task- 2005926
closesodoo/odoo#34708
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When the 'before' (resp. 'after') hook is defined on a QUnit module,
it is executed once, before (resp. after) the whole module is
executed. When the test suite is executed several times, tests that
failed in the previous execution are always executed first,
separately from the other tests of their module. In that case, the
'before' hook is executed directly (before the execution of the
failed test), but the 'after' hook is only executed once the whole
module has been executed. This means that a lot of other tests,
coming from other modules, can be executed in the meantime.
In calendar tests, we used the 'before' and 'after' hooks to catch
scroll events. So, when a calendar test failed, and the suite was
re-run, some tests depending on the scroll failed.
To prevent this, we use 'beforeEach' and 'afterEach' hooks instead,
as they are executed before and after each test.
closesodoo/odoo#34932
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
When posting a message (here is the livechat use case),
the _postMessage function can call the callback function.
but this parameter is not mandatory.
If the caller of this function doesn't need a callback function
to be called after execution, the _postMessage function was crashing
as callback is not defined.
This commit fix this _postMessage function by checking that
callback is defined before calliing it.
Pre-required for Task ID: 2028059
Fix Task : 2037048
PR #34917
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1* Allow products access from product_id / product_template_id of sale.order.line
2* Allow use of optional products along rentals and events.
closesodoo/odoo#34170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Put toogle_button or a favorite widget to handle a boolean field in an editable list
click straight up on the widget's button or link
Before this commit, the widget changed its appearence, but the changes were not
propagated to the model. This is because the controller will not force_save if its mode is edit
(to let changes piling up and save everything when clicking save), which is the case
of the editable list
After this commit, following what has been done at 2f5e44d40b
clicking on a widget in an editable list just activates the row for editing
but doesn't change the widget's value
OPW 2033700
closesodoo/odoo#34878
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
previously, when user tried to change the schedule_date, it
was being passed as a string instead of datetime. corrected
that.
Task-2034542
closesodoo/odoo#34873
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The ready code warning timeout of 2 seconds can be confusing since
it is triggered just after the 2 seconds. We can log this message
at the end in order to give the real timeout.
In JS tests, when the ready code takes too much time, a warning is
logged. As a consequence, the runbot updates the github status as a
failure, causing real pain to people who simply wants to merge their
features.
With this commit the warning is changed into an info and the runbot will
be happy.
closesodoo/odoo#34865
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
- Select template type boxed in general settings
- Select show serial/lot number in Delivery slip (in inventory - settings)
- Print the delivery slip with a non tacked product
Bug:
The delivery slip report displayed wrong columns.
opw:2031985
closesodoo/odoo#34852
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Usecase to reproduce:
- Create a MO for 5 final units
- Reserve all the components
- Produce 3 units
- Post Inventory (debug mode)
- Edit/Unlock
- Edit a line to consume to an arbitrary amount of quantity
- Change the product qty and set it to 3.
At this point, the reserved quantity and the quantity to consume
still the same than intialy even if the final quantity was updated.
- Mark as done
Then a move is marked as done withtout quantity done and still have
reserved quantity.
It happens because the _update_raw_move function do nothing if the
new quantity to consume is equals to 0.
The arguments returns in _update_raw_move still exists for override
but are not used by the chang_prod_qty method. It's not possible to
cancel the move and then find its parents in order to log the activity.
opw-2023653
closesodoo/odoo#34471
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previous versions of this action had a domain. It was removed at 2d3e6d7383
Set explicitly an empty domain to force the removal when upgrading the module
Similar to 2d03ed43a5closesodoo/odoo#34581
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Lucas Perais (lpe)