According to the RFC1034
https://tools.ietf.org/html/rfc1034
A TLD can use up to 63 octets.
The regex checking that an email address is valid
should there allow emails using a TLD with such a length.
Besides, the use of TLD domains exceeding 6 characters is more
and more common, nowadays.
e.g. using a domain `.amsterdam`
opw-660014
Before this rev., no notification was sent on the bus when the user presence
changed. Thus, the bullets displayed in Discuss were never updated and stayed
as they were on the initialilization of the chat_manager (on webclient launch).
This rev. makes the bus.presence notifications work, and handles them client
side.
Moreover, the disconnections detection is now performed at each poll (with a
maximum of 1 per minute), instead of randomly (1/100 chance) at each poll, as
it scales better than the former solution. We also added a cron that performs
this check every 5 minutes. It is needed to detect that the last connected user
just disconnected (useful for visitors in the website, trying to talk with a
livechat operator).
Also, the 'away' status is now handled client side, as it makes more sense
that way (being away at each poll, e.g. every 50seconds, during 10 minutes
doesn't mean that we didn't come back between two polls).
Finaly, in bus.js, CrossTabBus, we moved the code writing in/reading the local
storage after the tab registration as this code depends on the fact that the
tab is the master tab or not (and this is known only once the tab is
registered).
This rev. was necessary in stable because the livechat uses the user status to
detect if there is an operator available, and this was often inaccurate.
Moreover, it improves the user experience of the chat in the backend.
The traceback ocurred when the operator closed a livechat channel chat window,
and then unpinned it from the sidebar in Discuss. Then, if the visitor sent
him a message, the channel was automatically re-pinned to the operator, who
received two notifications: the first one being the new channel info and the
second one the message itself.
The channel fold_state being 'closed', the window manager was trying to close
it again, which produces the traceback as the channel didn't exist in the JS
cache anymore (it was re-added to the cache when processing the message
notification, so just after).
Anyway, closing this channel was useless as, even if it was in the cache, it
would already been closed. So this rev. simply checks whether or not the
channel is in the cache before trying to close it.
The problem was that, when calling 'match_rules()' from the loader template,
we compared the wrong url with the url regexp defined in rules. Indeed, we used
the url of the page we were leaving, not the one we were going to.
We thus need to know if we are coming from the controller, or from the loader
template directly as the way to get the correct url differs.
Courtesy of JEM
- use channel configuration for the auto_popup
- clear auto_popup timeout when chat open to prevent opening the chat twice
if the user opens it himself before the end of the timeout
- don't send message when no feedback given
The problem was that users couldn't write characters like <, > in their
messages because the messages are html (e.g. '3 < 5' resulted in '3' because
this wasn't html valid so the second part was trimmed).
Because of mentions, we can't force messages to be plaintext (mentions are
processed and replaced by html links before the message is stored in DB).
The solution is to escape them just before processing the mentions. In the case
of chat windows, we must be careful because chat windows are also used for the
livechat, for which messages are plaintext. So the escaping should be done for
chat windows in the backend, but not in the livechat.
Partial backport of 9.0 commit a14f89c8 to 8.0
<base href=""> are not well supported in some webmails
Replace absolute URLs by full path appending the domain.
Closes#10062
In case of registration with an already existant user, an SQL error 'duplicate
key value violates unique constaint res_users_login_key...'
Replace by a more user friendly error.
Fixes#10068, opw 659913
Currently, the m2m tags widget would only display the name present in
the "name" field. This prevent them from being used with custom
fields/models and other niceties.
opw-658490
Before this revision, in the ecommerce,
a new payment transaction was created only
when the transaction reference was different than
the order number, meaning that the transaction id
in the user session no longer refers to the current order,
that the user created a new order which has nothing
to do with the transaction he has in his session
variable `sale_transaction_id`
This made sense when the transaction reference
strictly matched the order number, but,
since f89e8f9df2,
this is possible that a payment transaction reference
number no longer strictly matches its order number,
as the transaction reference can contain `-1`, `-2`
at the end of its reference, meaning there was
already another transaction existing with the sale
order number as reference. But the transaction
is still about this order.
Therefore, from this revision, the condition on
which a new transaction has to be created
should no longer be based on the transaction
reference, but to which `sale_order_id` the transaction belongs.
In addition, we add two more conditions for which a new transaction
should be created:
- The transaction has been cancelled or in error
- The acquirer has changed.
For the second case, this is to handle a corner case:
- The user selects one payment acquirer (Ogone), then click
on "Pay now", and is therefore redirected to the payment provider website (Ogone)
- Then, the user opens a new browser tab on the ecommerce, on his cart,
choose another payment provider (Paypal), then click "Pay now" and is
redirected to this second payment provider website (Paypal),
- Then, the user comes back on the first tab, on which he is on the first
provider website (ogone), and pays/validate the payment
- Then, we receive the payment feedback (either from the user/DPN, either from
the server to server call/IPN)
Before this revision, this use case would have lead to the feedback from the first
provider (`/payment/ogone/accept`) while the transaction is set with the second
payment provider (`Paypal`), therefore breaking the payment validation.
Creating a new transaction when the user changes of payment provider solves this issue.
He will nevertheless be able to pay twice, on each provider, but it was
already the case before.
opw-659294
Reverted because it causes issue #10083 when serializing
nexted x2many values, and produces invalid x2many commands,
such as:
`[[6, false, [[5, false, false], [6, false, [8]]]]]`
Pending a proper fix for the oririginal issue.
This reverts commit 7e2628aeb2.
Closes#10083
The "delivery" module restricts the access to delivery.carrier objects.
There is no reason to relax this in website_sale_delivery.
Furthermore, nearly all the code of website_sale_delivery accesses
delivery.carrier in sudo mode already.
Closesodoo/odoo#9812
The function "_store_average_cost_price" doesn't have to update
the average cost price of a product if qty of the product in the move
is equal to zero.
opw:659329
The current code to show reccurent event would mingle on a searched
domain and add recurrency test leaves as alternative next to a leaf:
('start{,_date,_datetime}', '>=', '{date value}')
But in 43a12e9 the domain generated by the client was simplified, but
the had not yet been updated to reflect this change.
fixes#9165closes#10084
opw-658241
In 9.0, we created a simplified form view for mail templates, in
which the model_id field is retricted to show only the models for
which mass mailing makes sense. However, two of those models were
forgotten. There should have been some sort of override in their
respective modules, but considering the nature of the domain
attributes, there is no easy way to write such overrides, which is
probably why there wasn't any override to begin with. We decided
with tde and al to just add these models in mass_mailing, thus
breaking module abstraction, but avoiding a very complex override
mechanism for a rather simple case like this.
The list_price field doesn't take the extra price of variations
into account. Actually, it's not even a field of product.product.
The lst_price, however, is defined on both product.template and
product.product and does account for the extra price of variations.
OPW 659330
User can't edit the first and last chars of a link (same issue for a lot of editors), and users don't want to click on edit link button in the editor bar.
When the user click (not if the user use arrow) on a link the link is activate with a content editable true and can edit the first and last chars.
opw: 654280
* chat windows:
- input was kicked out of the window on chrome 43
- don't animate if folded by default (e.g. after a refresh)
- width and height 100% like in the frontend
- z-index to make sure that they are over bootstrap active btn,
but below notifications, and modals
* chatter:
- internal note: send button renammed to 'Log'
- send button is the first button again
- remove annoying form view widget's tooltip
* client action: focus on composer on channel change
- Don't display livechat button if no operator available
- Livechat windows persistence through website pages
- Auto popup feature re-introduced (inadvertently removed at rev. f23f57cc)
- Operators that are 'away' are available, as 'away' means that the focus isn't
on the Odoo tab for at least 10 minutes, but the user is still connected.
- Avoid duplicated messages when the visitor is a connected user
- Unfold livechat window on first 'close' click as the event is intercepted to
ask the user feedback before actually closing the window
When the partner already had a user,
checking `in_portal` of this partner and applying
the wizard raised the fact there was already a duplicated
user for this email, even if there wasn't.
This is because the system relied on the fact
the field `user_id` of the `portal.wizard.user`
was automatically filled with the partner user if
there was one, but it was not the case:
This `user_id` field is a simple many2one field,
not computed, and the assignation was done nowhere
when the partner already had a user.
The assignation should be done in the `onchange_portal_id` method
of the `portal.wizard` model, like the other fields
`partner_id`, `email` and `in_portal`,
but if we do it know, as the `user_id` field is not
in the view (not even in `invisible`), the
web client will ignore it even if returned by
this `onchange_portal_id` method. It was therefore pointless
to solve this issue by adding the correct `user_id`
in the `user_ids` returned by this onchange method.
We could add `user_id` in invisible in the view,
but existing databases with the current view
will not benefit of the bug fix without updating the according view.
This revision therefore replaces `wizard.user_id` by
`wizard.partner_ids.user_ids[0]` everywhere where it's needed to
know if the partner already has a user or not.
Besides, it takes care about the fact his user could
be disabled (`active` False).
opw-659339
Delegate the whole default sales team computation to the _get_default_team_id
of sales team to ease the overriding and understanding. Otherwise part of the
behavior is implemented in crm, part in sales team, leading to a difficult
overriding.
Order
- team the user is member of
- team in context
- Direct Sales
When adding a line in a PO with the SUPERUSER_ID all the record rules
didn't apply on him. Then all the supplier taxes set on the product
were written in the PO line even if some of its were not in the company
of the user. Then with the SUPERUSER_ID, just the company taxes of this
user must be applied. Inspired from product_id_change in model
'sale.order.line'.
opw:659236
Description: When updating the product module, if the "Service"
product.product has been deleted, but not the corresponding
"product.template" part, the update will crash on a "duplicate xml id"
error.
This commit fixes the bug by :
- Adding the link to existing inherited model xml id in values
- Avoid creating the duplicated XML ID
If the XML ID is found, but orphan, it's simply deleted.
Closes#8966
opw-658454
During database creation via the database manager,
or when using the startup option `--load-language`,
the selected language(s) will be installed as soon
as either:
- the base module is installed/updated (because
base_data.xml includes a call to res.lang.install_lang()
- the registry is loaded (after loading `base`,
the system installs the requested languages, even
if the server is not in update/install mode)
This is implemented by passing a global config
option `load_lang
This behavior was modified as of saas-7 by PR
for the command-line and for the database manager.
In both cases, we don't want the installation
to be repeated the next time either of these
event occur. Essentially the `load_language`
The Kanban view has been refactored recently, and the communication mechanism
between the view and its cards changed. The cards now communicate with the
view by triggering_up custom events.
The code in dashboard overrides the function open_record of the Kanban view to
allowing opening a record by clicking on a card directly from the dashboard.
Unfortunately, this code hasn't been adapted after the Kanban refactoring.
There was a weird bug on chrome when there was a scrollbar in the sidebar, as
the right part of the client action overlapped that scrollbar. The problem was
seemingly linked to the use of flex, which is removed by this rev.
Courtesy of QSM
Denis Ledoux