When the quantity of a purchase line id is changed, the unit price is
set to 0.0 if the PO partner has a seller line on the product and the
quantity choosen on the line cannot get a seller.
TASK-34233
In purchase we add a stat button that counts the number of purchase
orders linked to the product.
In this commit we change this count to count the quantity of products
linked to a purchase order.
We basically do the same thing with the stat button of sale (sale
orders) and mrp (manufacturing orders).
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes#25629
This will allow to use the same core for all intrastat reports and benefit from the dynamic financial reports engine.
Incoterms have been move to account, as we want to provide a light intrastat report for people not having the stock app installed
Was task: 35850
Was PR #23805
Purpose
* use the new notification template allowing to display the payment button
only in emails;
* reorder the fields definition to ease the reading;
* slightly clean the email body using a maximum of div and br tags as it
seems better integrated with Odoo edition capabilities;
This commit is linked to task ID 1860049 and PR #25824.
Commit e38ed7c780 moved code related to purchase, stock and
purchase_stock in order to clean module dependencies. However probably due to
some wrong manipulation notification layout was reset to an old removed
layout. This commit fixes it.
Task 40692
Various changes to import/export (mainly) UIs:
* default to excel & "full" (non-import-compatible) export
* auto-detect encoding of CSV using chardet
* remember column -> field mapping after having imported a file (useful
for repeated imports where auto-matching failed)
* better handle localised booleans & column names
* automatically select source list view's fields when exporting
* better integrate import templates feature and add a number of templates
When a PO is confirmed, cancelled, set back to draft and confirmed
again, the push rules don't apply because the PO lines have
move_dest_ids. So we remove those move_dest_ids from PO lines, to allow
push rules to be applied on the newly confirmed PO.
OPW-1859363
Usecase to reproduce:
- Create 2 sequence for PO(one for each company)
- Create a product with dropshipping
- Connect on the demo user with an active company different than the
admin company
- Create a SO for this product
It will create a PO with the admin's company sequence.
It happens because _run_buy use a sudo since SO user don't always
have the purchase and inventory rights. However the company is not
forced and thus the used company for sequence is the admin company.
opw-1860802
Purpose
=======
Currently the discount mechanism is not implemented in the purchase module.
This limitation is could be avoided if the _compute_amount arguments could
be overwritten.
While waiting the feature to be implemented in master, we simply introduce
a hook method to allow an easy inheritance of the argument values.
Closes#11235
PS: Also move compute methods under the fields definition to follow
the coding guidelines
The action 'account.action_invoice_tree2' has been changed into a server action, so we want to open the tree view of invoices by modifying some values of the action we should now use the xml reference 'account.action_vendor_bill_template'.
Additionally, the help tooltip is now completed as would do the server action
Let's consider a Sales user U with no access to Purhcase
Steps to reproduce the bug:
- Create a SO with one line with the drop shipping route
- Validate the SO
Bug:
A access error was raised because the user has no access right on
Purchase.
opw:1851301
purchase_requisition install stock, but when doing services you might
still want the option. This option was only display when stock
is installed. This commit changes this to make it visible when
purchase is installed.
The option is better visible and installing a new apps, then
hidden (or difficult to find).
Purpose
=======
The method _name_search and _search add support to search as another user.
All the overrides of name_search and search redefine the behavior of the search.
This bring inconsistencies as the result of a call to _name_search and name_search
could differ on certain modules, which is not acceptable.
Specification
=============
Example:
~~~~~~~~
If the name_search method is overridden to search also on the driver name,
then calling name_search with a label 'JF' will return all the cars with a name containing
'JF' or all the cars with a driver name containing 'JF'. Let's say that we have a ir.rule
preventing a user to read the cars of another company. Then the call to name search only returns
the cars satisfying the previous condition AND belonging to his company.
Now, we want to overpass this constraint. We call _name_search with the attribute name_get_uid=1.
Then the call to _name_search returns all the cars from all the companies with a name like 'JF',
but nothing is done about the driver_name.
Example of wrong search redefinition on a model
-----------------------------------------------
@api.model
def name_search(self, name, args=None, operator='ilike', limit=100):
domain = args or []
domain = expression.AND([domain, [('name', 'ilike', name)]])
partners = self.env['res.partner'].search([('name', operator, name)])
if partners and name:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partners.ids), ('driver_id', '=', False)]])
rec = self.search(domain, limit=limit)
return rec.name_get()
Example of correct search redefinition on a model
-------------------------------------------------
@api.model
def _name_search(self, name, args=None, operator='ilike', limit=100, name_get_uid=None):
domain = args or []
domain = expression.AND([domain, [('name', operator, name)]])
partner_ids = self.env['res.partner']._search([('name', operator, name)], access_rights_uid=name_get_uid)
if partner_ids:
domain = expression.OR([domain, ['|', ('driver_id', 'in', partner_ids), ('driver_id', '=', False)]])
rec = self._search(domain, limit=limit, access_rights_uid=name_get_uid)
return self.browse(rec).name_get()
The same logic should be applied on the overrides of the search method.
We want to break the dependency between stock and purchase
for our furtur developpement. For more modularity, a new
bridge module 'purchase_stock' is created.
This commti move part of business code, views, data, ...
related to stock management from purchase into purchase_stock
without changing any feature.
Task #47927
Before that, the following scenario (tested in purchase/tests/test_anglosaxon_valuation_reconciliation.py) failed:
- create a PO
- change of currency rate
- create and validate vendor bill in foreign currency
- receive goods
- change of currency rate
- return the goods
- change of currency rate
- refund the bill
At the end of it, both invoices (bill and refund) were not in 'paid' state, but they should have been! The anglosaxon stock valuation code had some issues in the way it managed currency rates. The main one was that we converted the computed valuation_price_unit variable in company currency using the date of the invoice as a reference, which was wrong in case the invoice was a refund, as it should then use the date of the valuation for this. This problem caused the code to detect an exchange rate difference between refund and valuation as a price difference, hence generating a line in the price difference account, which caused the debtor account line of the associated account.move to be wrong, and hence impacted the residual field of the invoice ("amount due", in GUI). Finally, as this field contained an inconsistent value, the refund invoice was not marked as paid after reconciling it with the original one.
Solving this needed to refactor the code quite a bit, so that we don't convert everything in invoice currency in the end, but rather do it directly everytime we compute a part of valuation_price_unit. The test had also to be partly re-written as it was too naive in the way it used currency rates, we needed something closer to a real utilisation of the program.
On purchase orders, the scheduled date is mantadory. This date is computed from
the purchase order lines and hidden. If there is no purchase order line, the date
stays empty and it's not possible to save the PO.
This commit uses the order date as scheduled date if there are no PO lines
Before that, the following scenario failed due to FIFO handling of stock:
- make PO 1 for 10 x product A at 10€/piece, receive and invoice everything
- make PO 2 for 10 x product A at 20€/piece, receive and invoice everything
- refund and send back PO 2
=> With FIFO handling, it means the valuation corresponding to the return of product A consists of the first received products, hence 10x10=100€. The credit note, though, was made with the price of the invoice (200€) and did not (because of a too simple check) use the price difference account to post the missing amount (100€).
Test test_fifo_anglosaxon_return (purchase/tests/test_stockvaluation.py) failed because of that.
- Create a product FIFO / Real-Time valuation
- Create a PO with 1 unit, validate, receive the picking
- Create the corresponding vendor bill, but do not validate
- Unlock the picking and change the received quantity to 0.0
- Validate the invoice
A traceback because of a zero division occurs.
When searching for the stock moves linked to the PO, we should filter
out the ones with a zero quantity.
opw-1843543
Steps to reproduce the bug:
- Enable multi companies and multi-currencies
- Multi company: Your Company and Test
- Users: Admin and Demo
- Login as admin user with the current company: Your Company
- Allowed companies: Your Company, Test
- Login as Demo user with the current company: Test
- Allowed companies: Test
- From the admin user with the current company: Test, do the following configuration in the product,
- product: iPad mini, select vendor: Delta PC with price $100 with company: test, currency: USD
- Change the admin's company from Test to Your Company, do the following configuration in the vendor,
- vendor: Delta PC, set supplier currency: EUR and payment terms: 30 Daya Net Payment
- Log in with the demo user
- Create SO for that product by selecting routes: Make to order and Confirm it.
- Open the PO which is generated from this SO
Bug:
The Currency and payment terms were set with the data set for Your Company
Excpected behavior:
Nothing is set for supplier currency and Payment terms as nothing is set for the company: Test
Closes#24564
opw:1841379