Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit splits the _content_image method to allow to call the
get response part individually.
This is needed because _content_image call binary_content using current user
access. But in some cases, we need to render a binary content even if the user
does not have access to the target model (typically for public users).
The binary_content is gotten in sudo mode where needed and the result can be
given to the _content_image_get_response.
This will avoid code duplication where the sudo use case is met.
Usage :
This commit prepare the redesign of survey. This _content_image_get_response
method will be called to grant access of background image even for public
users. Other modules will use this new method like elearning (website_slides)
to display karma ranking, etc.
Task ID: '2150291'
PR #43237
Previous versions of this action had a context. It was removed at
odoo/odoo@2d3e6d7383 Set explicitly an empty context to
force the removal when upgrading the module. Fine tunning of
odoo/odoo@9346563009closesodoo/odoo#43319
X-original-commit: 63a5a795a57af0da3b7459e0acd83a247861eaf3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Issue from rim:
In runbot 12.3
- Go to Purchase
- Create a PO with one product line: qty 1 / unit price 1000
- Validate the PO and create the Invoice
=> DON'T VALIDATE THE INVOICE YET
- Go back to the PO, change the unit price to 2000
- Go back to the invoice, validate it
==> the PO is marked as "fully invoiced" because the qty "1 unit"
is counted as "invoiced"
=> we should not be able to change the price of a line that has
already been invoiced, even in draft
Cause
It seems that in all the PO's invoices state, we can edit a PO line.
No restriction?
Solution
Set the line price column to read only when they have a linked
invoice.
OPW-2161477
closesodoo/odoo#42797
X-original-commit: b31c04040a2d7fe83741dec2d3a622487b7e46c3
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
on the portal:
- in Timesheets, when search something, the text of the search must remain displayed
- in Tasks, when search something, the text of the search must remain displayed
- in Purchase Orders, "Sort By" and "Filter By" selectors shouldn't change when going to next page
- in Timesheets, the "Group By" selector shouldn't change when going to next page
closesodoo/odoo#40278
Related: odoo/enterprise#6787
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Move the method `_prepare_purchase_order_line` from 'stock.rule' to
'purchase.order.line'. The purpose is to reuse it in approvals_purchase.
task-2040710
closesodoo/odoo#41046
Related: odoo/enterprise#6702
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Do not update the date_planned of section/note purchase lines when
writing on the order date_planned. Otherwise the SQL constraint
ensuring display lines have no other data blocks the changes.
Fixes#40741closesodoo/odoo#40747
X-original-commit: f3ebab6eb52e3dc8be1f030aecfff348a22f7e09
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose
=======
This fix makes no sense because it exposes some private data to
portal users. Fortunately it was only introduced in the master branch.
closesodoo/odoo#40710
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
NB: if the company_id isn't defined, with_company doesn't change the
environment.
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
Purpose
=======
This is the first huge step to improve the test suite in several ways:
- Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases.
- Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing.
- Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners.
- This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example.
closesodoo/odoo#39868
Taskid: 2075739
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* the employees file apparently never worked as the marital status was
updated before template files were added (respectively
0eb58775c9 and
b60de0db41)
* the purchase template was never updated to reflect the Big Demo Data Changes
(58fc4e4409).
Fixes#39074
Employees file update split off of task 2059779.
closesodoo/odoo#39823
X-original-commit: 80a2f6877378a87638c04061ceaf69965c1707c0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
Steps to reproduce the bug:
- Let's consider product P with purchase_method = 'purchase'
- Create a purchase order PO and puchase 20 units of P to a vendor
- Confirm PO and create a vendor bill VB the 20 units of P
- Validate VB
- The invoiced quantity on PO is 20
- Go to the Purchase report and analyse the qty_to_be_billed
Bug:
The qty_to_be_billed was still equal to 20 instead of 0
opw:2091264
closesodoo/odoo#39493
X-original-commit: b00febedef7826f593bb07c7896595ecce8cae32
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
Steps to reproduce the bug:
- Create a RFQ
- Add a line with a product
- Add a line with a note and save
- Duplicate the RFQ
Bug:
A traceback was raised because the function _select_seller was called on a line
with no product.
opw:2085977
closesodoo/odoo#38921
X-original-commit: 4ffc517d6011c2443f78ba27a608d4ec3815e737
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
* use an editable tree to edit the supplier info
* keep the original forms because they're used in the "vendor pricelist"
menuitem
* updated tour
* change the position of requisition_id
Task-2029380
closesodoo/odoo#35972
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
-Define "g" as the default UoM for a product.
-Make a purchase order with that product.
-Select the "kg" UoM in the order line and a price of 50.
-Check the Purchase tab of the product.
Before this commit:
the UoM of the price created is the default UoM for the product, "g".
This is because it's a related field.
However, the price wasn't converted to the default UoM, it's still 50.
After this commit:
the price is converted to the default UoM, it's 0.05 per "g".
closesodoo/odoo#38688
Opw: 2076722
X-original-commit: 341b568773b28b2bbce02f3532215e9664b318ec
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
**Steps to reproduce**
* Define "Purchase Order" sequence for using date ranges checking "Use subsequences per date_range".
* Change sequence prefix to "PO/%(year)s/".
* Create a purchase order with order date in 2020 (a different year than current one).
**Current behavior**
Got a purchase order with 2019 (current year) number.
**Expected behavior**
Got a purchase order with 2020 number.
closesodoo/odoo#38468
X-original-commit: ce423e6adb6659a1d5885bad158c59b882cb4565
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Install stock and purchase. Make a RFQ for just one product, coonfirm
and receive in one transfer. Click on the delivery (should be only 1).
The picking will display. Open studio, select view, activate list view.
Javascript traceback will popup. Moreover the view of the stock
module will be altered in a faulty way (can be recovered from "Window
Actions", looking for the stock.picking action with external id
"stock.action_picking_tree_all" and removing the last added tree from
"View Mode").
This is caused by studio not detecting all the active views, thus giving
the possibility to add an already active view, because when there is just
one picking all other views are filtered out.
Changing the way the form view is retrieved in case of a single picking
fix the issue.
opw-2076241
closesodoo/odoo#38093
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
*: mrp
product
purchase
stock
Renamed the 'activities_exception' filter to 'Warnings' and moved it
to the bottom of the filters, isolated by separators
Task-2056425
Closes: #36027
- Set Joel Willis (the portal user) as a vendor.
- Create a purchase order and add a line with a variant product, such as the
conference chair (aluminium).
- Confirm the order.
- Then switch user to the portal user.
- In the portal view, go to the purchase orders and select the purchase order.
Before this commit:
the product line does not show the variant, only the base name of the product.
After this commit:
the product line now shows the vendor specific product name and product code.
To set this name and code, go to the Purchase tab of the product, and add a
line for the vendor in the Vendors table, or modify the existing line for
the vendor.
closesodoo/odoo#38082
Opw: 2076962
X-original-commit: c2f2169ab7574c49fa6b544299aab7214b1f4698
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since the commit allowing all list views to be editable, there are some
views in which we need to ensure that certain fields are always readonly.
Affected modules:
- account
- crm
- product
- purchase
- sale
Task 1967602
If SQL, if you do
```display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL```
and `display_type` is `NULL` then you can only have `'t'` because
`SELECT NULL OR 'f';` yields `NULL`
`SELECT NULL OR 't';` yields `'t'`
The check of NULL is not blocking, hence the constraint doesn't work.
closesodoo/odoo#37075
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
To avoid slowing down search like "{relational_field}" contains "{value}"
we always need to return the lazy name_get() for each [_]name_search method
closesodoo/odoo#36735
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
For some reasons, when the `mail_compose_message` wizard tries to
read the name of its source document, the id and the model are
sometimes mismatched as a `purchase.requisition` or a `purchase.order`.
To avoid this we force the `active_model` and `active_id` in the context of `action_rfq_send` to be always referring to the current `puchase.order`.
closesodoo/odoo#37097
Taskid: BugsLogistics.
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
david