- Replaced order date by confirmation date in sales order list view
- Added confirmation date in Sales order PDF report when it is not in 'draft' or 'sent' state
- Calculation of expected delivery date should be based on sale order date
* Share code between website and backend
* Do not do a [100ms - 500ms] RPC on each app change in the backend
but do it only if the planner is asked to be opened
* Use the Dialog class so that the planner is not broken
* Simplify/optimize code, use standard conventions, lint files, ...
This reverts commit 6d9c59f348.
This commit is breaking the enterprise/master branch because the method _get_delivery_methods takes 5 seconds to be executed with some delivery methods. Now, instead of having 1 delivery method displayed, the admin has all the delivery methods in order to be able to publish/unpublish them. As this method is called for each carrier, the phatom js tour takes more than 15 seconds to display the page /shop/confirm_order in the ecommerce, with is more than the timeout threshold.
I revert this commit while waiting to find a proper solution.
Push and procurement rules are some difficult concepts to understand.
Add some tooltips :
Push Rules tooltip :
When a move is foreseen to a location, the push rule will automatically create a move to a next location after. This is mainly only needed when creating manual operations e.g. 2/3 step manual purchase order or 2/3 step finished product manual manufacturing order. In other cases, it is important to use pull rules where you know where you are going based on a demand.
Procurement Rules :
The demand represented by a procurement from e.g. a sale order, a reordering rule, another move, ... needs to be solved by applying a procurement rule. Depending on the action on the procurement rule, this triggers a purchase order, manufacturing order or another move. This way we create chains in the reverse order from the endpoint with the original demand to the starting point. That way, it is always known where we need to go and that is why they are preferred over push rules.
normal mode: Importing only regular/basic fields from source file
advanced mode: Importing any related fields from source file(i.e. if detected pattern in header like '<relational_fieldname>/<fname>')
- Rename following checkbox "Show all fields for completion (advanced)" in "Show fields of relation fields (advanced)"
- If the import file contains a column with a field of a relation field, show the column label in the preview, even if "Show fields of relation fields (advanced)" is not checked > to make it less confusing when importing advanced files (e.g. products with attributes)
Purpose:
On a list view (Ex: the invoices list view), if a column is a currency column (Ex: total amount), it makes no sense to display the aggregate (Ex: sum) if the records contains several currencies.
Spec:
Don't display the aggregate of a column if a least two records are in different currencies.
When a column holds more than 40 records tooltip indicates 40/<record_number>.
However this is not really helping. What is interesting is the total number
of records.
Kanban state values are different from their visual display. When searching
on kanban state it is not easy to understand the link between the label
and the color. We now set the label as the color to ease matching and
searching. However in kanban view labels can be defined on the stage
itself. This way searching is done on the color while working with
tasks and issues in kanban is done using business meaning defined on
the stage.
Purpose:
What is the purpose of hr_timesheet_sheet ? Because it is installed when you install project_issue_sheet and you have a lot of unnecessary menus + ugly view of timesheet grid. For example in Timesheet menu: My Timesheets, All Timesheets, My Current Timesheets, My Timesheets, Detailed Activities (still timesheets), Timesheet App.
- Extend 'account' method and not '_prepare_layout_values' to add
document count. This avoid useless 'search_count'.
- Make the 'active' page working, by passing 'page_name' to the template
- Uniformize the pages when no document are available
website portal now provide mecanism to sort and filter the
paginated document on the portal pages.
All portal module now use this mecanism, like they do for
'archive document' and 'pager'.
A generic template was added in website_portal. To use
it, renaming variables in method controller was required
to make it as generic as possible.
Some style cleaning was also done to make portal pages
consistent.
In the pivot view, when the user select a new field to drill down, the
previous dropdown menu displayed all the groupable fields as valid
choice. This commit disables all the fields that have already been
selected. It means that they will be greyed out, and inactive in the
UI.
Stop using ugly code for ace editor.
* Really close the ace editor by changing its display property thanks
to the dedicated do_show and do_hide method.
* Make the common part of ace editors (website, web_studio) consistent
so that the extensions are really small.
* Do not do RPC to retrieve data already retrieved (now, there is only
one unique RPC when the editor starts an one RPC per view changed
on save).
* Fix born-dead code so that the website editor starts automatically
if the URL contains its associated hash and loads the correct view
* Better handle errors (previous behavior only worked partially and
only on chrome):
- Jump to the error line and make it red.
- Do not open a Dialog with mostly incomprehensible message but
allow to open it on click of the error marker.
- Do not save any changed file if one contains an error.
- Do not allow formatting a file if it contains an error (show the
error instead).
* Do not use different routes to get the same content (remove the
/website/customize_template_get route as it returns the same
content as /web_editor/customize_template_get route). Note: in
a further commit this route will be refactored.
* In a general way, use consistent method names and behaviors /
comment the code / lint files / ...
* Open the code to extensions (so that it may later load other data
than XML).
Note: this refactoring allowed to fix bugs in previous odoo versions
but this commit message will not detail them.
To have the right sign, amount = debit - credit
Before the fix:
-Create an invoice in another currency than the currency of your company
-Link the invoice lines to an analytic account.
-Validate the invoice.
Bug:
The analytic lines have a negative amount in the amount currency field
which was a bit stange as it is the opposite sign than the amount in the company currency.
opw:692557
When an asset is set as Prorata Temporis, with a one month period, the
first depreciation amount is computed on the basis of the remaining days
in the purchase year. This doesn't make sense for a monthly
depreciation.
This commit makes the distinction between a monthly and a yearly
depreciation. In the case of a monthly depreciation, the remaining days
in the purchase month are taken into account.
opw-690034
Backport of 0a3899b72c
The fiscal year start date should be taken into account when calculating
the depreciation amount in case of prorata temporis.
opw-678072
Backport of e69d9b8b7d
Steps to reproduce:
- Create a Sales Order with 2 product qty
- Keep Delivery Method as DHL International
- Confirm
- Open Delivery Order
- Edit Qty of the Delivery Order
- Change Carrier (any integrated)
- Validate the transfer
- Process the backorder
- Edit and change the Carrier to normal or free delivery charges
- Validate
Bug:
The price of the free delivery charges was not recomputed and kept
the carrier price set on the SO.
Fix:
When the price of the carrier is "fixed" or "base_on_rule", the price must
be reconsidered in case of change.
opw:691224
Fabien Pinckaers