From Odoo 9.0, en_US is not always activated in Odoo. As a fallback, if
the search for a language does not find company language nor English US,
we use the first available language (there is always at least one).
In order to reproduce this behavior, eg: you can set the language of
your company's partner to en_US, then load another language, then
disable en_US from your database. Try to open the "Accounting" dashboard
and you will get a traceback.
When consuming products tracked by unique serial number, no check is
done on the quantity consumed for a given serial number. It means that
negative quants might be created without any warning to the user.
We implement a simple warning thanks to a onchange.
opw-687129
When a model has no form defined, a default view is generated displaying all
fields of the model.
The one2many and many2many fields were not displayed on the form, probably for
aesthetic or historical (2008) reasons.
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.
The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).
This is a forward-port/cherry-pick of 7bdd4de805
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.
For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.
Since commit 2ab68047, the Paypal link can be sent in an invoice as it
was the case before. However, in order to be able to save the Paypal
account in the accounting settings, the Paypal account must be
website-published. If the module `website_payments` is not installed,
this is not possible.
We remove this condition, since it should be possible tu use the Paypal
payment method without installing the whole website.
opw-686216
This reverts commit a57b10dbd5. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. On some status
bars, clicking doesn't work anymore.
The reason is because, in some mysterious cases, the event is propagated
to the parent. The `currentTarget` is not the `li` element, but the
parent `ul`. By setting the `immediate` argument to `true` (execute the
first function instead of the last), this solves the issue.
When removing the "Save as Attachment Prefix" field
of the Invoice report (`account.report_invoice`),
it was no longer possible to reset the invoice to draft
opw-687130
When a database is created, we are not auto-logged in to the new
database anymore because the login passed to the authentication request
is 'admin' instead of the one set in the creation form.
To fix this issue, we used the login parameter from the creation form
in the authentication request. We also set the login field to
required in the create database form view.
This bug comes from rev https://github.com/odoo/odoo/commit/903733a32
When anglo-saxon accounting is enabled and the valuation of a product is
'real_time', rounding errors might occur in the price difference between
the invoice price and the product price. It occurs when the product
price precision is larger than the accounting precision.
To avoid these rounding errors, we calculate the difference as the
difference between the price before update and the price after update.
opw-686730
- Activate the option "Track Lots or Serial Numbers".
- Set the outgoing process as 3-step one.
- Create a stockable product for which the tracking is "By Unique Serial
Number".
- Go to Sales > Sales > Sales Orders.
- Create a Quotation for the created product and confirm it. A picking
is generated but it is waiting availability.
- You are sure to have this product in stock so you force the
availability and assign the serial number (001) you want to transfer
in the operation lot details.
- Validate the picking. By doing this, it creates a negative quant in
the origin location (WH/Stock) and it creates a positive quant in the
destination location (WH/Packing Zone). The two quants are linked to
each other.
- Go to Inventory > Inventory Control > Inventory Adjustments.
- Create an inventory in WH/Stock for all products and set it in
progress.
- You want to correct the negative quantity you have so set the real
quantity of product B to 0.
- Validate the inventory and you get the following warning: "The serial
number 001 is already in stock.Otherwise make sure the right
stock/owner is set".
We should allow a quantity larger than 1.0 temporary, so it allows the
system to reconcile the quants.
opw-685825
Since 5a9e1af64 our guess_mimetype accepted a `default` named argument.
This commit fix the use of library used instead of our implementation, so
we don't get an error from an unexpected argument when having python-magic
installed on a given server.
Since python-magic functions always return a default mimetype:
- empty content: application/x-empty
- text content: text/plain
- binary content: application/octet-stream
the guess_mimetype default argument is not used with python-magic
implementations.
closes#13343
opw-687354
When an owner is defined on a quant, the current behavior is to to allow
only the owner to use it. This is restrictive for internal transfers:
when a quant is owned by Partner A, only a picking with owner Partner A
can select it.
The fix is to make things a bit less restrictive: when a quant is owned
by Partner A, a picking without owner or with Partner A as owner can
select it.
opw-687207
In the new API, default calls are supposed to return recordset
(even empty recordset), not bool values for relationnal fields.
If the table for this model was already present and if no l10n_x
was installed, no default value could be computed correctly for
existing entries. This caused a crash on install.
opw-683470
If you create an issue when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create an issue directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created issue. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the issue, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
If you create a task when `default_project_id` is set, the stage_id
is initialized at the lowest sequence of the stages of the project,
which is normal. However, when you change the project of the task,
the stage_id was not correctly reset. If you save at this time, you
add the selected stage in the project.
Also, the stage_id was not correctly cleared if you remove the project.
If you create a task directly, the key `default_project_id` is not set
in the context. This key is used to compute the default stage of the
created task. It is done by creating a domain. Unfortunately, the
domain is always filled with `[('fold', '=', False)]` and thus it
always returns a result that makes no sense when `default_project_id`
is not set. Worse, if you actually create the task, the found stage
that was not in your project is now a part of it.
The fix is to return no result if the `default_project_id` is not set
in the context.
It might happen that a price is strike through in the shopping cart
although it has the same value than the discounted price. This can be
due to differences in decimals smaller than 0.01.
The fix is to apply the same logic than in other places: strike through
if the difference is larger than 0.1.
opw-685109
This is needed to avoid the scheduler to stop suddenly as the scheduler
takes a bunch of moves to reserve without looking if all moves of
a picking are taken. That way, it is possible that a certain key
is not there in this dictionary and the solution is to simply
filter them out.
Closes#13286
In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order
will generate unexpected behaviour.
Eg:
> id id_dept name
> -------------------
> 1 1 Tom
> 2 1 Mike
> 3 2 Meggie
> 4 2 Marge
> 5 3 Bart
> 6 3 Lisa
> using LIMITed selects like:
> SELECT * FROM employee ORDER BY id_dept LIMIT 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6
> You can have some result missings from the 3 requests, and others duplicated.
> Because id_dept is not a uniq order.
opw-686639
note: backport of saas-12 4dce8616
If you create an ir.ui.view from the backend, it'll everytime
show a traceback (Keyerror arch).
The field we write to in the form view is `arch_base`. Writing in
`arch_base` will indirectly write on `arch`.
The issue is that the `create` function or ir.ui.view is overriden
in order to compute the `type` column. For this to be done, we parse
the `arch` content and the type is the string of the root tag.
The issue is that we parsed the `arch` field instead of `arch_base`.
However, during the creation of the db, convert.py will write to
the `arch` field when inserting the views in database.
Another thing is that we'll get a traceback if the parse fail for
any reasons (an invalid xml string for example). To workaround
that, we chose to catch the issue and do nothing with it as the
constraint on `ir.ui.view` will detects this issue among others and
will raise a proper ValidationError.
Lastly, the actual code only clears the `arch_fs` field if we write
on `arch`. This patch also clears it when writing on `arch_base`.
[FIX] packaging: debian: update-python-module is no more
The command is not installed by default. It was available in the
python-support library which we didn't depend on and now this library
is no more in debian jessie/ubuntu xenial.
Backported for #13302
If a budget line has no analytic account id, the code is intentional
about returning a value of 0 for it. It is possible, that in some
cases, depending on the order of lines processed, the routine returns
the previous value, as it does not initialise an important
variable on each iteration of the loop.
Closes#13303
When a reconciliation creating an exchange rate entry was done, the newly account_move_line corresponding to the exchange entry was not given a full_reconcile_id.
Also when doing a full reconciliation in different currency, full_reconcile_id was not set on account_partial_reconcile object resulting in problem when trying to unreconcile entries.
This is a backward fix of commit: 9b5fed4976 and cda132bba5
Google made the use of an API key mandatory to use the "Google Static
Maps API". The API key field will be created for the upcoming version.
opw-686510
Non-required selection fields and incorrectly updated fields (e.g.
changed options but didn't fix existing values) trips KanbanSelection
badly leading to the entire kanban view failing to appear: the rendering
phase does not find the state in its states list and blows up when
trying to access the state's class.
Fix by adding a fallback default state with an empty class.
Ravi Gohil