When MRP and Product Extended are installed:
- Define a manufactured product with valuation as 'Periodic (manual)'
- On the product form, click on "Compute from BOM"
Several issues:
- The field "Counter-Part Account" is mandatory
- Account moves are posted although the product valuation is 'Periodic
(manual)'
The problem is that the wizard is originally used for products with
valuation 'Perpetual (automated)', where this behavior makes sense. In
this use case, however, it's an issue.
Making the field not mandatory is not possible without an upgrade of the
module, so this will have to be fixed in master branch. Regarding the
creation of account moves, however, this commit solves it.
opw-697867
The revision
8f48baeda6
broke the ability to search pages in the dialog
allowing to add a menu to the website from the website
(From the website, Content > Edit menu)
as `request.website` was not defined in this case
opw-702020
This reverts commit 8416c2bcfa.
Temporary revert this commit, to have enterprise green again...
Need to replace 'full' args by key in context to don't break override
Need to rewrite account_bank_statement_import_csv from enterprise
In multi company, some followers of a document could be not
readable for a user who has the rights to modify this document.
If the user has the rights to write on a document, he is allowed
to read and modify the followers of this document.
opw:693536
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.
crm.lead model now supports activities. Filters have been added to ease
their management. Mail activities replace the old crm.activity model. All code
related to crm.activity is then removed, including views and custom widget.
Standard activities feature is now used widely in Odoo addons and replace
those custom activities.
A small update is required in website_crm_partner_assign. Now the portal user
can only update or create its own activities aka assigned to him. If he has
an activity assigned to him it is displayed in the opportunity website view.
If not editing the opportunity will create a new activity assigned to him.
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.
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.
From #14704, backport of 03ac47b9
Event with interval > 1 was not correctly computed.
This patch doesn't fix existing event but only the new one created after this fix.
Event 1/1/2015 repeat every 3 months, 6 times
Before this commit : end recurrency = 1/1/2015 + 6 * 1 month
After this commit: end recurrency = 1/1/2015 + 6 * 1 month * 3 (interval)
This commit closes#14332
Fix datetime where the return of rrule is sometime a list,
sometime a set according to the datetime version.
list(set) == list(list) and works in both cases.
Similar fix: #9f09c62
DO NOT FORWARDPORT!!!
An issue occurs when a PO line is updated following a reordering rule or
a MTO rule.
As an example, a product is configured as follow:
- UoM: Units
- Purchase UoM: Box of 25 Units
To reproduce:
- Sell one unit of product, then run the scheduler
=> it creates a procurement for one unit, but since the product is
purchased by box of 25, it creates a PO with a box of 25.
- Sell one unit of product, then run the scheduler
=> it creates a procurement for one unit, find the existing PO line,
round in the purchase UoM (so it gives one box of 25), then add it to
the PO line.
The solution is to recomputed the necessary quantity at the very end of
the process. For a given PO line, list all procurements and adjust the
quantity.
This is a partial fix, since it doesn't take into account the potential
new price of the seller. However, that would require a major rewrite of
this part of the code, since it was originally written for v8 which
handles the PO line quantity recomputation sequentially instead of
batch.
opw-688916
Before this commit, 'select all' into a list view, and use an action that assign
a user_id to all the records will send n² email, because the function send_mail
use active_domain instead of the current record.
Now, we keep mass_mail mode, but simulate the case where we have clicked on
each record one by one and not all the records matching the active_domain.
So we send only one email by record.
How to reproduce:
create a action server "record.write(dict(user_id=env.user_id))"
add this action in context menu
select all records in a list and apply the action server
Before this commit, the parser (date, datetime, float, monetary, ...) was only
called on field from current model, and not on sub field.
Eg: product_id.price was not parsed as float, because product_id != float
This commit add an overiddable function to get all the parsers: get_parsers
This commit closes#14572
_get_partner_pricelist could return both a recordset or an ID.
While the ORM handles both where the method is called, a migration script
relies on an ID being returned.
( migrations/sale_contract/9.saas~13.1.1/pre-models.py", line 24 )
This commit ensures an ID is being returned every time.
The amount (=credit - debit) of the first line must be equal to the total included
to reconcile balanced entries.
Before the fix, it just worked with included taxes because the amount of
the first line was already equal to the total included.
But with excluded taxes, it didn't work because in this case the amount was equal
to the total excluded. Then it raised: "Cannot create unbalanced journal entry"
due to the second line which includes all the taxes.
opw:697129
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
When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py
opw:695616
Pierre Masereel