Forward-port of ffee5bdbd12b0080349da515d01981943355d0cd;
because of 1a315e87b05fcbdefcb3db6d8d4837f6cc3e835c by the same author,
only the following are left:
- we need to translate the untranslated message
- give the temporary cursor a name different from cursor or cr
so that _'s _get_cr method does not get the closed cursor
closesodoo/odoo#41140
X-original-commit: 926873031d479ec96ca122fe8c3a481b31f2a32b
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Note that this also add data-oe-model and data-oe-id in XML.
This allow us to avoid to load these links as external URL when
a user receive it in inbox instead of external mail client.
See file addons/mail/static/src/js/thread_widget.js -> _onClickRedirect
Task ID: 1895451
closesodoo/odoo#39958
Related: odoo/enterprise#6414
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit fixes the traceback that happens when we try to create
a question from the survey form in mobile mode.
The problem was due to the context not being propagated
to the "add record" button that appears in mobile mode.
Therefore, as we use that context in our widget, it crashes.
The solution to this is to just use the normal tree view behavior
instead of our override when we are in a mobile environment.
LINKS
closes odoo/odoo#41143
Taskid: 2071342
Pr: #40694
X-original-commit: 0dc7d956c59dfbece1f05e475c227affd51ce435
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the traceback that happens when we try to create
a question from the survey form in mobile mode.
The problem was due to the context not being propagated
to the "add record" button that appears in mobile mode.
Therefore, as we use that context in our widget, it crashes.
The solution to this is to just use the normal tree view behaviour
instead of our override when we are in a mobile environment.
LINKS
Taskid: 2071342
Pr: #40694
X-original-commit: b394a67ccd527b4ff88f0b59083fd3b59cf97681
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Some cleaning is performed prior to that change of ACLs, done in separate
commits. This cleaning includes
* ease the use of mail.thread tool method _message_compute_author by
cleaning its api (return tuple instead of dict);
* give a way to access to company email and catchall with formatting.
Those will be used in various automated emails. Indeed currently several
templates use either ``company_id.partner_id.email``, ``company_id.email``
or even don't provide fallback values;
* improve mail creation calls, notably author and email from default
computation. Purpose is to correctly compute author_id and email_from
in mail_message and mail_mail as they depends from each other. Moreover
it is a good idea in various flows to specify email and author when giving
creation values to avoid default computation that is not always guaranteed
to be accurate notably when involving super user;
* improve author / email_from synchronization in default values in mail
composer;
* clean some calls to mail.template send_mail();
Task ID 1853147
PR #32243
Related: odoo/enterprise#4001
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes 2 issues, both coming from a misbehavior in
`get_nearest_lang()`:
1. Anyone could reach the website in a lang available in backend but not in
frontend. Eg, french is activated but not a website lang, going to `/fr`
would show the page in french.
2. As a logged in user coming from backend in a lang not available in frontend
(has request.lang set to that lang), the website would show a 500 error page
since it would not filter out the current request lang.
Both these issues are fixed here by ensuring langs are filtered out if they do
not belong to the frontend (website langs).
Step to reproduce (bug 1):
- Install french in backend lang (not on website)
- Visit `127.0.0.X/fr_FR`, the frontend will be displayed in french even if
it not a lang available in frontend.
Step to reproduce (bug 2):
- Install french on frontend and remove english from frontend
- Navigate to the backend /web
- Navigate to frontend, it will crash
Fixes#40572 and fixes#40078closesodoo/odoo#41146
X-original-commit: 4bfba037fbbf34c178abd532f7bf52b94ae40b27
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Purpose of this commit is to correctly compute author_id and email_from
in mail_message and mail_mail as they depends from each other. Moreover it
is a good idea in various flows to specify email and author when giving
creation values to avoid default computation that is not always guaranteed to
be accurate notably when involving super user.
Mail message creation could lead to desynchronized values between author
and email_from. This is improved with this commit by correctly inheriting
from default_get and computing both of them at the same time instead of having
two default values. Indeed they depend on each other.
Same thing is done for mail composer. Mail Thread offers a tool method to
find email_from / author_id based on having one of those values or current
user and it is called whenever necessary.
Some calls to mail template send_mail are also cleaned.
Task ID 1853147
PR #32243
Purpose of this commit is to give a way to access to company email and catchall
with formatting. Those will be used in various automated emails. Indeed
currently several templates use either ``company_id.partner_id.email``,
``company_id.email``, or even don't provide fallback values.
With this commit from a company record people will be able to use
* a correctly formatted catchall: ``"My Company Name"
<catchall_alias@catchall_domain>``
* an email_formatted field like partner email_formatted that is either its
partner-related email_formatted value, or formatted catchall if its partner
is not correctly configured;
Various calls to mail creation are updated accordingly.
Task ID 1853147
PR #32243
Purpose of this commit is to ease the use of mail.thread tool method
_message_compute_author. Instead of returning a dict with two values and
having to unpack them, directly return a tuple with both author and
email_from values. All calls and return management are the same in mail.
Let us simplify code.
Task ID 1853147
PR #32243
- Install project_timesheet_holidays
- Create a company with any user (except the SUPERUSER)
An AccessError is risen.
This is because the new project is created in the new company, but the
user is not in this company. The record rule `project_comp_rule`
prevents the constraint to be evaluated.
`sudo` seems the only solution here...
opw-2146153
closesodoo/odoo#41144
X-original-commit: a7d24cabafe1a9c71f9dbdb7cf3f129006250951
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This is a first step towards more complex behaviors in the left panel
and more possibilities with standard XML options. The main goal is to
use widgets for internal option components (checkbox, button, input,
colorpicker, ...) as a way to receive a value for an option method
(selectClass, selectStyle, ...) while the two parts of this system were
both handled by the option before.
For example, now, a developer can say: "I want a colorpicker to style
the border-color of this elements" or "I want the combination of two
inputs to be set as a data-example of this element" without writing
any JS.
See sub-commits for details.
In preparation of task-2122935
closesodoo/odoo#40282
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In a normal flux, this happen when an option is hovered and left:
1) Hover event -> the widget goes in 'preview' state and notifies a
preview to the option
2) The preview is received by the option and, after an internal mutex
resolution, the option enables its methods with the widget values.
3) Leave event -> same as (1), except leaving 'preview' state
4) same as (2), except receiving a 'reset'
Everything is fine and correctly managed... except if a JS code triggers
both hover and leave events in the same execution... and this is what
tests are doing. In this case, as (2) executes after an internal mutex
resolution, the points (2) and (3) were inverted, so the widget left the
'preview' state before (2) got the widget values.
Maybe the test system has to be improved, but this commit solves the
problem for this case explicitely.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
* website, website_blog, website_sale
Some snippet option already needed to implement this by themself and now
that they use custom widget, this is even more needed. The long-term
goal is that developers should not have to override the onFocus method
or the updateUI method but only the _computeWidgetState method.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
* web, mass_mailing, website
Introduced a new sub-widget for snippet options: we-colorpicker. This
allows to retrieve a color value (either a normalized css color or a
theme color name) to be used for a snippet option method.
This commit replaces the old 'colorpicker' snippet option whose behavior
is now simply achieved by defining an xml option using a we-colorpicker
widget in combination with the 'selectStyle' standard method.
This commit also adds the possibility to control the border-color of
elements alongside their border-width. Again, just a we-colorpicker
widget in combination with the 'selectStyle' standard method.
Note: this commit reviewed what the colorpalette palette widget
notifies. This is not a cssColor and a 'isClass' flag to say if it is
a css class or not. The colorpalette always returns a color string which
can be the name of a color like 'alpha'. This is up to the caller to
check if the color string is a css color or not with isCSSColor. In the
case it is not, the related code can read the actual color by reading
the related css variable.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
* website
Review colorpicker methods to always allow to use normalized colors.
Also factorize some code in the color palette widget.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
Before this commit, the rendering of inner content of the left panel
options was handled through _buildXXXElement methods in the options
widgets. Now they are handled through sub-widgets which also handle
the user events.
Each sub-widget is notified with the string value it should hold
according to the snippet option target and methods. Each sub-widget
notifies a string value following user interactions, which snippet
options can use to adapt their target through their option methods.
The current sub-widgets introduced by this commit are (others will
follow):
1) we-button
2) we-checkbox
3) we-input
4) we-select (typically containing multiple we-button widgets)
5) we-multi (typically containing multiple we-input widget)
Following this commit only 3 standard option methods remain, which can
be used with any meaningful widget:
1) selectClass
-> Same as before + handle the old 'toggleClass' method when used with
a checkbox-like widget.
2) selectStyle
-> Same as old setStyle, introduced recently (simply renamed)
3) selectDataAttribute
-> Handle both old selectDataAttribute and setDataAttribute, introduced
recently
The parameters these methods received are now:
- previewMode: same as before
- widgetValue: the string value the widget currently holds
- params: additional parameters (mainly dataset of the related xml)
+ params.possibleValues (all the possible values for the method,
meaninful for a select or a checkbox)
+ params.defaultValue (the value that the widget would give if it
even holds no value)
When defining a method in XML, the given value is the default value.
e.g. data-select-style="34px" data-css-property="margin-top"
-> if set on any widget, allows to retrieve a value from the user to
customize the margin-top, the default value being 34px.
-> if used with a we-input, allow to retrieve any value and an empty
value will be equal to 34px
-> if used on a checkbox, allow to toggle between no value and 34px.
-> ...
Hopefully, detailed documentation about all of this will follow. Code
documentation should already be helpful.
Last note: the _updateUI method (replacing the old _setActive) is now
async (so does all the functions calling it). In particular, the _select
method is now async.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
* website, website_sale
Also make the "isTopOption" method a property.
This is done in preparation of better code for coupling sub-widgets used
to retrieve user value (button, input, colorpicker, ...) to actual
change in the edited DOM through snippet options methods.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
Now, the editor UI can suggest options the same way as select-class but
for editing a data attribute.
Note: the public widgets are now refreshed on data attribute changes
through the select-data-attribute and set-data-attribute methods.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
Currently when you open, for example, 5 chat windows on the desktop,
each of those windows will be opened on mobile as well.
The big issue with that is that I have to shut down all windows before
starting to work on the application.
To make things simple, you have to explicitly open chat window to
make it appears on mobile. Synchronization is blocked in both direction.
We don't update the chat window state on the server and we no longer
consider notifications (bus) about it.
Tests were added in enterprise.
Task ID: 1891952
closesodoo/odoo#41052
Related: odoo/enterprise#6943
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Missing / wrong indented code during rewrite of binary controller:
https://github.com/odoo/odoo/commit/7d85ab1#diff-1407a8ce197a04eefaefa26c127a4418L343-L348
In case you have:
<record id="s_cover_default_image" model="theme.ir.attachment">
<field name="key">website.s_cover_default_image</field>
<field name="url">/web/image/theme_treehouse.bg_img_15</field>
</record>
theme_treehouse.bg_img_15 will be not found in /web addons.
So we need a 301 redirect too.
opw-live
How to reproduce:
odoo.com/trial > Website > Install theme Clean
Drop first snippet > background is 404
closesodoo/odoo#40605
X-original-commit: b8ce93e4eb397e1b7a0e1d408d61d2f283223fb9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Old heuristic is not more True:
Force to check method to POST. Odoo uses methods : ['POST'] and ['GET', 'POST']
We have some controller that only allow 'GET' method, so we need to check GET
also when we try to know if an url is multilang or not.
This commit fix case where a controller '/test' only allow GET and you were in
another language that the default, in this case, the rendered url in qweb was
/get instead of /<lang>/get.
Closes#37223closesodoo/odoo#40519
X-original-commit: c7650106f8588083be12812600a6c94ba703fd6f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Introduce a new account.tax.report object
> Tax report lines now refer to a tax report, and the tax report to a country
- Tax report lines can share tags accross reports within the same country
> To support the cases where some report is a simplified version of another one: some of its lines can be computed in the same way as the 'bigger' report.
> This is done by giving the same tag_name to the tax report lines, and the same country_id to their parent report.
> Full support for tag name modification, and the way it impacts the shared tags (sometimes, we can overwrite them all, sometimes we must delete them, sometimes, we create new tags to replace them on some report lines).
- Support copying tax report (and the lines/tags linked to it), so that it is possible to duplicate them and change the country set on the duplicate for use in another country (coopying is way better as replacing in place, as we don't keep any link to an xmlid, and still allow using the original report in the original country it was created for).
- Make all l10n* modules compatible with those changes
closesodoo/odoo#38964
Related: odoo/enterprise#6217
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Reproduce the issue
- Install Sale
- Create a quotation template with a product price that is different
than the price on the product form.
- Create a quotation
- Select a customer then the quotation template
The product price is not the price mentionned in the quotation
template
Cause
In the method `onchange_sale_order_template_id`, if we have
a pricelist set and the discount policy "with discount" we
use the price of the pricelist instead of the price of the
template line.
This commit use the template line's price if the discount policy
is not 'without' discount and if there is a template line's price
OPW-2146210
closesodoo/odoo#41139
X-original-commit: 1ed2c4dcb76f462497ae669372077446be3dd738
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If the name of a file input field is 'x_binary_input', before
commit 9be29371abcdfe57b1738484c5057ad81e76b00d (opw 2092653),
self.form_fields would have names of the form 'x_binary_input[i]'.
After this commit, they are of the form 'x_binary_input[i][j]'.
When calling extract_data, field_name would then be 'x_binary_input[i]'
instead of 'x_binary_input'. Therefore, the file would be considered as orphan
instead of being attached to x_binary_input.
We thus change the split so that it always returns 'x_binary_input'.
opw 2122624
closesodoo/odoo#41135
X-original-commit: 21ed2b971f66879fa3fa53dbd2c349ab39fa3fdb
Signed-off-by: fah-odoo <fah-odoo@users.noreply.github.com>
This reverts commit 802817c925.
The new test was crashing when current weekday is Friday.
This is easy to fix, but some other considerations are missing in
the original commit, like taking into account timezones.
We will add a proper fix later, and revert now in the meantime.
closesodoo/odoo#41123
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Create a sale order in POS with generate invoice option enabled.
When the user timezone is creating a day difference with respect to UTC
the date reported on the invoice will be wrong. This is caused by the
invoice date being written using `fields.Date.today()` , which is using
the UTC date. Respecting the order_date fix the issue
opw-2129440
closesodoo/odoo#41121
X-original-commit: 34fcb7300a8eb73b39f5f871e3553f036d6f3639
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Some parameters were missing, leading to incorrect SHA-OUT calculation
on Odoo's side. Some were removed as well.
opw-2121544
closesodoo/odoo#41114
X-original-commit: af184e7c4fb89752263a53794e4807f601587ecd
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Change the version of the IoT Box.
From 19_10 to 19_12
closesodoo/odoo#41109
X-original-commit: 2b8779dc657a5a2b877ad2a552dd0dfda0071357
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
1) Don't set an amount_currency without currency_id set.
2) Use the journal's currency only if different of the company one.
closesodoo/odoo#41094
X-original-commit: 3dd8bf6a38704df0db4f0879e685d2230be572a2
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task creation was crashing when there was no project selected in the
kanban's quickcreate window.
closesodoo/odoo#41006
Taskid: 2146564
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Fixes issues where static multi-company filtering would get squashed /
replaced by dynamic domains not having those filters.
The conditional could be replicated in two ways: one would be to use a
python-level conditional expression:
a if cond else b
this is easier for users to interpret, but harder to analyze: python
expressions are currently opaque to view analysis (and possibly
eventually to domain edition).
The alternative here is to leverage domain simplification:
(OR (= (not cond) 1) section)
if `cond` is true becomes
(OR (= 0 1) section)
and thus `section` itself, while if `cond` is false it becomes
(OR (= 1 1) section)
and thus `true` (so the section doesn't apply).
It works OK though the inversion of the condition itself is a bit
bizarre.
And in this specific case since we need both branches the negated
condition requires explicitly converting the condition to a boolean if
it might not be one: the expression compiler recognizes specifically
`(= 0 1)` and `(= 1 1)` (`(= False 1)` and `(= True 1)` also work for
Python reasons).
[REM] dynamic domain from hr_timesheet
closesodoo/odoo#40945
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
There are no mentions that a module may contain In-App Purchases in Apps.
We should inform the users of this so they make a conscious decision when
installing such app.
closesodoo/odoo#40731
Taskid: 2129214
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The current 'Base Action Rule: check and execute' CRON search every
four hours for delayed actions to run. This mean, any action scheduled
later can be delayed up to four hours.
We now dynamically reset the CRON frequency according to the least
delayed automated action to minimize the potential gap.
closesodoo/odoo#40633
Task: 1998809
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose is to ease designing your courses by allowing to create and update
slide quiz directly in frontend, within the slide display.
With this commit you are able to
* add a quiz to a slide or add a question to an existing quiz;
* edit an existing question from a quiz:
* change the title of the Question;
* add, remove or update answers;
* change the right answer;
* delete an existing question;
* reorder the questions from a quiz;
* reset the quiz for the current user if he is a website designer, allowing
to test the quiz and its answers;
New frontend widgets are introduced allowing to manipulate quiz. Slide page
now supports a readonly / taking quiz mode and an edit mode for quizzes
used notably for website designers / course maintainers.
Task ID : 1999636
PR : #35326
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently there are several checks on answer integrity for slide quiz
questions. In this commit we simplify code to effectively implement
what is requested: 1 valid answer and at least 1 invalid answer.
Task ID 1999636
PR #35326
New multi-company guidelines for 13.0 documentation explain the use of
force_company. This is still valid in 13.0, but removed in 13.1 and
replaced by the with_company mechanism.
closesodoo/odoo#41108
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The trailing check on the fiscal year lock date is wrong and is
triggered whatever the values passed to 'write'.
closesodoo/odoo#41100
X-original-commit: 5b3486a434dbb0d9d1ed583e59f6b478b33e9745
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Afschrijving means depreciation.
However all depreciation lines have been copy-pasted with
wrong tags and types:
e.g. Aanschafwaarde overige immateriele vaste activa
has a counterpart Afschrijving overige immateriele vaste activa,
the first user_type_id is data_account_type_non_current_assets, but the
counterpart should be depreciation; similarly tags should go to their
Afschrijving counterpart.
opw 2115991
closesodoo/odoo#41071
X-original-commit: edac3bf4147aa4853660621b6c34f3a750882a94
Related: odoo/enterprise#6953
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
We clean the code for the MPDManager by removing useless lines and
simplifying the way we run the MPD server.
closesodoo/odoo#40892
Related: odoo/enterprise#6892
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit adds the out-of-office ribbon at the top of the
conversation in the discuss app.
Task-2066672
closesodoo/odoo#39362
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Fixes the way record end hours are computed in calendar views.
Before this commit: objects `record start` and `record end` properties being copied by reference
and being incorrectly rewritten by other functions.
This caused incorrect end hour computations (and a SQL crash in the Planning app).
Now, objects are copied by value and don't interfere with each other.
Task 2072961
closesodoo/odoo#37690
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Nans Lefebvre