When creating a down payment for a SO, the applied taxes must
be the taxes of the company order. In this way, it's the same behavior
as a product with multiple taxes is added on a SO, only the order company
taxes are applied.
opw:741958
Let's consider the stockable product P with an internal category set
with cost_method = 'real' and 'average'. When creating a PO with P
and a unit_price=0, after delivering the product, the cost transfered to
the stock valuation account was equal to the product cost multplied by
the product quantity instead of the unit_price set on the PO multiplied
by the quantity.
PS: The quant is created with the stock.move in _quant_create_from_move and the unit_price
set on the stock.move is taken with function get_price_unit.
opw:740865
Steps to reproduce:
1. Create a payment of 999 with bank
2. Create a statement line of 1000 on bank journal
3. Go to reconcile interface, choose the 999 line and make an adjustment of 1
4. The payment has been reconciled with the statement line, and one new journal
entry has been created for adjustment of "1"
5. Cancel statement line (you need to enable this functionality on bank journal)
Bug:The payment journal entry of 999 is deleted and payment remains confirmed
After the fix: The payment journal entry of 999 is UNRECONCILED and the payment
entry still exists.
opw:741619
hr.recruitment.report is not necessary anymore as it can be replaced by
classic pivot and graph views on hr.applicant model.
Applicant has been slighty modified to ease reporting
* adding group_operator average on both days to computation;
* adding group_operator average on working hours computation;
hr.recruitment.report is not necessary anymore as it can be replaced by
classic pivot and graph views on hr.applicant model.
Applicant has been slighty modified to ease reporting
* adding group_operator average on both salary fields;
* adding missin delay to close computation on applicant;
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
Events currently have a reply_to field that is purely informative. Indeed
it has to be explicitely taken into account when using mail templates and
is not used for setting classic reply-to of other messages.
This commit removes this field as it is simpler to have a standard
behavior as in all other addons. If a custom reply-to is required it
can be set on the mail template or using the mail composer.
... records on models having a sequence field (e.g. project.task).
When a record is dragged and dropped, the following RPCs are done:
- write (the new group id on the moved record)
- read (the moved record)
- resequence (the column where the record has been moved to)
To perform the resequence RPC, we need to retrieve the list of ids
of the records being in the column. We do that by iterating over
the cards in the column and reading the id in their data attribute.
However, a traceback might occur if the resequence was triggered
exactly when the user was holding a record over the column being
resequenced, because jquery-ui creates a placeholder for the record
being dragged and dropped, and this placeholder doesn't have the
required data attribute.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
The field `ssnid` is used on the payslip. However, it is not available
in any view, therefore it is impossible to fill it.
We replace by the `identification_id`, which is the field commonly used
for identification.
opw-742204
Closes#16798
With this commit, we prevent view dialogs from changing the 'global'
environment in the view manager. Here is how it could cause a problem:
* open a form view for a bill of material
* click on one of the component, it will open a form view in a dialog
(and will change the environment with a wrong res_id)
* click on the many2one product -> it will open a new action in the
background, and change the environment again
* click on the breadcrumb to come back to the bill of material: the view
manager will try to restore the correct res_id (which is the wrong id
from the component form view), the form view will do a read (when
reloading the data), will get an empty result, will update its
information with no data, then will be in a wrong state which means
that the basicmodel will fetch a x2many with a wrong res_ids list
* boom
- Activate multi-currency: EUR is main currency, USD is secondary
currency
- USD currency rate is:
1.2 on 2017-01-01
1.5 on 2017-02-01
- Create a journal in USD (e.g. Cash)
- Create a tax with Cash Basis activated
- Create an invoice of 100 USD on 2017-01-15
- Register a payment of 100 USD on this invoice on 2017-02-15
- 4 journal entries are created:
the payment itself
the exchange rate difference
the cash basis linked to the payment
the cash basis linked to the exchange rate difference
The cash basis linked to the exchange rate difference should not be
created, it is not necessary. The amounts are already included in the
cash basis linked to the payment.
opw-728767
Purpose
=======
- product form is a bit disorganized with fields showing up at wrong place:
- inventory tab for services -> to remove
- subscription & events fields under Invoicing tab
- inventory tab is not structured
- invoicing and bill control fields are not grouped together
- etc.
Before this rev., there might be a crash when the user quickly
clicked several times on the browser's back button. This crash
occurred in the code saving/restoring the scroll position of the
current action.
When clicking fast on the back button, several actions are
executed but don't wait for each other (those actions are triggered
by the hashchange event), so when it is fast, and mainly when the
appswitcher is involved, it may happen that we try to get the
scroll position of an action that isn't loaded yet.
opw~741814
The function _get_bom_component_qty has been deleted by odoo@2ddc35a
But this function was still used in 10.0 in function _get_anglo_saxon_price_unit.
opw:742462
As administrator is used to create all records from website form he is
also put into followers. This creates a lot of unnecessary notifications
and/or emails depending on the system configuration.
Using the magic context key this behavior is modified. Administrator
will not follow every records created through the website form anymore.
The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
Before this commit, numbers in list views were right-aligned
depending on the widget they were using (float/monetary). Now, the
input text alignment is inherited from the parent which should
solve the problem.
The field move_line_ids was present in the view and used only for display
purposes. However modifying another field triggering an onchange (e.g. a payment
line) was recreating the move lines.
Recreating the accounting entries may trigger an error if the entries are
already posted.
The entries are recreated because:
1. the move_line_ids is loaded with the default tree & form view for
account.move.line records, displaying several fields
2. some of the fields (e.g. reconciled) are computed
3. the initial onchange recomputes all the computed field, including the one
on the one2many (e.g. recomputing move_line_ids.reconciled)
4. the field being dirty, the onchange returns the value of move_line_ids with
[(5,),(1,id,{...}),...]
5. trying to save the modified lines may fail
Replace the field by a simple readonly integer field.
opw-741205
Haresh Shyara