1. Add an accounting configuration option
"Assets management & Revenue recognition"
2. Deferred revenue account not set by default in product
- Create new Deferred Revenue Type
- Create new product and assign this "Deferred Revenue Type"
you can see in income account there is nothing set. Actually
when we select revenue type then in income account system
have to set "Deferred Revenue Account" which we set on revenue type.
Otherwise, if we create invoice for this product then system will
by default take the income account from product category.
3. Change word Depreciation to Revenue :
The current test in landed costs puts landed costs on outgoing pickings.
It is a bit weird as they are put on incoming shipments normally. It checks
if the lines of the landed costs have been calculated well, but not if the
amounts/accounts/... on the account move and account move lines have been
calculated correctly. It should also check the entries created when some
part is already out and when we create negative landed costs. (in order to
be able to revert them)
Scenario :
- Two new products without stock as is done in current test in real-time
valuation,...
- Both products are received
- One product goes out (or a part of the quantity)
- A landed cost is created for the incoming picking
- Check that the journal items created, have the correct amounts and that there
is a part that went out and is put on the out account
- Create a negative landed cost as the first landed cost was a little bit too high
- Check again that the journal items created have the correct amounts
The commit adds a "Refund" field on the stock move, in the module
sale_stock. This allows to decrease the quantity delivered in the
associated SO, and therefore to generate refunds more easily.
This commit fixes two problems with the dashboard:
- The function prepare_dropdown_menu() has been removed by commit 002660,
breaking the include in dashboard.js, and thus the 'Add to Dashboard' feature
wasn't appended to the FavoritesMenu.
- The code to render the dashboard didn't correctly wait for the action
manager's deferred to be resolved, which produced a traceback when they were
a Kanban or List view in the dashboard.
1/ ISSUES WITH BADGES:
Go to menu Employees > Badges > Select any Badge from kanban View.
Click on "GRANT THIS BADGE" button.
- When you grant a badge, the description field is not at the right place.
It should be below the employee field
- Badges Form View: "Granted Employees" should be a stat button with a counter
- Badges form view is broken, field label/values are not at right place
2/ ISSUES WITH CHALLENGES:
Go to menu Employees > Challenges
Challenges Kanban View
- Image Avatars are too big, make it smaller.
- Challenges Form View > Advanced Options : fields Report frequency, Report Template
and Send a Copy to are ugly
- add or fix decorators on methods
- fix most compute methods (wrong dependencies)
- revert changes in `eval_context` of `ir.actions`
- various code simplifications and improvements
- migrate methods that were not
- ir_qweb: modify `QWebContext` to take an environment instead of `cr`, `uid`, `context`
- ir_qweb: convert `AssetsBundle` to use new API `env`
- ir_ui_view: use decorator `multi` on method `read_combined`
- ir_ui_view: ensure that method `render` is never called with an xml_id
- ir_ui_view: factor out part of the `ormcache` key of method `_read_template`
1/ Add a stat button with history of activities (count of activities) on
the Customer form view
2/ Activity reports: When clicking on the list view, there shouldn't have any
group by (remove the Salesperson/leads group by)
Prevent drag'n'drop in the following cases:
- Group by field is read-only
- Group by field is a date or datetime
This is necessary to avoid, for example, changing the state of a sales
order or an invoice without going through all the business logic.
Related to #7047
opw-671697
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.
- 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.
* 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.
rmu-odoo