When X is adding Y in a discuss channel, the recieved notification was:
- if read in discuss: from Y, "joined the channel" (no information who added him)
- if read in email: from X, "joined the channel" (misleading, think X was the
one joining the channel)
The problem comes from the author_id in the first case and the email_from in the
second, both containing a different value.
Also correct a bad api.multi parameter
New rights were applied on hr.employee with this commit https://github.com/odoo/odoo/commit/2d777d5ade94f4a80862608e2807660f289d9923
Since, users with limited rights would see a read error when submitting an
expense to manager.
Indeed, when clicking on "SUBMIT TO MANAGER", it opens the view form for
'hr.expense.sheet' that trigger an onchange on employee_id to set the
employee's private address to the expense.
Since restricted users can't read that field, the rpc call to that onchange
was throwing an error resulting in:
1. Showing an read error when entering form view that user could close to
save anyway.
2. The hr.expense.sheet address would not be set as it should have
Now, we give sudo rights to read that field during the onchange
OPW-815786
When a picking is in 'Waiting Another Operation' state, there is no
possibility to force the validation. In v10, it was possible to force
the reservation, which is not possible anymore.
Therefore, we make the 'Validate' button accessible in the mentioned
state.
opw-817234
The generic payment form introduced in 11.0 has changed the way we collect payment and so does the code.
The route /website_payment/pay hasn't been changed to support the new payment form.
This commit fixes this.
It also fixes a bug for when a customer tries to create two transactions with the same reference.
Before the patch, validating a picking where one of its move do not
have any quantity done nor quantity reserved resulted in the complete
validation of the said move. This doesn't make sense and does not do
what the help in the wizard indicate (process only *reserved* quantities).
We also use this patch to clarify what the tests on this workflow is
doing (test_immediate_validate_*). We completely replace the 3 as it was
testing the `force_assign` mechanism, which methods are still present in
v11 but unused. Instead this test is now testing the failing flow this
commit is fixing.
We thus adapt the `process` method of the immediate transfer to only
process the move lines (move line = reservation). We also fix a case
where nothing is reserved and nothing is done. In this case, the
backorder wizard should not opens but instead an UserError telling the
user to either cancel or process something. The testcase for this flow
is test_immediate_validate_7.
With these changes, the test `test_04_create_picking_update_saleorderline`
was failing because one of the items in the so lines was a stockable
product without stock. So before this patch, everything was processed,
now there's a backorder wizard. We complete the patch and duplicate it
with enough products in stock, so that the backorder wizard is not
needed.
opw-815056
opw-808126
Purpose of this merge is
* to introduce a new notification template much more up to date with
modern convention about emails;
* to introduce a new method allowing to push notifications to recipients
that are not necessarily linked to a document. Those notifications
can be either Inbox or email according to user existence and
notification type choice;
* to make assignation email use this notification mechanism instead of
an hardcoded email;
Please see commits under this merge for more details about why, what and
how it was done. This merge is related to task 51517. #Closes #22670 .
Current behavior when assigning someone as responsible of a document is
to send him an email if he works using emails. Technically it is done
when writing on user_id field and based on notification_type field value
of the user.
This commit changes that behavior to push a notification to the new
responsible. It uses the recently-introduced message_notify method
allowing to push notification to recipients without being linked to
a document. It means people working in Odoo receive a message in their
Inbox while people working by email receive an email.
Assignation message contains a link to the document meaning it is always
possible to go to the document. Notification email uses the new template
defined recently. It allow to have a notification email a bit classy.
This commit implies that more notifications are created. Indeed previously
to this commit no notification were created for partners without user
or for users working in Odoo. There is therefore a performance test whose
counter increases and a slight increase in query count when installing
all modules, about 1K queries on 581K.
Mail API contains a message_post method allowing to post a message on a
document. In some cases we would like to push notifications to recipients
that are not necessarily linked to a document. For that purpose we
introduce message_notify. It is a shortcut that prepares the message and
speeds up the computation by pre-computing message values. This method
calls message_post and therefore the whole notification process. It
means no custom code for pushing inbox or email notifications is necessary.
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
This commit adds a new QWeb layout mail_notification_light. It is a new
lighter template using more modern styling. Its purpose is to be used as
a basis for all future templates used in notification mechanism (chatter,
sale orders, ...). During some time all templates will exist separately.
Future commits will gradually improve or add various notification
mechanisms. This new template will gradually be used more often in order
to replace old ones.
Thanks to @est-odoo for its in-depth testing of the template.
Steps to reproduce the bug:
- Connect as demo user
- Create a repair
- Add a product
- Save
Bug: An access error was raised because the demo user has no access rights
to write on product.product
opw:816645
Revision on recent JS refactoring: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
Intermediary changes have not been updated with final way of communicating
with JS services. In particular, widgets must now explicitly call the
service with this.call instead of relying on a mixin that hides the service call
(e.g. the chat_mixin that has been removed)
Rev. on this commit: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
A consequence of the above commit is that @ mention were broken:
the dropup menu with partner propositions was not displaying when
the user typed the first characters to mention a user (e.g. by typing
"[at]demo" in order to show the proposed mention "[at]Demo User" in a dropup
menu).
This commit fixes the issue by reverting the logic of how mentions are provided
by the chat_manager, while removing some dead code.
note: [at] = @
Before this commit, if we wanted to add channels on rpc initMessaging,
we had to mock this rpc completely.
Now, with this commit, we can use data 'initMessaging', whose keys
can overwrite the default mocked initMessaging.
For instance, if this.data.initMessaging has the key 'channel_slots',
then the mocked initMessaging rpc will return a new state for the
existing channels to the chat_manager.
This is needed in order to reduce the size of tests than need some custom
initMessaging state, such as any test that needs at least one non-static
channel (i.e. neither channel_inbox nor channel_starred).
Before this commit, phantomjs was crashing when some code manipulates
window.getSelection (such as the composer input in discuss or in the chatter).
This commit lets us mock window.getSelection in tests that need this function
in order to work properly.
Another benefit of this commit is the possibility to simulate the state of
window.getSelection in our tests, which enables tests on the composer that
were not possible before (e.g. making sure that mentions and emojis are
correctly rendered in the input, after the user clicked on them in the dropup
menu or the bottom bar.
This commit adds a first test of discuss, which checks that the
essential DOM elements are present when we create a discuss widget.
In particular, there should be a sidebar that contains links to
channel_inbox and channel_starred.
In order to test discuss, the service 'chat_manager' has to be ready.
We do not want to explicitly write discuss.call on any test with discuss,
so now the function createDiscuss returns a promise that is resolved with
the discuss widget when the chat_manager is ready.
Discuss has to perform a rpc to fetch messages of its channels.
Some tests do not care of the result of this rpc call, so we mock
it by default (by default, channels have no messages in our tests).
When changing the routing on a bom, "Consumed in Operation" indicated
in some lines of the BoM did not correspond to the routing used.
So the system did not link it to a workorder and it was never consumed when
a MO was processed.
Now the "Consumed in operation" are reset when the routing is changed.
opw:807560
This commit improves link creation in web editor.
Before this commit, anything with a @ would be considered as valid email which
is obviously not the case. It would then be prefixed by 'mailto:'.
This was causing 2 issues:
- URL with @ symbol in it would have 'mailto:' added as prefix, like google
maps coordinates.
eg: mailto:http://www.google.com/maps/whatever/@312211.22,321321
- Incorrect emails would go through (eg: @@@, ko@k@k@, mail@mail)
Now, we will try to detect and identify valid emails from invalid emails from
URLs. It will also handle 'mailto:' directly typed in the input.
This commit comes with it's counterpart in enterprise https://github.com/odoo/enterprise/pull/1859
This closes#11984, closes#22936
Note that there is a WIP in master to use this new is_email function
everywhere we try to validate emails. It will aim to uniformize email
validation in odoo's javascript that are often performed with different mean
here and there, some more permissive than others, some only checking for @.
It happens from time to time that someone use "Format" on the
web.layout template. Thus:
```
<script type="text/javascript">
var odoo = {
csrf_token: "<t t-esc="request.csrf_token(None)"/>",
};
</script>
```
becomes:
```
<script type="text/javascript">
var odoo = {
csrf_token: "
<t t-esc="request.csrf_token(None)"/>",
};
</script>
```
breaking a number of things on the frontend and everything on the
backend.
On a pure javascript content, we could wrap it with:
```
//<![CDATA[
/* javascript content */
//]]>
```
but in this instance we still want the xml to be processed.
This commit avoids formatting XML containing a script tag.
opw-815865
closes#23164
Before this rev., an issue occurred on grouped editable list views
that became ungrouped after a reload (i.e. when the grouped part in
the search view was removed). In this scenario, the click handler
outside the list used to leave the edition wasn't bound (because
the list was grouped at the beginning, and thus not editable). So,
it was impossible to leave the edition, even by clicking on 'Save'.
Fixes#23061
When having a default template for quotation
Doing a sale order through the website
Before this commit:
The field require_payment on the SO was not matching the one on the template
This leads to confusion at config time when on the backend something is set on the template as default
while not matching what actually happens
After this commit:
The field require_payment on the SO is computed from the template
OPW 807946
This commit only concerns the community webclient. The user can
edit the company data by clicking on the company logo displayed
in the submenu (left bar). When it does, the logo's url must be
updated to force the logo to be reloaded.
The last part doesn't work since the new views, as it uses an
hook of the form view (called when it is saved) that doesn't
exist anymore.
This rev. adapts the code so that the logo is reloaded when the
edit menu dialog is closed.
It also ensures that the logo is properly reloaded by specifying
the timestamp in the img url as a query string parameter instead of
an hash param, since changing the hash doesn't seem to be enough to
fool the browser's cache anymore.
From a recent action manager refactoring (https://github.com/odoo/odoo/commit/32b8cec5361174c92c45a4975d4e02f1fb448aa2),
the attribute 'views' in viewOptions is now structured as follow:
viewOptions: {
action: {
views: [{
viewID: 1,
type: 'list',
}],
}
}
instead of this:
viewOptions: {
action: {
views: [[1, 'list']],
}
}
The pivot view was not updated correctly, so now it should be correct.
When executing an act_window action, the ActionManager has to
determine whether or not the first view of the action is a form
view (typically, when this happens, this is also the only view of
the action, and most of the time, it is displayed in a dialog, i.e.
the action's target is 'new'). This ensures that the control panel
is correctly shown/hidden, that form buttons are correctly rendered
and displayed at the right place, and so on.
Before this rev., it uses the view_mode to do that, but there is no
guarantee that the view_mode is even defined (for instance, actions
returned from python methods don't have to define it), so from now
on, we use the 'views' attribute instead, which must always be set.
This commit adds demo data to populate
the project overview with billable
timesheet on sold projects and tasks.
This will ease the testing and reinforce
the wow effect during demonstration.
Note: those demo data should never be
involved in python test cases.
Closes#21132
Before this commit:
If you changed the URL of a menu linked (m2o) to a website page and the new URL
was already taken by another page, it would edit the menu.url and the
menu.page.url resulting in the menu's page having the same URL than the already
existing one.
Now, if you edit the URL of a menu linked to a page and the URL is already
taken by another page, we will simply change the menu/page m2o relationship
without writing on the menu's initial page's URL.
For a better tracability, we will have 2 journal entries directly created from the validation of a voucher in 'pay directly' method:
- one regular for the sale/purchase in the selected journal
- one for the payment in the selected payment journal
both being processed normally and automatically reconciled together.
This allows to have no difference, in terms of existing document and tracability, between a voucher created with payment set to 'pay directly' and another, paid in another mean afterwards.
Was PR #22108. Was task 43712
In chatter, also linkify URL with IP address as domain name like it may
be in other part of Odoo (eg. plaintext mail received).
With this change, an URL:
http://192.168.0.1:8069/web
would be linkified.
opw-816175
closes#23153
The correct model description is set in hr_payroll.
The model does not change when installing a new module ("payroll run" was not
very meaningful anyway)
Martin Trigaux