This reverts commit cbc760acb8.
The reasons we put the product name and description is in the SO line:
- users want to be able to change the description in the printed quotation
- product is in user lang, description+product_name is in customer lang
That commit breaks what was a good behaviour
- sales_team: Rename Next actions into Next activities on CRM dashboard.
- calendar: In meetings, reminder config, display 2 fields "Unit" and "Amount" inline with the string "Remind Before".
PURPOSE:
When users try to delete records in the database, we usually warn them about the possible damage they would cause by asking them to confirm this is what they want to do (just in case you misclicked for example)
Unfortunately, that feature wasn't implemented everywhere, at least no in the export window, which means a user can remove ir.exports records without having to confirm that's indeed what he wants to do.
This got worsened by the fact, in the export window (like pictured in the attachment), the "Save field list" button is less than 10px away from the DELETE button, meaning you could really remove 10min of your work (or worse, anybody else's work as we don't have any specific record rule on that) in one click
As this button leads to a void form view without context it is not
really usefull. As creating new records is achieved using aliases
there is no real need for a New Task/Issue/Note button.
mail/new controller is kept for compatibility but should be removed
before v11.
- sale: Improvement in quotation/so line's description
Currently, quotation/so line's description shows product's name with description.
It should show only description of product if description is there else show name of the product in backend views.
- sale: show product with description in sale report
Due to change in description of quotation/SO line, sale report is affected. Fixed it.
- website_sale: show only description in cart lines
Due to previous commit, cart lines shown with product and it's description as a quotation/so line's name.
When we create order from frontend, quotation/so lines' name field takes product name and it's description.
It should only take description if description is there else product name. Fixed it.
- purchase: Improvement in RFQ/PO line's description
Currently, RFQ/PO line's description shows product's name with description.
It should show only description of product if description is there else show name of the product in backend views.
- purchase: show product with description in purchase report
Due to change in description of RFQ/PO line, purchase reports are affected. Fixed it.
Case 1: To check order date of purchase order and schedule dates of shipment and purchse order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a company level set Purchase Lead Time
Case 2: To check order date of purchase order and schedule dates of multiple purchase order line of the same purchase order,
we create two procurements for the two different product with same vendor and different Delivery Lead Time
Case 3: To check order date of purchase order and schedule dates of shipments and purchase order,
- Configure lead times:
- At a product level set Delivery Lead Time
- At a route level set delay of push rules
Detailed Use Cases
==================
Consider today's date = 2016-04-21 ( date_planned of procurement = today's date + 10 days)
CASE 01:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Configure your company data
---------------------------
Purchase Lead Time : 3.00 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 15.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-23 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 02:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Create another Product
----------------------
Name : Product B
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 2 days
Procurement Request
-------------------
Warehouse : YourCompany
Product : Product A
Quantity : 10.00
Planned Date: 2016-05-01 00:00:00
Procurement Request for second product
--------------------------------------
Warehouse : YourCompany
Product : Product B
Quantity : 5.00
Planned Date: 2016-05-01 00:00:00
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-04-28 00:00:00
Order date: 2016-04-26 00:00:00
Schedule date of purchase order line for product A: 2016-05-01 00:00:00
Schedule date of purchase order line for product B: 2016-04-28 00:00:00
Incoming shipments schedule date :-- 2016-04-28 00:00:00
CASE 03:
========
Create Product
--------------
Name : Product A
Product type : stockable
Buy : True
Make To Order : True
Delivery Lead Time : 5 days
Warehouse configuration (YourCompany)
-------------------------------------
Incoming shipments : three steps
Routes
------
YourCompany : Receipt in 3 steps
Push Rules:
-----------------
WH: Input -> Quality Control :-- Delay : 2 days
WH: Quality Control -> Stock :-- Delay : 2 days
Create Procurement:
-------------------
Product : Prosuct A
Quantity : 5.000
Warehouse : YourCompany
Procurement Location : WH/Input
Schedule date : 2016-05-01 10:30:43
Notes : 'Test scheduler for RFQ'
Confirm Purchase Order
Result
------
Purchase Order :-- Schedule date: 2016-05-01 10:30:43
Order date: 2016-04-26 10:30:43
Incoming shipments schedule dates :--
In type :-- 2016-05-01 10:30:43
Internal type 1 :-- 2016-05-03 10:30:43
Internal type 2 :-- 2016-05-05 10:30:43
Before the fix:
When creating a new session with Cash control POS then it was impossible to close the session.
After the fix:
The same flow as in 9.0 when closing a session
opw:691517
=======
purpose
=======
By default, the sequence is 0 for all new attributes and the result is messed up. The product attribute values are not ordered in the same way in a list view.
That's because the results are not returned from sql ordered by id if the sequence is the same. Just add this in the order definition will remove the non-deterministic behavior.
The JS widget is simplified, which a cleaner approach.
For the rendering part:
- the server reads the data
- the JS widget formats/organizes the data
- the template renders the data prepared by the widget
Quick summary of the modifications:
1. The associated field is a text field which contains JSON-encoded
data. The data are read server-side, and not client-side anymore.
2. The widget is an AbstractField, no need of ReinitializeWidgetMixin
anymore. No use of the FieldMonetary widget directly, but use a similar
format_value instead (inspired by ShowPaymentLineWidget).
3. Data formatting (call to format_value) is done in the widget, not in
the template anymore. This seems to be the standard way of doing, since
lunch was the only module where format_value was in the template and not
in the widget.
4. The addition of an order line is cleaner since all necessary data
are prepared server-side.
The javascript tour (test) will verify the total amount based on sale
price of the product without taking taxes into account.
However, if any l10n_* module is installed and defined a default value
for product taxes, the test will fail this check.
Model account.invoice has "date" and "date_invoice" fields.
("Accounting Date" and "Invoice Date" respectively)
The dashboard was incorrectly using the "date" field from account.invoice to
look up the corresponding invoices.
NOTE: account.invoice.report renames the date_invoice to date and doesn't use
the date field from account.invoice, it can be very confusing.
For invoices analysis(account.invoice.report) add this month and last month
filters in search view and set appropriate default filter on dashboard actions.
For pipeline analysis(crm.opportunity.report) add this month and last month
filters in search view and set appropriate default filter on dashboard actions.
For activities analysis(crm.activity.report) add current month and last month
filters in search view and set appropriate default filter on dashboard actions.
Set sale order and production order link on Mo. override make_mo method in sale_mrp module to set sale order reference in mo.
.and to find final destination move, i created one common private method to get parent move.
MESSAGES TO DISPLAY:
-Set a Reordering Rule (stock.warehouse.orderpoint) that creates a manufacturing order:
"This manufacturing order has been created from: OP/00001"
-Create new Sales order of manufactured product , there will be a Source Document with procurement of that Sale Order
"This manufacturing order has been created from: SO001"
-create MO for BoM items of the product, there will be a Source Document with procurement of that Manufacturing Order
"This manufacturing order has been created from: MO/00001"
Previously we had 'Inventory at Date' (debug mode) and 'Inventory Valuation'
Both have been merged into 'Inventory Valuation' that pops up a wizard asking
whether you want the current one or the one from a specific date.
Depending on which one you choose you will get either report from the previous
menus. (stock.quant or stock.history model)
* Do not assault the user with a full traceback on bug, but indicates
an error occured and allow him to toggle the traceback
* Automatically scroll the traceback to the end (better for python
errors)
* Propose the user to report the traceback by using a new "Copy"
button which correctly copies the full error + traceback
'issue_ids' has a domain, so all the issue a folded
stage are not taken into account for statisfaction
percentage.
So replacing the field with a search call solve the
problem.
When a user has access to a quote (because he is follower) but he is not
in the same company than the customer, an access error can occur on the
the rendering of the partner field.
We use the tokenized link instead, which will read the SO as a superuser
to avoid this situation.
opw-691740
Currently when using a language on the website, the following is done in
this order to choose which one will be used:
1) use a language code if present in the url (eg. /fr_BE/),
2) use a language similar to the one in the url,
3) use a previously choosed language (saved in cookie),
4) use the browser language if available on website,
5) use a language similar to the browser language,
6) use the default website language
When a bot is requesting a page, he could either not specify a browser
language (en_US is set as default) or sometimes specify english
erroneously.
In these instance, we will then never use the default website language
if an english language is installed.
This fix changes this behaviour so if a bot is visiting a page, the 4th
and 5th steps are skipped and the default website language is used
instead of using the browser language.
closes#14033
opw-690910
Yannick Tivisse