Description of the issue/feature this PR addresses:
Accessibility improvements forbids the use of the syntax
`<i class="fa fa-check"/> Some text`
to create a labelled icon. But, by this, some fonts are changed.
Desired behavior after PR is merged:
The old syntax can be used.
Now, when setting a server action's model to `ir.actions.server`, a
button will appear that will allow the user to immediately run the
current server action.
Task ID 1850663
Commit 2fa469c5e5 implemented the possibility to sign and pay (one after the
other) a sale order to validate it.
The option to sign and/or pay is activated in the sales settings but can be
overrided by a template.
Two improvements needs to be made:
1. Creating a new template should use the sale settings as default value for
sign and pay confirmation mode.
Note: If none has been enabled, sign should be forced.
2. Default value in sale settings should remains as it was before, nothing
activated by default.
opw-1818837 (Added specs with fgi)
This revs. add a new test suite for the im_support module. Defining
a new suite was necessary as the im_support JS feature needs
specific keys to be defined in the session, otherwise its files are
simply skipped.
Those test utils files should be in the test assets bundle such
that they are available for potential other test suites (e.g. the
new im_support suite).
Also roughly called "open chatter in chat windows".
With this commit, document threads can now be detached in a small thread window.
It uses client-side cross-tab window synchronization by means of the local storage.
To detach a document thread in a thread window, click on the document thread preview
in the systray messaging menu when receving a new (needaction) document thread message.
-------------------------
Technical Limitations
-------------------------
1. In order to use this feature, the user must select the Notification Management
'Handle with Odoo' in the Preferences of the User settings (top-right menu).
2. For the moment, only needaction messages automatically updates the thread window. Manual
refresh is still needed for other kinds of messages (e.g. reload document record to fetch
new messages in the document thread).
Server-side code changes are required to receive new document thread message notifications on the
longpoll bus, which would fix the limitations above.
-------------------------
Future Works
-------------------------
1. Receive any new message from the document thread window when it is detached.
2. Log a note from the document thread window.
Task-33118
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
Forward port 49edee1f4b broke commit 2fa469c5e5
Indeed, the mail template got fixed with 5940f41ddc in earlier version.
Mail template should not integrate static term
Closes#25561
Since refactoring of account, payment and sale with commit 01216345 the
`Pay Now` button in the panel-heading of the SO in the portal was always hidden
except if there was a pending transaction.
The button should be visible when there is no transaction. In that case
`payment_tx_id` is an empty recordset, we can safely access its `state` field.
Closes#25529
In stock.move.lots.form view, the field product_uom must be readonly like
the field product_uom_qty.
When creating a raw material, it was not possible to add a stock move line
with a finished product for a product which is not tracked.
The consumed field must be readonly in mrp_production_form_view view to avoid
to send to the server wrong value manually set.
opw:1861321
As a follow-up to commit 276ea817f4,
we change the default template database used for CREATE DATABASE
operations, and we avoid setting the LC_COLLATE option unless
this default template is used (to avoid locale compatibility errors).
Rationale for the default template choice:
PostgreSQL uses `template1` by default, and recommends that users alter
`template1` if they need a custom template, while keeping template0
virgin. This is likely to be the reason why we had `template1` as the
default previously (from a1e5c645d9).
However, for new Odoo databases, it's actually better to use `template0`
as template, for multiple reasons:
- We do not customize the template database, and the system will work
fine when starting from a completely virgin database
- Since template0 does not allow connections by default, we have a
stronger guarantee that no user will be connected to the template
database (which would otherwise block database creations!)
- We use the same logic for creating new databases and for creating
placholder databases for restoring dumps. In the latter case,
PostgreSQL recommends using a virgin template, to obtain a perfect
copy of the database being restored (unaffected by any template
customization)
- Using `template0` as a template lets us choose any encoding and locale
settings (LC_COLLATE/LC_CTYPE) upon creation. Any other database
template might cause errors unless we select compatible encodings
and locale settings.
As the locale setting is system-dependent, we can't just hope
that there will be no compatibility problem, we must explicitly
default to template0. Therefore the change in
276ea817f4 was prone to causing
locale compatibility errors.
Finally, if users have a reason to prefer a different template, they
should select it explicitly with the --db_template config.
Note: existing environments will likely continue to use `template1`
as a default due to presence of older config files.
Complements #25196
Tests from [1] were not passing, due to changes from [2].
This is due to the fact that `$.('.modal-body')` picks 2 elements, instead of 1.
Partial HTML before [2]:
```
<main class="modal-body">
<div>
<p>
...
</p>
</div>
</main>
```
Partial HTML after [1]:
```
<main class="modal-body">
<main role="alert" class="modal-body">
<p>
...
</p>
</main>
</main>
```
In order to not pick both DOM elements, we refine the jQuery selector to pick
the `<p>`, so that there's only one element and it has the same text content.
[1] [FIX] mail: warn user on record reload before post message
https://github.com/odoo/odoo/commit/b74d1e90ef32893bfbcf750cdf4586c453790b01
[2] [IMP] Improve compatibility with screen readers (accessibility) (#24574)
https://github.com/odoo/odoo/commit/9de1bc0eef6f5bfaa2a8d745431caa361ae91548
This makes sorting and indexing independent of the cluster/machine
configuration, and allows simple b-tree indexes to be used for
prefix-searches on VARCHAR columns without needing special operator
classes (and therefore without needing duplicate indexes).
The 'C' collation is built-in and always available on any postgresql
installation. It also allows any encoding/locale to be used, contrary to
other LC_COLLATE values, so it should never conflict with custom db
templates.
Admins who want to apply a special collation can still do so by creating
the database manually, instead of letting the system do it.
Closes#25196
Revision on https://github.com/odoo/odoo/commit/299ebb2cdf63de2e3967da0d2f3e7effd239812b
[IMP] mail: add moderation on channels
The commit above adds moderated channel. When a message is pending moderation,
it is not yet linked to the channel server-side, which is why there is a hack
to set `channel_ids` on the client side so that the message is visible on the
corresponding channel (only for author of message and moderator of channel).
It is only when the message is accepted that this message is linked to the
correct `channel_ids`. The server provides the updated list of channels that
this message is linked to, but it misses static channels that only make sense
on the client-side, such as "Inbox" or "Starred".
This commit solves the issue by only extending the list of channel registered
on the message when it is accepted, so that static channels are not unlinked
from the message.
Note that it is necessary to update `channel_ids` of the message,
because there could be "relay" channels. In other words, when the moderated
message is accepted, there could be more channels that contain this message.
This fixes the following bug:
Creating an Invoice, clicking on Validate (with no invoice line), and then trying to add a product.
Before this fix, this would throw an error message.
Now it works.
The sequence had a static default value, but when there is an handle, it's important that new items are added at the top or the bottom of the list.
This is a rare case where the defaul_get from the server will be ignored by the view for a certain field.
This will work:
- both in editable mode (inline) and in dialog mode,
- both for X2Many and standalone list.
The scenario is:
- create a new parent model, which has a one2many
- add at least 2 one2many lines which have:
- a handle field
- a many2one, which is not required, and we will leave it empty
- reorder the lines with the handle
This will call a resequence, which calls a name_get.
With the bug that would throw an error at the RPC, but this commit fixes it.
The $as_all variable was mentioned in the doc but it is non-existing in the Python code.
This commit makes clear it is only available on JS QWeb.
Also rename OpenERP to Odoo.
Extension of commit c4f5b9f751
Instead of disabling only the button on which the user has clicked, we
disable all 'Add to Cart' buttons until the end of the transaction.
Closes#24853
opw-1858080
Backport following opw-1851612
[FIX] google_calendar: do not create an event with an invalid id
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
On an optimization done for not rendering each time the template, the possibility
of sending the template in the proper language when multiple recipients was lost.
This is being refactoring in master, but for this version, Odoo won't merge a
change in the behavior, although it's the correct one as in previous versions.
Extracted by pedrobaeza from https://gist.github.com/nim-odoo/8a9749037370343f05c7e6681324f576
(cherry picked from commit 386a936)
Commit a3c9c286cc made stripe.js more generic. By doing so it also fixed the
`provider_form.innerHTML = data` that was not doing anything since
provider_form was not a dom element.
For orders on /my/orders/XX, the `return_url` was /my/orders/XX before going
through stripe.js.
stripe.js would then call `/pay/sale/XX/form_tx/` that would return new
acquirer form values that should replace the old ones, including a new
`return_url`.
But since `provider_form.innerHTML` was undefined, the old data would remains.
With commit a3c9c286cc the data is now correctly replacing the old ones.
The `return_url` is now /my.
So when an user pays a SO, he is redirected to the portal root page instead of
the SO he just paid with a confirmation message (like it was the case before
the stripe.js improvement).
This fix ensure that the user is still redirect to his SO, by redirecting to
/my/orders/xxx and not /my.
res.currency's `_convert` expects a record not an id.
On res.currency:
_convert() calls
_get_conversion_rate() which calls
_get_rates()
_get_rates does company.id.
Both features already existed but it was not possible to enable both.
This makes that possible. When both are enabled the quotation first has to be
signed, then it can be paid.
Purpose
=======
No way to combine digital signature and online payments to confirm orders.
A customer signature matters for big deals, in order to keep an official print
of customer agreement.
Specs
=====
- when the customer signs online, a new pdf is generated with the customer
signature on it and posted as a note in the chatter, replacing the current
signature jpg.
- show the signature in the portal view, with both sale_management and
website_quote module
- change in settings: Digital Signature and Electronic Payment are now 2
checkboxes instead of a radio button
- these settings must be company-specific (add company icon if multi-companies,
like other company-specific settings)
- when both modes are activated, it first request the signature, then the
payment
- the order is confirmed after payment
opw-1818837
Closes#24174
The funny self.$('#o_portal_sign_accept') line was some leftover
debugging code. It doesn't actually match anything, because that
element is not in self.$el.
Before this change nothing happened when you clicked the button and an
error occured.
Now the `data.error` message (e.g. 'Invalid Order') is shown near the
bottom of the dialog.
kujiu