Note that to copy the workflow, just after creating the state is updated
to draft. The 'New' state is not used anymore in the flow. It could
probably be cleaned. However in this task we only remove the workflows
without changing their behavior to avoid unwanted side effects.
This report is too advanced and/or complex to be a single menuitem. Furthermore the model was a mess and a horn of plenty for bugs.
The class ProjectTaskHistoryCumulative inherits from the class ProjectTaskHistory, and create a view based on the same model.The orginal class defines a compute field 'end_date' which calls a compute method '_compute_end_date' that will either make a simple assignment or a SQL request if the columns is always opened or folded.
As ProjectTaskHistoryCumulative is declare with '_auto=False' the compute method will try to write on this table, which is obviously wrong because we are trying to write on a view.
This leads to erors when trying to edit a project stage like:
OperationalError: cannot update view "project_task_history_cumulative"
DETAIL: Views that do not select from a single table or view are not automatically updatable.
HINT: To enable updating the view, provide an INSTEAD OF UPDATE trigger or an unconditional ON UPDATE DO INSTEAD rule.
or when trying to delete a column which already contains some tasks.
So we removed this these models and view and replaced them by a simple favorite filter in the Tasks Reports
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.
Denis Vermylen (dve)