When the purchase model is installed, there are two checkbox with
label 'Can be Purchased'. This error is due the rev https://github.com/odoo/odoo/commit/e945b86d5a61e53a9104ab6cc4ed4a1c060587e4
where we moved purchase related fields from module product to an
inherited view in purchase module.
To fix this, we removed the 'purchase_ok' field that was left in
the product_template view.
Barcode, default_code (Internal Reference), standard_price,
volume, weight fields are not saved when we create a new product.
This is due to the fact that these fields need the product_variant_ids
field to be set, in order to compute their values.
Due to migration in rev https://github.com/odoo-dev/odoo/commit/1aa5bc0fdfa402ac7cccbc3a7203ec5050f6339b
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.
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
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
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.
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.
This drops the backward compatibility with the old API:
- remove method wrappers;
- convert all the remaining old-API calls to the new API;
- remove the processing of _columns, _defaults, _inherit_fields, _all_columns;
- remove all old-API fields;
- implement sparse fields;
- modify the registry to become a mapping model_name -> model_class;
- adapt XML-RPC and JSON-RPC gateways.
Fabien Pinckaers