According to RFC 7232 # 2.3, an etag must be wrapped in double quotes:
entity-tag = [ weak ] opaque-tag
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text
Odoo didn't properly quote etags, which could lead to stripping or
failures when putting Odoo behind strict HTTP proxies.
Analogous to 6fde72abeacdac6e36a0c623c024252839f993ae but now instead
for the 'split' button.
Additionally this uses float_compare with the rounding set on the uom of
the operation to determine if there are any units left, which is more
correct.
opw-685908
When a stock.pack.operation gets created by a stock.picking, it will
have its pack_lot_ids set. This way the user has an overview of what
lots are available and how many of each are still left.
When splitting the stock.pack.operation these where lost. The still
unpacked stock.pack.operation would always have an empty pack_lot_ids
field. The reason for this is that those records where reassigned to the
newly created and packed stock.pack.operation.
This resolves the issue by copying pack_lot_ids that are still
available (qty_todo > 0) and assigning them to the original
stock.pack.operation.
opw-685908
In some cases, users change the sequence of base
views in order to have one applied before the other
e.g. when there is two inherited views doing
```
<tree position="inside">
...
</tree>
```
The priority of the views will have an impact on the
fields order in the tree.
On update, the change of priority done by the users
was overwritten, even if the priority of the view
was not defined in the XML code of the view.
The priority of the views should be overwritten only
in the case were the priority of the view
is specifically set in its definition.
opw-688470
A portal user couldn't change his address details if he was
of type `contact`
This happens because users usually
have no access to write their parent company.
opw-688192
Closes#13430
The snippet options can define an on_remove method which was supposed
to be called when the snippet is removed. This was not the case since
the method was written so that the options were removed before the
on_remove method was called... (Un)fortunately, the on_remove callbacks
were not doing any critical job in current implementation. In saas-13
however, some elements will rely on this.
Although we have been reluctant to perform this change, a specific
use case can cause customers to be redirect to the Odoo DPN url
with a GET request.
This happens when a Paypal Merchant account has the feature Guest
Checkout active; in that case, a customer can pay without having
a Paypal account (using only his credit card) and will *not* be
subjected to auto-return; as detailed here:
https://www.sandbox.paypal.com/be/cgi-bin/webscr?cmd=p/pop/help-account-optional
Request coming from that payment flow will always trigger a GET
request, causing the customer to be welcomed by a
405 - Method Not allowed
error on the Odoo server. The payment is normally correctly processed
through IPN, so this does not normally causes loss of data; however
this is not a nice way to welcome back your customer right after
they pay you.
Commit 8ad0c0f3 introduces back the base amount taken into account for
tax calculation. However, the way it calculates the amount is wrong in
several cases:
- the tax amount is a percentage
- the tax is calculated thanks to Python code
opw-686846
When selectionning a saved shipping address when setting the shipping
address of an ecommerce order, the country and state should be set
accordingly.
unrelated issue noticed when testing e0d4dd01cc
In 1ef52c9c the code displaying state of a given country was improved
for some incompatibilities.
But, if when setting the billing informations we choose to create a new
shipping address, the shipping state* would not be displayed even when it
should be (currently, if the shipping country is Australia or U.S.).
opw-687948
*a state being a subdivision of a country
Until 9.0 our psycopg2 DSN connection strings do not allow having
spaces within the db name, and passing some can cause duplicate
registries to be loaded.
Stripping spaces is a simple workaround until we actually support
spaces within db names.
Fixes#13078
Since 9.0, `message_follower_ids` are
`mail.followers` records,
the partner are in `message_partner_ids`.
Therefore, the partner images displayed in the note kanban
were not the images of the right partners.
opw-688100
Do not force the `search_default_product_id`to the current
product variant, as the domain just above could return a
result, a BOM which is set for the template of this variant
but not for the variant istself, that this filter would hide.
This is following the revision
52cba1b563
Because of this, a product variant smart button could
display "1 BOM", but when clicking on it, none would be displayed,
which is not user-friendly at all.
opw-687912
If `method_time` is set to end, `method_number` is not the reference for the number of depreciation lines.
Take directly the number of depreciation lines is more correct.
Commit 06754b32 brings an inconsistency between the PoS frontend, the
pos_order and the account_invoice tax calculation. Part of the commit is
correct since it corrects the matching between the `compute_all`
methods, however.
opw-680891
Removing a slide was buggy :
* Removing the last slide left the slide handles (and the user had to
click on remove slide again)
* There was an ugly delay before the removal
* Changing the bg image of a slide was not possible anymore once one
slide was removed
* ...
WHen checking `Dedicated Refund Sequence` in a
sale / purchase journal,
the field `Refund Entry Sequence` must be filled with a sequence.
Otherwise, later, when issuing a refund invoice, it won't be able
to generate the number of the refund invoice as it won't be able
to find the sequence to use.
opw-687839
Inconsistencies can arise between the tax calculation performed in the
PoS and in the backend (e.g. in a SO). For example:
- Unit price: 9.479
- Tax: excluded, 5.5 %
- Buy 5 units
- Round globally
In the backend, the result is 47.40 + 2.60 = 50.00
In the PoS, the result is 47.40 + 2.61 = 50.01
We make the PoS apply the same logic than in the backend. First, at the
level of the `compute_all` method, especially to use the appropriate
rounding precision before starting the calculation (so we move the
rounding of `total_excluded` after the rounding precision adjustment).
Then, by calculating the taxes amount as the difference between
`priceWithTax` with `priceWithoutTax`. This is mandatory since they
contain the result of `compute_all` in which the rounding logic has
already been applied.
opw-680891
When we drag and drop a record in a folded column, the number of elements
in this column displayed in the column title is not updated.
This issue is present because when a record is droped in a column
its id is not added to the dataset of its new column.
To fix this, we had to add the id of the record in the dataset, and
override the method 'add_ids' in 'DataSetSearch' to have the size
of the dataset equal to the number of ids in it. We have replicated
the behaviour of the function 'remove_ids' in the new function 'add_ids'.
It is possible to put a clickable object in a vignette that opens
an action, for example the kanban_status class used in the CRM
pipeline. This thing presents an issue as it opens a wizard, but
when the wizard is closed the vignette is not reloaded.
When you click on this item, it will go through `on_kanban_action_clicked`
in kanban_record.js that will trigger up a `kanban_do_action` custom
event. The kanban_view have an handler for this custom event and
will call the `do_execute_action` method defined on the view.
This method can take a callback as its last argument that will run
when the wizard is closed. Before rev ae583ba1, the behavior was
to reload the entire kanban view but this rev tries to only reload
the kanban record. Unfortunately, it didn't use the argument
in `do_execute_action` but in a then of this method. So it
didn't work. This commit put the onclose callback at its right place.
The `geoip` is not always defined in the session,
and therefore one needs to check it's defined before
attempting to use it.
The same is done at different places in the code,
through the different modules.
opw-687783
It was doing something before but the useful line was removed at 908f4165
The method is no longer useful and can be removed.
It was error prone has it had not the same signature as the one on project.
Fixes#13402
Without the @api.multi property,
the method is considered as taking only one parameter (self?),
while it takes multiple parameters.
This prevented to change the quote template on a sale order,
if the quote template had some order lines, due to the below error
`TypeError: product_id_change() takes exactly 1 argument (19 given)`
opw-687797
Commit f30ec302 defines the messages sent thanks to the channels as
plain text. This is true for all cases but one: the notification
(e.g. @user). Therefore, the notifications links are broken.
opw-687781
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)
andreparames