When applying the accounting configuration wizard,
the `currency_id` was being re-written on the company,
even if there was no change (if the currency remained the same),
because of the related.
This leaded as well to the re-write of the company currency
on all journal items, because the `company_currency_id` on
`account.move.line` is a related to `company_id.currency_id`as well,
and they were being recomputed due to the above re-write.
Meaning, when you had a bunch of journal items, applying the
accounting configuration wizard could have take a while.
opw-672400
This is related to 3d58cd1ca2
`compute_all` indeed does expect ids, and not browse records,
but it expects a list of ids for the `ids` parameter, or a single
id, but not `False`.
Besides, `line.tax_id` is a many2many, despite the fact
its naming seems to say otherwise, and therefore `.ids`
should be used in order to pass all the taxes of the line,
not just one.
Apply the same domain which is appled in the form
view, which was redefined during the 9.0 accounting
refactoring (c04065abd8)
This is following the forward-port 51774f2a45
opw-672321
Introduced by 5bb64d40d0. Before doing
anything we should first ensure that the quantity keypress event targets
body (and that it is a number, but that's less important). Before this
we didn't do that and thus the _display_no_edit_mode_warning was given
when people where just typing in the associated thread of a picking.
opw-672350
This is a technical field corresponding to the discount amout to apply on a
ticket from a pricelist. As no form view for event.ticket was defined before
we added one to customize it.
This commit introduces "Sub-task", a concept remotely similar to
the "delegated tasks" available in version 7.0, but covering a
more specific and narrow scope.
Activating Sub-tasks
--------------------
Sub-tasks are made available within any project by configuring
a "sub-task project" in the project settings. This feature is
considered low-level and technical, and only accessible with
"Technical Features" enabled.
The "sub-task project" may be the project itself.
Using Sub-tasks
---------------
Conceptually, a sub-task represents the allocation of a part
of the scope of its parent task. Multiple sub-task levels
are possible.
Once activated in project settings, a new "Sub-tasks" smart button
will appear on the task form, giving the option to view and
create sub-tasks. In addition, a new field "Sub-tasks Hours" will
appear next to the other computed "Hours" fields, representing
the total hours allocated to sub-tasks.
(Technically, the sum of the maximum between the planned hours
and spent hours of all sub-tasks, with spent hours always used
when a task is closed)
These sub-task hours will be dynamically subtracted from the
remaining hours of the task, and will therefore affect the
task's progress as well.
Upon creation, a sub-task will inherit the link to the
original sales order and procurement from its parent task, and
will by default be assigned to the "sub-task project" set on
the project of the parent task.
Enhancement
-----------
The kanban view for tasks will now display a color-coded label
with the number of remaining hours, whenever the percentage
of remaining hours is below 20% (orange=20%-, red=1%-).
Note: This is a forward port of the commit 9eac32beea
- RPCs to load fields_views, fields and filters are batched for optimization
purposes.
- Those data are now stored in a JS cache.
- Views API has been refactored.
Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
A special case for X2ManyKanban views was handled in the Kanban view itself.
This commit makes the X2Many case identical to the general case by setting
options.action_buttons to true if the X2Many field is not readonly.
When a stock move was created in a picking with a product set with
a unique serial number existing in the stock of a specific owner.
If the owner was not specified for the stock move then a wrong message
was raised "The serial number 00005 is already in stock.". But the real
problem could come from function quants_get_preferred_domain which didn't
find the existing quant due to the fact that the system didn't check in the
right stock(owner). A new quant was then created with the existing serial number.
And a wrong message was raised.
opw:671783
When searching for a dropshipping route, we need to access the field
`picking_type_id`. If user is not allowed to read it because of the
access rule `stock_picking_type_rule`, he will get an access error.
opw-668926
* This commit adds an easy access to products and variants from the app switcher / root menu, similar to what exists for contacts.
* Move an action to view stockable products to stock, as it is only executed from stock.
Before the patch:
- product A, with optional product B and C
- buy A with B and C as options
- buy (again) A with B and C as options
=> existing line A,B,C is incremented
- buy (again) A but with only B as option
=> existing line A,B,C is incremented
This was wrong as a new line should be created instead without option C.
Side note: this should probably removed as confusing to have duplicated lines
and has no interrest to keep the link.
* _cart_find_product_line
The method _cart_find_product_line is always called with only one record.
The fact that the return statement was inside the loop confirms the for loop is
not useful.
The method will now return recordsets instead of ids.
Convert the overrides to the new API for cleaner code and avoid old-new api
headhache.
Side note: the website_sale_option override logic is very counter intuitive and
should probably be refactored.
* _cart_update
Add ensure_one to be sure working on only one sale.order.
The method is always called on only one order and does not make sense to be used
on multiple (is the action that is done on one line of the cart).
The return format is the updated line without link to multiple orders.
Remove the for loop and assume self is only one order.
- remove field complete_name
is the same as the ORM field display_name, compute the name_get
- website_publish_button is duplicated
- write outdated, according to TODO (field color already renamed)
- Instead of open_website_url, should use website_publish_button
- styles, style_in_product, attrib_encode: are no longer used in templates
- remove unnecessary rebrowse
This check was added at d3678bf5 either
- to prevent browsing as public user (wrong as always browsed with SUPERUSER_ID)
- to refresh fields of the record (I find your lack of faith in the cache
invalidation distrubing)
- remove get_pricelist method
equivalent to call request.website.get_current_pricelist
The pricelist in the context is only useful when computing the price of the
product.
Do not modifiy request context but only a local copy.
active_id is only used for the computation of the extra price from variants
If the fixed quantity was higher than the produced quantity, the quantity of the
manufacturing order was used for the byproducts instead of the one specified on
the BoM.
This bug was due to the computation of the subfactor (`_get_subproduct_factor`
in mrp, because I love the modularity) that was computing remaining quantity,
only considering the variable quantities cases.
In fixed quantity, the MO quantity being lower than the byproduct quantity, it
was never fully produced.
Corrected the test to correctly check the quantities and handle the usecase with
an higher quantity in fixed byproduct.
Added a field subproduct_id on the stock.move object that allows to easily find
the attributes of the mrp.subproduct item without making hacky (and probably
wrong in case of more than one byproduct) search to find it back.
Closes#8031
Otherwise, when uninstalling the `purchase` module, this
menu is not deleted, while it should.
Besides, there is no reason to set `base.` to this xml_id:
It's not used by any other module.
opw-672130
In the backend product.product records are not just ordered on their
name, they are first ordered on default_code and then on name. The POS
should order records the same way.
opw-672284
In communtiy, the order of the accounts shown in the reports
didn't follow the order written in the legend(How account type affects your reports?)
Adviser > Chart of Account > create
opw:669270
Odoo Translation Bot