This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.
New models are
* mail.activity.type: used to categorize activities. Each type is a different
kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
available for all models using activities; or specific to a model in which
case res_model_id field should be used.
* mail.activity: an actual activity to perform. Activities are linked to
documents using res_id and res_model_id fields. Activities have a deadline
that can be used in kanban view to display a status. Once done activities
are unlinked and a message is posted. This message has a new activity_type_id
field that indicates the activity linked to the message.
This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.
Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.
There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.
Next commits will aim at integrating activities inside main Odoo addons.
Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.
This is a manual forward-port of commit 03ac47b9d7
Currently when someone is added as follow to a document default subtypes
are computed if no specific subtypes are given to the subscription. However
if internal subtypes are set as default those are added to all new
followers. It should take into account customers and shared users and avoid
adding them internal subtypes.
Customers and shared users are not notified of messages using an internal
subtype. So currently there is no information leak. However with this fix
we ensure internal subtypes are not followed by external people even if
no notification is created.
Compared to original commit tests are slightly updated because there are now
default internal subtypes in data. Not in 10.0 and previous versions.
This is needed in order to support use cases where we have several account.move.line on an account_id of internal_type 'bank' inside a single account.move. Indeed, each journal item should be linked to a bank statement line in order to disappear from the bank reconciliation widget and, previously, setting the reference to the second bank statement line was removing the first as both info had to be filled in a single m2o. OPW: 696842
Before this commit, the list of channel members is fetched once, and never reloaded.
So, when a new member is invited, he cannot be mentionned by the autocompletion.
With this commit, we remove the 'members_deferred' from the channel,
which will cause the member list to be refetched next time it is needed.
The model does not actually need this feature, as the hierarchies of packages
are not expected to be deep. Performance wise, updating columns `parent_left`
and `parent_right` may actually suffer from concurrent updates that require
retrying requests.
Before this commit, in anglo-saxon accounting the account of a
vendor's bill line was defined as the stock input account, or the
default account.
With this commit the chain becomes:
- if one: stock input account,
- else if one: expense account,
- else: default account
opw-695167
Declaring the keyword argument `context` in an API v7 `orm.browse_record` can
lead to mixed API v7/v8 inheritance bugs (`context` will be treated as a
function parameter instead of being injected in `self.env.context`). As the
context is already propagated in line 953, we can safely remove it from line
971.
Closes#13115
When the user name entered hasn't an email specified the error message wasn't
displayed in the reset view.
The error message was in e.name, not e.message
There are literals inside a t tag that should be translated but they are never
exported to the pot file because they are inside a t-value attribute as python
code.
Closes#14344
* Added accounts provided following the structure provided by the SAT
this accounts are only the minimal necessary ones, with the objective
to set the first easiest engagement to new users and tags will represent the actual information
from the document linked.
* The name of the tag is the concatenation of tag.code + tag.name, because the account.tag
model have not the code field.
Note: we will need more accounts but some of them for special operations
which are not basic at all, then it is better just propose the operational accounts
once we understand a proper closing process.
* Set the proper user-types on accounts in order to be able to use it with the official reports this CoA
for operational purpose.
* Added nature field and data in tags to allow set this value in electronic account report, and
set this value with data pre loaded, we did not use user.type for this due to the fact that the same user type can have different nature (if it grows for credit or debit), I do not know if this field brakes the stable rule we can discuse about that.
* Assign the account tags with in the Mexican CoA template installation, and with an onchange(account.code) when manually modifying/creating accounts.
Rationale: If the code of the accounts follows the pattern 111.00.00 or 111-00-00 then it will
set the tag 111.00 if the tag exists, if not then this will be ignored.
* Generate an account tag by each second level account in SAT catalog, and assign to the corresponding account.
split SQL query inside the init method of the model
'crm.opportunity.report' into multiple methods (i.e.
_select, _from, _join, _where, _group_by) to bring ease for other
modules to inherit
Closes#14568
When testing the access rights, attachments associated with
archived/inactive records are inadvertently being hidden due to
the default ORM behavior of search.
Patch simplified while merging.
Closes#14366
When `paypal_validate_data` is called without any reference, `tx` is None.
Before the migration, it was catched by a `tx and tx.acquired_id` but it is no
longer the case.
Introduced at f1ac1b12Fixes#13834
- Create a SO, link it to a Quotation Template (e.g. "Odoo Monthly" from
the demo data). Note that the Quotation Template must require a
payment.
- Click on "Preview", then "Accept & Pay" in the website quote
- Pay with Authorize.net
- In the Subscription linked to the SO, change the invoice date to a
date in the past (so it will generate an invoice)
- Execute manually the Scheduled Action "Generate Recurring Invoices and
Payments for Subscription Contracts"
The payment is correctly registered on Authorize (you should receive a
confirmation email), but:
- No invoice is generated
- The next invoice date has not been changed
The issue comes from the fact that:
- `payment_authorize` executes the callback method
`reconcile_pending_transaction` before changing the status of the
transaction.
- The method `reconcile_pending_transaction` cancels and unlinks the
invoice if the transaction is not 'done' or 'authorized'.
In order to solve the issue, two fixes are necessary:
- Switch the status update with the callback (this commit), as it is
already the case for Ogone and Stripe.
- Do not manually call `reconcile_pending_transaction`, since it is
already executed as callback. This avoids two increments of the period
(commit in Enterprise).
opw-694730
1. Setup authorize.net acquirer
Published on website
Order Confirmation: capture manually
Store card: always
2. Buy something on the store => SO gets confirmed
3. Buy again but select the saved card
4. You get a confirmation screen on the website, but the SO is not
actually confirmed in the backend (but it should)
The issue is that the confirmation of the SO is located in the
`form_feedback` method. When paying with a saved credit card, there is
no form filled in since we use a S2S transaction. Therefore, the method
is never called, and the SO never confirmed.
Fixes#14007
opw-693517
Ravi Gadhia