Add a related field to the partner_id of the picking. Note that
partner_id on stock.move is different from partner_id on stock.picking
in case of dropshipping, therefore we need to show both fields.
opw-656298
Depending of the location where the "Copying" happened, only text/plain
content could be available from the clipboard component.
So if no text/html was retrieved, we should fall back to plain text
pasting.
closes#9787
opw-657137
The "edit" action is on the "website.TopBar", which will create a new
instance of the "editor" (web_editor.editor) widget.
So if we want to do something when the "editing" start, we have to
either override "edit" of the TopBar, or override "start" or "init" of
the editor.
opw-657662
When accepting/declining a calendar event invitation received by mail,
we landed on an empty gray webclient. The confirmation page had been
dropped with passage to new JS API / new calendar / new webclient.
Previous mechanism had been reimplemented: custom web client with event
information/confirmation if the user is not connected or redirection to
the event form view if the user is connected.
+ FIX manyattendeetag : the status circle did not turn red when an
user declined the invitation.
In particular, when an automated action is defined on "create or update",
setting `old_values` to `None` allows to distinguish between a create and an
update. Note that not setting `old_values` at all may be confusing: on a
create, it may be present because of an outer update...
The base action rules manage a kind of checklist with the records already
processed for each action. This checklist may be populated by recursive calls
on other models (such as the update of relational fields), and guarantees that
a given action on a given record is executed at most once.
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.
Nicolas Martinelli