The invoice date of demo data is changed to match the current
month/year. The original issue is the following:
- install accounting, keep default configuration (company currency: USD)
- add a payment for Agrolait in USD (e.g. $10,000)
- go to customer invoice demo_invoice_2 (which is in EUR)
- the system proposes you to add a outstanding payment to pay the
invoice -> do it
The invoice is not shown as fully paid, but on the other hand if you
click again to add an outstanding payment, nothing happens.
The reason of this bug is because for this specific bill, the currency
rate has changed between the invoice date and the payment date. The
amount used to pay the bill: this is the price in USD, at the rate
corresponding to the date of the invoice (i.e., what you were supposed
to pay at the time of invoicing). The fact that is does not mark your
bill as paid is also correct: the payment is written with the rate at
the date of the payment, and in this case, the invoice is not fully
paid. You should therefore reconcile the invoice and create a write-off
afterwards to register the exchange rate difference.
This unusual situation (pay an invoice in a different currency, and
moreover the rate has changed) has not been taken into account for v9,
and there is no clean solution which can be foreseen for a stable
version.
However, since this situation arises right away with the demo data, this
can be very misleading for a new user. The fix simply changes the date
of the invoices, so that there will be no rate change between the
invoice date and the payment date with the demo data.
opw-657151
In the base summernote library, each event modifying the editable area
DOM trigger an 'onChange' event which update the textarea associated
with the editor.
Some widget (ImageDialog) have been entirely rewritten for Odoo without
copying this behaviour. Hence for those components, if they were the
last to be used and only in the instance of inline backend editor
(FieldTextHtmlSimple widget), before saving updating the widget value by
the current editor value is required.
closes#9784
opw-654240
- display appropriate message when no results are found in a search
- don't display 'you have been invited' notif when creating private channel
- correctly join when a user was invited in a public channel
- display a message when a user join a channel through an invitation
- don't display subject for message of type notification (still a
mystery why it happens in test.odoo.com for channel of type mailing)
- better heuristic on when to display message subject
- tweak sidebar text color (slightly whiter)
- add ... to the placeholder of the text area in the composer
- invert send and icons for attach/smiley in composer
- don't display 'read less' on expanded messages
- exclude livechat channels from channel mention suggestions
The purpose of this commit is to improve the overall performance of the mention
mechanism of the client action and chatter composer, by pre-fetching some data.
First, the employees are fetched at chat initialization (basically, at web
client initialization), if hr is installed.
Second, when focusing on the composer of a channel, the members of this channel
are fetched. In the case of a chatter, the members are already known as they
are the followers of the document.
When the user types a mention, we first display suggestions from the pre-fetched
partners, and we only perform an RPC when there are no more result matching the
search string. This RPC searches among user, and then partners if there aren't
enough matches.
A few side changes occurred:
- auto_join set to True on user_ids field of res.partner to boost the query
that searches partners that are users
- the '/mail/read_followers' route now returns follower's email as well, as
we need it for the mention;
- a partner can now be mentionned several times in the same message;
- mentionned partner previsualization has been removed, mainly because of
the previous point, but also because it simplifies the code;
The content of an asset can change according to which modules
are installed, but cannot change according to the user rights,
according to which user is connected.
Otherwise, the assets is re-generated and stored
in the filesystem too often, which is against the
concept of the assets.
opw-657046
If the current cursor transaction was not empty when using the check
called endpoint, at the first call the cursor would be rollbacked but
the environment could still have outdated values.
This was an issue for example when selecting the route would trigger
database insert, for instance when a model was used in the route and
this model had also translatable prefetchable fields with tokens not
already present in ir.translation
opw-652045
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
Raphael Collet