Some accounting model (i.e. account.tax) are redefining the ORM search
method, but with misordered arguments (placing count as fifth argument
instead of context).
For the export function, this lead to have the "context" variable
associated to the "count" function variable. As "count" is then
considered as True, the method returns the number of records instead
of the list of record ids. This then exported the last record (the
count'th one) instead of all the records that matched the domain.
The solution here is to explicitly give the context variable by name.
When a portal user opened his quotation form,
all buttons of the regular form were available.
They were not working, due the access rights,
but it's better to hide them.
opw-657654
The drop ship address was missing from the view, making impossible to
specify the address where the products needed to be delivered.
The fix adds the missing field to the view, and make it visible (and
required) if the delivery must be done at a customer location.
opw-657054
The filter `Sales` in the sales orders search views
was defined as
`[('state','in',('progress','Done'))]`
but
- progress no longer exists. It's `sale` now.
- `Done` is the label, `done` is the value
opw-657552
Messages are required to be displayed in a smarter way: relative to the
current date, if it's a recent message, or absolute if not. This
commits rework most of the date processing code to comply with these
requirements.
Messages were preprocessed each time a thread is rendered, which is
stupid. It should be preprocessed only when the message is created.
This was a small problem because livechat does not use the chat manager,
so a simplified version of the preprocessing had to be done.
The fields Total Receivable and Payable are calculated as debit-credit.
However, this leads to a wrong computation if, for example, a payment is
used to pay several invoices. For example:
- Create a customer invoice of 2500 USD
- Register a payment of 3000 USD
The Total Receivable will be 3000 USD instead of 500 USD.
At the same time, this commits changes the sign of the field. The help
depicts the Total Receivable field as "Total amount this customer owes
you". Therefore, one would expect that if the customer owes 250 USD, the
Total Receivable is 250 USD, not -250 USD.
The same logic applies to Total Payable.
opw-657053
This commit tries to correctly use messages from the cache instead of all
messages. This means that we need to correctly add messages to the
domain-specific caches, and correctly invalidate them when necessary.
Also, to avoid increasing the algorithmical complexity of the process,
particular care was made to avoid scanning too many lists. For example,
the channel caches have now a messages field, instead of message_ids.
applied_on:
The field applied_on in pricelist rules is not taken into account:
- In the price computation
- In the name computation
When creating a pricelist item, if you select (applied_on = Product)
first and set a product, then select (applied_on = Global), and save the
rule, the computation will still take the product_tmpl_id in the price
computation.
Instead of fixing the whole _price_rule_get_multi method, this patch
sets the fields that should not be taken into account to False.
compute_price:
Add a behavior similar to the applied_on field, to reset unnecessary
fields to zero when the computation method is changed.
Original idea from @tgr-odoo
opw-657148
Closes#9671
The expiration date will now be set when installing the enterprise
'web' module instead of at the init of the database since putting
an expiration date on a community edition database doesn't make sense.
- Differentiate between the Community and Enterprise editions
in the version number. By adding this attribute on the global
odoo JS object in the web client bootstrap controller /web,
we can differentiate between versions easily on the client
side without extra RPC calls.
- Remove a couple of version-related RPC calls in case
the global version info is present in the JS environment
- Update "About" panel to display the edition info
- This commit also reverts 07fe5afc87
which implemented the idea in a more limited way.
Closes#9625
This window action did not open the create form
view as a leave allocation but as a leave request,
which was inconsistent with the very similar
open_allocation_holidays action. With the former,
the duration field was two dates. On the latter,
it was only a number of days, as it should be for
leaves allocations.
When the user validates a picking without going through the manual
reservation process, Odoo tries to assign the picking then performs the
transfer. However, if the picking could not be assigned, no pack
operation is created and the picking will simply be set to done.
The fix raises an error if the picking could not be assigned completely.
Another solution is to use a force_assign instead of action_assign, but
that could lead to the creation of negative stock moves without warning
the user. We therefore prefer to stay on the safe side and force the
user to manually handle the reservation.
Note: the original issue was that the Owner of the picking was not
copied on the quant when validating right away. The reason was that no
pack operation was created.
opw-654423
There were still references in the POS to a child_ids field on
account.tax. This field was renamed in accounting v9 to
children_tax_ids. Because child_ids wasn't loaded anymore this meant
that child_ids on the taxes in the POS was always undefined. On top of
that the original code used Array.prototype.concat() assuming it
modified the array, when in fact it returns a new array.
All of this meant that group taxes in the POS were never calculated,
this resolves that.
The time_display is present in a translatable email template but was not
translated. Added the missing term.
Updated .pot file for a few missing terms.
Removed base_calendar.pot that has no reason to be in 8.0
Fixes#9573
`stock.move` & `stock.product` have multi-company rules.
There is therefore no reason why `stock.quant` could not have one.
Besides, this could lead to access rights issues,
when a user went to the `Quants` list,
in Warehouse > Traceability > Quants,
while there were quants for products in a company different
than the user company.
opw-653188
When creating a SO with a quotation template, the lines created
with the quotation template must take into account the fiscal position
set on the SO to compute the right taxes.
opw:657015
In 6fd7fc9 the issue was solved in some instance, but there was still an
issue with the combination of IE11 / Odoo community / Overflowing content.
fixes#9696
related to opw-653477
`website_quote` overrides `payment.transaction`.`form_feedback`
the same way `website_sale` does,
in case `website_quote` is installed without `website_sale`.
Therefore, the revisions
- 4adb4b8
- 809e1a6
must be applied there as well.
opw-657432
Add the possibility in the decorator to specify the `upgrade` and `downgrade`
functions that convert values between APIs. Both function have the same API:
upgrade(self, value, *args, **kwargs)
downgrade(self, value, *args, **kwargs)
The arguments ``self``, ``*args`` and ``**kwargs`` are the ones passed to the
method, following its new-API signature.
Fixes#4944, #7830.
On databases with a large number of res.partner entries,
the extended name_search of analytic accounts was prohibitively
slow, due to the expensive name_search on res.partner.
Restricting the search to the partner name is extremely
similar business-wise, but makes a huge difference in
terms of speed. E.g. sub-second results vs 10+ minutes
for a database with 30k analytic accounts and 600k partners.
IE11 and IE Edge presented issue in the project kanban view with content
overflowing its container.
On IE Edge it could be solved by "min-width:0" on the left part of a
kanban card, so it was an issue in the computation of widths order.
But on IE11 that wasn't enough so a less elegant fix has been used.
opw-653477
(solution found mainly by qsm)
The error message on the journal entry for currency was wrong.
The multi-currency view does not exists anymore in 9.0 so is no longer relevant.
To avoid breaking existing translations, create a en translation.
Rename the en_US.po to en.po to be used by _GB and _AU
Will be fixed in saas-7 by the mighty @csnauwaert 📯
In v8.0, a procurement is not created by default. Only sale_stock and
sale_service will create procurements, since they are only used for
physical products or task-related services.
In v9.0, the behavior was changed and a procurement was always created.
This is not necessary, since the procurements are still only used for
physical products and task-related services. This behavior will just
lead to the creation of procurements which will fall into exception
(method `_assign` will return False).
This fix switches back to the previous behavior. The other solution was
to prevent the exception, but it will imply that useless procurements
will pile up.
opw-654363
When a PO is created from a procurement, the field product_id of the
supplierinfo is not taken into account when the possible vendors are
chosen. For example, let's take the following situation:
- A product with 2 variants (color White and Black), route MTO
- Two vendors are created, one for color white, the other for color
black
- When a SO containing the 2 variants is created, only one PO for the
same vendor is created for both products.
With this fix, 2 POs will be created, linking the appropriate vendor and
variant.
opw-657362
Goffin Simon