The link to open the merging partners wizard was duplicated
in the action menu:
- Once as "Deduplicate Contact",
- Once as "Merge selected contacts".
This is due to the revision 30a7ef8,
converting the
`<record model="ir.actions.act_window"...`
to an
`<act_window`
which creates an action binding automatically.
No action binding must be created for this window
action, as there is already another one,
the link to this wizard is already in the
partners action menu, thanks to the `act_window`
`action_partner_merge`.
Besides, the `'default_state': 'option'` seems useless,
as this is the default value set in the model directly.
On the opposite, removing the `active_test` (as done in
the revision mentioned above) could be armful. We
therefore re-set it.
opw-669688
When the database_or_uri is not a URI, rather than generate a dsn string
just collect the various psycopg2.connect keyword arguments in a
dictionary, and return that. This way psycopg2/libpq is the one doing
any necessary processing on the various parameters.
Fixes#3865 and fixes#6958 in a more resilient manner than manually
escaping dsn-injected values so database names or passwords containing
spaces or non-ascii characters work correctly.
In case a URI is provided to the dsn() function, return it as the `dsn`
keyword to get the same behaviour as previously.
Since we're checking dsns by equality, a dict should work just as well
as a string.
The algorithm for matching analytic accounts based
on search term is only meant to be used for
simple, positive operators.
In other cases the results will not be what the user
expects. Falling back to the default name_search
behavior will be more useful.
It was like that for the date field, which is taken into account for the forecast quantity,
but in the view the scheduled date field is shown. We put the scheduled date equal to the date.
That way it is clear to the user when the products are foreseen to be consumed.
When a tax with an amount of 0 percent was linked to an invoice line,
this tax didn't appear in the tax details in the bottom of the invoice
report.
opw669162
By calling directly the method `fields.Datetime.now`,
the default order date was the datetime at which
the server is started or the worker created,
while, it should be the current datetime, not
the datetime at which the registry has been
loaded.
opw-668278
The revision 29bd622521
aimed to improve the performance by changing
the view index, to use a BIGINT instead of a text.
It was assumed that the index used
(`stock_move.id`) could not appear
multiple times with the JOINs and
group bys defined.
This was in fact possible, if a
stock move is associated to
several quants with different costs,
because of the JOIN on the many2many table
`stock_quant_move_rel`
linking quants to moves,
and the GROUP BY
`price_unit_on_quant`
that caused the different moves/quants association
not to be merged within one unique line
if the costs on the quants are different.
Instead of the group by, we now aggregate the quants
costs, using the weighted average, so the index
used can be unique, as expected.
From now, the inventory value per line in
this report view can therefore
be different than what can be found on the quants,
but this report view is based on the stock moves
rather than the stock quants, and this is therefore accepted.
In other words, the inventory value is computed for the stock move
rather than for the stock quant.
opw-658903
Ogone responses comes from direct s2s calls or form feedback;
not necessarily in that order. The behaviour of the system should
be the same in both cases. This commit add payment_methode creation
when a s2s response contains the necessary information, juste like
the form feedback methods.
Ideally these methods should be merged to share the same code,
this will be done in master (v10).
In a SO line, the price unit is taken from function "_product_price"
set on the product(model: "product.product"), this is why the variable
new_list_price has to be taken on the product too. In this way, the right
discount can be computed. Before the fix, new_list_price was equal to
the price set on the product template(list_price) then if the product template had
several variants with several sale price, the discount was wrongly computed.
opw:668636
When making a landed costs with pickings using
unit of measures different than the default products unit of measure,
the additional costs added to the quants inventory value were wrong.
This is due to the fact the quants unit of measure is always
the quants product unit of measure, while the quantity
in the adjustment lines were assumed in the stock moves
unit of measure.
As there is no unit of measure field on the adjusment lines,
it makes sense to assume the quantity within the product
unit of measure, to display the quantity within the unit
of measure the user uses the most, which is, normally,
the product unit of measure.
Thanks to this, the additional costs added to the quants
inventory value is now correct.
opw-668374
To match the current website, we should compare the request http_host to the domain and not
to the website name. That was working luckily because name and domain in demo was the same.
close#10870
Translated text is stripped of starting and ending spaces on Transifex which
makes the result text look bad (as translators do not put spaces in their
translation either).
Add explicitely a space to be sure it's present in the translation.
Will have no effect on English as it's HTML
By default, a pricelist can be created without pricelist item. However,
if a user does not have the rights to manage the pricelist items (or
simply does not want to manage them), the feature is unusable. Indeed,
the user will create a new pricelist (for example, in a new currency),
but this pricelist will not have any item. Therefore, the pricelist will
not apply to anything.
The fix creates a pricelist item by default. The pricelist item is the
most generic possible: it applies to all products and uses the list
price as a base price.
opw-667607
The problem was that mentions weren't correctly erased with DELETE key (in some
conditions), or when replacing mention text. When this happened, the mention
didn't appear in the message, but the message was even tough sent to the erased
mentioned people.
With this rev., we don't try to detect erasing on the fly anymore, but we
rather validate mentions before sending the message with the content of the
input.
opw 669362
In the report model `im_livechat.report.channel`,
The `session_name` field no longer exists. It has been
replaced by `technical_name` instead, labelled
`code`.
opw-669443
Use the same factor than the one used when
computing the products to consume at confirm.
Before, the quantity of products to consume was wrong
when using a different unit of measure in the BOM
than in the production order.
e.g.
- BoM defined as:
- 1 dozen of milk
- BoM lines: 1 cow
- Production order:
- 1 unit of milk
- BoM: The above one
At confirm, the quantity to consume is 0,083 cow (1 cow / 12, this is correct)
But, when updating the quantity to 2.0,
it updated the quantity of cow to 24.0, instead of 0,16.
opw-669447
When a product template has several variants, the fields volume, weight and
standard price don't have be displayed in the prodcut template form view.
opw:669240
A SO line with an ordered qty less or equal to the sum of all the quantity
linked to its procurement must be ignored. In this way, when a SO line has
an Ordered Qty equal to 0 in a SO, all the other lines can be processed like
in 8.0
opw:669200
From saas-6, setting `0` as maximum available seats
means there is an unlimited amount of tickts that
can be sold, as stated in the help message of the field:
```
Define the number of available tickets. If you have too much registrations you will
not BE able to sell tickets anymore. Set 0 to ignore this rule set as unlimited.
```
This domain is the same domain used than in
the QWeb views of `website_event_sale`.
opw-669355
`write` expects a `dict` for the `values` argument,
`part[record.id]` is a list of commands to add new
followers.
See the returned variable `specific` of the method
`_add_follower_command` in `mail_followers.py`.
Surrounding `part[record.id]` with a `dict` with
`message_follower_ids` has probably been
forgotten by oversight.
`gen` and `part[record.id]` have actualy the same
syntax, and the `write` done with these variables
should therefore be called the same way.
opw-669376