This commit improves the tokenization process, allowing users
to set the acquirer to save payment data never, always or letting
the customer decide (only implemented in ecommerce for now).
Support for tokenization is improved for Ogone and Authorize.net
This commits also factorizes advanced payment features support
(authorization, tokenization, fees computation) in a generic method
overriden by every provider to specifiy which features are supported.
This process can be used in views to hide/show fields depending on
feature support or in constraint checks.
This commit add s2s communication to the Authorize.net payment
provider, allowing the user to:
- Create a payment token
- Charge a payment token
- Authorize/capture transactions
Since the creates overrides needs some information that do not end up
in the final record, let's avoid warning by removing all non-model
fields from the call to super.
This allows using a modern e-commerce flow where amounts are first
authorized at checkout then captured when the picking is in fact
shipped instead of immediately capturing the amount.
To access this flow, a new selection value is available on the payment
acquirer: "Authorize the amount and confirm the SO on acquirer
confirmation". If this value is selected, s2s/form transactions should
only require authorization to the acquirer; the user can then
capture/void the payment manually from the Odoo backend transaction
form view by simply using buttons.
Since 85bcd6fdd8, the field `paypal_account`
has been removed. The field `paypal_url` cannot be computed correctly
anymore.
This reverts commit 2ab68047c1.
As you open the lots in a raw material move in a production order,
you should not see the temporary stock move lots from the work order.
Also the quantity_done should not take into account those. They will
when they press 'Done' on the workorder.
When posting inventory, the temporary stock move lots on the workorder,
should be transferred to the split move.
For splitting and unreserving, some optimizations are done.
Since 85bcd6fdd8, the field `paypal_account`
has been removed. The field `paypal_url` cannot be computed correctly
anymore. Convert it to a dummy field.
When a database is created, we are not auto-logged in to the new
database anymore because the login passed to the authentication request
is 'admin' instead of the one set in the creation form.
To fix this issue, we used the login parameter from the creation form
in the authentication request. We also set the login field to
required in the create database form view.
This bug comes from rev https://github.com/odoo/odoo/commit/903733a32
This option implies 3 changes:
* a default char field x_name on the new model
* be able to infer the `model` of the ir.model in name_create
from its `name`
* avoid deleting the registry when unlinking *nothing* ; the default
field_id or ir.model ([(0, 0, ...)]) implies an unlink ([(5,), (0, 0)])
that delete the current registry
Courtesy of @rco-odoo
The API of `Registry` has been modified as follows:
- `Registry(name)` returns the registry of the given database
- `Registry.new(name)` forces the creation of a new `Registry` object
- `Registry.delete(name)` discards the given registry
- `Registry.delete_all()` discards all registries
- `registry.setup_signaling()` initializes the signaling for `registry`
- `registry.check_signaling()` returns an up-to-date `registry`
- `registry.signal_registry_change()` notifies that `registry` has changed
- `registry.signal_caches_change()` notifies potential cache invalidation
This merge holds several long awaited improvements for the mail gateway.
It includes
* store email status of notifications emails sent to customers
* display this information on Chatter
* improve bounce email management: track bounced notifications emails, use
message_bounce fields directly in mail and not in mass_mailing
* send emails to assigned user on records
* remove required alias on users while keeping it possible to define alias
on users and use them
* handle emails forwarded to aliases as new threads instead of replies
* do not store needaction for forum and blog posts
* automatically unsubscribe partners that bounce on channels
* some light code cleaning
When anglo-saxon accounting is enabled and the valuation of a product is
'real_time', rounding errors might occur in the price difference between
the invoice price and the product price. It occurs when the product
price precision is larger than the accounting precision.
To avoid these rounding errors, we calculate the difference as the
difference between the price before update and the price after update.
opw-686730
Forum and blog are public models that could have a lot of followers. After
notifying followers of a new comment, discard the needaction information.
For those models email is considered as sufficient. This way we avoid storing
a lot of unnecessary entries in the m2m table between message and partner.
If the 'To' of an incoming email is an alias on another model we now consider
this emails as a forward to a new alias. A use case for this is an email on
a task that should be considered as an issue and forwarded to another alias.
When a user is assigned to a model on a user_id field an email is sent to him
containing a link to the document. This way the user is warned he is now
responsible of the task / issue / lead / ...
Using after commit event notifications emails are now send once the current
transaction is finished. This allows having issues with emails being sent
while the transaction failed sometimes after email sending, but still in the
same transaction.
A small hook is done to allow invitation emails to be sent directly as some
data related to mail.message is unlinked directly in the wizard.
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.
Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.
Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.
This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.
Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.
Previously Return-Path were composed using bounce_alias-<mail_id>-<model>-
<thread_id> . However this may lead to return adresses not supported by
the incoming mail server. We now form the bounce alias using bounce_alis+
<mail_id>-<model>-<thread_id>. Using a + indicates that the right part of
the address is for information and used to manage the bounce. Only the
left part is used for the email routing, allowing the return email to
effectively land in the alias mailbox.
When a new answer comes in a thread the mailgateway finds if the recipients
are linked to existing aliases. This allows notably to check if the author
can effectively contact this alias. Previously only the To was checked.
However we cannot ensure the recipient is contained in To as it could be
in Delivered-To for example. We now check for all possible recipients.
The purpose of this commit is to clean a bit the code related to email
routing in the mailgateway: message_route and message_route_verify.
message_route is now clearly separeted into two categories. First one
handles emails considered as answers to existing threads. Second one
handles emails that have to create new threads, either through alias or
default behavior of the mailgateway.
message_route_verify has been a bit facotrized to simplify the various
overrides that appeared lately in the codebase.
This commit only contains code cleaning. No functional change should occur
due to this commit.
Before creating a account analytic line related to a sale order, check that the sale order is in 'sale' state, i.e. not a quotation, not in done or canceled state.
The issue is that when validating an expense (for example, but it's the same for a timesheet), the analytic account line is created even if related to a canceled sale order which is obviously wrong. This was leading to confusions about what's displayed, what is existing and not displayed and whatever.
This was the behavior before this commit 48ea59d46e
- Activate the option "Track Lots or Serial Numbers".
- Set the outgoing process as 3-step one.
- Create a stockable product for which the tracking is "By Unique Serial
Number".
- Go to Sales > Sales > Sales Orders.
- Create a Quotation for the created product and confirm it. A picking
is generated but it is waiting availability.
- You are sure to have this product in stock so you force the
availability and assign the serial number (001) you want to transfer
in the operation lot details.
- Validate the picking. By doing this, it creates a negative quant in
the origin location (WH/Stock) and it creates a positive quant in the
destination location (WH/Packing Zone). The two quants are linked to
each other.
- Go to Inventory > Inventory Control > Inventory Adjustments.
- Create an inventory in WH/Stock for all products and set it in
progress.
- You want to correct the negative quantity you have so set the real
quantity of product B to 0.
- Validate the inventory and you get the following warning: "The serial
number 001 is already in stock.Otherwise make sure the right
stock/owner is set".
We should allow a quantity larger than 1.0 temporary, so it allows the
system to reconcile the quants.
opw-685825
mail.mail and mail.thread have methods to decode headers. This commit
move them in mail tools. It is indeed simplier to have all email tools
in the same file. Moreover they have been renamed to avoid confusion
with standard library methods: decode and decode_header already exist.
* decode in mail_message is now decode_smtp_header
* decode_header in mail_thread is now decode_message_header
A method to data from references is also moved into tools. A regex was
already defined in tools. Now the method using it is already put in tools.
Mailgateway will now simply call this method.
category was changed to "Website" so it'd appear under the website
category in the store, but it needs to be "Theme" otherwise it doesn't
appear in the "Choose your theme" menu after installing website.
Previous version of the test was actually not correct. Mailgateway was not
considering references as in-reply-to when trying to find answers that have
to be considered as a new thread instead of an answer to an existing thread.
Purpose of the test is actually to be sure that answers considered as a new
thread have no parent_id set. Otherwise you may have threads linked to
messages belonging to other records, leading to access right issues. Moreover
if this email begins a new discussion thread it makes no sense to have a
parent message set.
A new test is written to better simulate the test case. It sets a message_id
containing reply_to which is the way odoo uses to indicated that answers
to a message have to be considered as new threads. This is used notably in
mass mailing for example.
We already know that a user is a shared user. This means a partner created
for a customer for the purpose of sharing data. However sometimes it is
interesting to know that a given partner is a customer or a partner linked
to a shared user. This will be used notably in the Discuss app.
Thibault Francois