**Issue:**
- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
it's displaying all records under each group.
**Solution:**
This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.
closesodoo/odoo#106238
X-original-commit: e5bba9f5eb63ee95924c892801fe18feaef6d1fc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently, in mass mailing, the user cannot be redirected to the next
page after clicking "upload a file" in the import mailing list.
This is because the contact list field is mandatory, so when the user
clicks "upload a file" with an empty contact list, it is unable to
be redirected to the next page, as it saves the wizard before executing the
action.
This commit fixes the above issue by making the contact list field
not mandatory anymore in the wizard view.
Oversight of: aa183fa29d609d2b608fa451ee48a35e3d1549b2
taks-3070829
closesodoo/odoo#106237
X-original-commit: 21272221ebf22b3075c79a759c8ad8f72825b1ef
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
**Steps to reproduce:**
- go to a product page
- replace image (=> image is shown)
- click on "Save manually" (the cloud upload icon)
- BUG: previous image is displayed.
But it was saved: if you move to another record and return then it
shows the correct one.
**Solution:**
Basically, in an image_field: If its props.value is a "binary size",
then the image source is a url pointing to a server endpoint and
this url is based on the rawCacheKey, otherwise, we use the "base64"
of the uploaded image.
The proposed solution for the said issue is to invalidate the
rawCacheKey during upload. Then, during the calculation of image url
(at `getUrl`), we reassign the rawCacheKey with the newest
"__last_update" value of the record when needed (if the props.value
is a "binary size").
closesodoo/odoo#106236
X-original-commit: 93911daab238e96c8aa9b0a951b9a268d83a9847
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce the issue (see opw):
- Add a form to a page
- Add a checkbox
- Add a second checkbox that is required and visible only if the first
checkbox is not checked
- Save
- Do not check anything and try to send => Good, you can't, the required
checkbox is not set
- Check the second checkbox and try to send => Good, you can, the
required checkbox is set
- Go back to the empty form, check the first checkbox and try to send
=> Bad, you can't but you should: the required checkbox is hidden, it
is not supposed to be required anymore.
(Not that arguably, that two checkboxes setup should be replaced by a
required selection field but the issue of the OPW would remain as there
is another required conditionally-hidden field (a file upload) when the
second checkbox is checked.)
Conditionally-hidden fields should not require validation while they are
hidden. Indeed, their purpose is to be able to enter additional data
when some condition is fulfilled. If such a field is required, it is
only required when visible. The problem only occurred with checkboxes,
the other fields were already working in that case. Although there could
be issues with dates too, this commit added a series of FIXME and TODO
comments as well as some things need to be investigated.
opw-3003952
closesodoo/odoo#106204
X-original-commit: f501c25a9d33399cfbb45526d95038266d91686e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when submitting a website form which has invalid
radio buttons, checkboxes or file upload elements, they had no visual
difference. Now they will have red labels as intended with bootstrap.
For alone checkboxes, a warning label will appear after the checkboxes.
This will only take effects for newly added checkboxes.
Related to opw-3003952
X-original-commit: 3268b4c902c92c12f50081d31eb08d4c330ca03f
Part-of: odoo/odoo#106204
With [1], checkboxes in website forms were wrapped in a <div/> with the
"form-check" bootstrap class (as they should). That forgot to mark the
checkboxes themselves with the class "form-check-input". Without it they
are misaligned.
This fixes the error for newly added checkboxes in forms. Old ones will
stay "broken".
[1]: https://github.com/odoo/odoo/commit/9ea276ae2f00c3a5ba4e10af313085947e70e265
Related to opw-3003952
X-original-commit: b3ff062e8add1e9b810a37112f05a0c1d23136be
Part-of: odoo/odoo#106204
Before this commit, if the user tried to setup a required selection
field whose first value is empty, it was possible but the empty value
appeared as a 0px-height div in the DOM preview. That empty value also
shows up when trying to use the conditionally-hidden fields feature: if
another field's visibility depends on such selection field, the editor
UI was visually broken as the first choice was an empty option element.
Now, we show "<no value>" in both cases.
Note: this is not done in earlier versions than 15.0 although the
problem exists, but it was decided that the real problem was about the
visibility select being visually broken and that feature only appeared
in 15.0.
Related to opw-3003952
X-original-commit: a62f3dbef31c4750ba16d55adf28c235a27dbc56
Part-of: odoo/odoo#106204
When we have too many products from orderpoints we cannot compute the
forecasts for all at once. Otherwise we may get a MemoryError. Here we
iterate by chunks.
This error was observed on upg-417045, where there were 381927 prodcuts.
closesodoo/odoo#106196
X-original-commit: feea4e5f147b3b26cbc032daaf0ceabbe3417912
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909
Fixes 2687380
Fixes 2856101
closesodoo/odoo#106180
X-original-commit: ac0ca14c349e0d70d9f3a1aeb720f5e31f16d63e
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This PR
Reverts the change in #105425 as the code is redundant see Discussion
Fixes the issue and explain the details as it doesn't get triggered from
inventory adjustment view but from current stock view in location X.
Steps to reproduce:
- Install inventory
- Activate storage locations
- Allow import in Locations/WH/Stock/Current Stock
- Export the current stock of WH/Stock
- Change the Location in the file to WH/Output
- Import the modified file
In the Location/Current stock view, the _load_records_write/create methods are bypassing the allowed_fields checks in the def create/write since this check only occurs when _is_inventory_mode() = True. This can cause inconsistencies if there are quants reserved. To solve the problem we set inventory_mode to True so that the method returns True and the checks are triggered (and prevent these inconsistencies).
Task id: 3007499
closesodoo/odoo#106077
X-original-commit: 7240c5b19e9c06fe22a929ca3ec83115c29a5c7f
Related: odoo/enterprise#34153
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously, we had an option on char/text fields called "onchange_on_keydown",
which allowed to trigger the onchange while the user was typing (instead of
when the field is blurred).
It was notably used when typing a phone number in the sms composer, to warn
the user that the phone number is invalid.
This feature was lost during the port to OWL, this commit restores it.
Task-3033107
closesodoo/odoo#106193
X-original-commit: 54def8969d49d6e5284cd97ab8df75e08043cd4e
Related: odoo/enterprise#34211
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The `comment` field was not properly displayed since the move to grid display.
closesodoo/odoo#106197
X-original-commit: bf98d880087ccc562712d82fa690f76d58dedfef
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Update to current runbot state, in order to better spot changes potentially
introduced with this PR.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106182
Related: odoo/enterprise#34197
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since [1], the google map UI to search for locations thanks to the
google map API was not working anymore. Indeed, the lib was loaded
inside the iframe (as it should) but not outside of it, preventing to
use the `google` object in the related editor panel widget. The
autocomplete UI style was also broken as the CSS is not available
outside the iframe.
As a fix, the code outside the iframe now use the `google` object from
inside the iframe (no problem seems to come out of it) and the style is
restored via custom CSS (custom CSS already existed and was already
changing most default style anyway).
As a reminder, this snippet is only available in debug mode or if your
google map key is setup, which we do not allow to enter anymore via
standard flow since 16.0 (15.3).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#106103
X-original-commit: 7d60d0ae4ea195edc4a12e57bf1c3b7c661bcf82
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.
opw-2976261
X-original-commit: 50bf0b7f1677b8125d892fad968ccc8174c974c1
Part-of: odoo/odoo#106103
Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.
opw-2976261
X-original-commit: b761c8fe0762f449bd6d9a1763c152833819247c
Part-of: odoo/odoo#106103
Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.
Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled
Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.
Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.
opw-2976261
X-original-commit: d9f86840e27463ccf370a748cafc7c4be32f901f
Part-of: odoo/odoo#106103
The existing code was generating misleading errors for imported Odoo
modules that could not be loaded. Although there was a specific hack
for module 'studio_customization', imported modules were not handled
properly. This patch adds the right condition in the SQL query in the
module that introduces imported modules.
closesodoo/odoo#106098
X-original-commit: e1cfc1f74000e55473f7a26f0df5a13c4d5094c0
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
PURPOSE
Cleanup usage of rendering mixin: clearly support void recordsets, add tests,
cleanup options.
SPECIFICATIONS
mail: support rendering on void or falsy record sets
In this commit we support calling rendering methods on void or falsy record
sets. Currently some rendering methods prevent from having 'None', some do
nothing specific. As Qweb or inline template support rendering on void records
we can safely support rendering on [], (), [False], [None]. Returned result
will either be void, either contain the rendered on void record for the
False or None key.
In this commit we also add a protection against trying to render a non
existing field. Instead of raising a KeyError, a ValueError is raised with
a clearer error message.
test_mail: add some tests on content translation
Purpose of this commit is to add tests on translations when using templates
and composer, on both email content (body, subject) and email layouting
content (view content, groups-based buttons, ...). This better highlights
some missing part of translation support, notably
* when being in mass mode: as content is taken from the composer and rendered
dynamically, it does not take the original translation from the template
even if it matches template content exactly;
* access button title is not translated as it is added during a separate
part of the process;
mail, various: cleanup usage of options / post process in render mixin
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated accordingly
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
LINKS
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-3046371 (Mail: Improve language propagation in mail and layouting)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
closesodoo/odoo#106072
Related: odoo/enterprise#34147
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We can call ``_render_field`` on template model directly. In this commit
we also add the dynamic language computation through ``_compute_lang``.
It will use the field defined in template.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106072
When calling ``_render_fields`` asked options are now considered as more
important compared to options defined in field itself (using render_options).
Purpose is to allow to force some options when necessary.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106072
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
Finally some 'compute_lang' are explicitly added in _render_field calls in
order to be explicit on what we want, instead of being unsure.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#106072
Purpose of this commit is to add tests on translations when using templates
and composer, on both email content (body, subject) and email layouting
content (view content, groups-based buttons, ...). This better highlights
some missing part of translation support, notably
* when being in mass mode: as content is taken from the composer and rendered
dynamically, it does not take the original translation from the template
even if it matches template content exactly;
* access button title is not translated as it is added during a separate
part of the process;
We also improve tests for ``mail.composer.mixin``. The wizard used in test
(mail.test.composer.mixin) is improve to behave more like a real invite
wizard: it runs on records (mail.test.composer.source) which are records
on which dynamic content is rendered. This highlights one issue with
translations: translations are fetched on current model (aka: composer
body and subject fields). However when using templates, translations are
stored on template model (aka: mail.template). This will be improved soon
by trying to fetch template translations when composer content matches
content from template.
Task-3046371 (Mail: Improve language propagation in mail and layouting)
Part-of: odoo/odoo#106072
In this commit we support calling rendering methods on void or falsy record
sets. Currently some rendering methods prevent from having 'None', some do
nothing specific. As Qweb or inline template support rendering on void records
we can safely support rendering on [], (), [False], [None]. Returned result
will either be void, either contain the rendered on void record for the
False or None key.
In this commit we also add a protection against trying to render a non
existing field. Instead of raising a KeyError, a ValueError is raised with
a clearer error message.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#106072
Currently, the DIN5008 layout is a bit off and some aspects can be improved:
1. some fields are useless/unused (namely country, phone number and duplicated VAT number)
2. the size of the header and footer is too big, leading to out-of-frame text depending on the amount of information to be displayed
3. footer and company details fields (from the document layout) are not used, reducing user's customization
This commit addresses both these issues by:
1. removing useless fields
2. resizing the company information text de be more concise
3. replacing 'hard coded' company details/footer by their respective editable fields, and improving their default values to match DIN5008 requirements
task id=2821303
closesodoo/odoo#100723
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
1. Create a membership product for a period of time in the past,
and one including the current day
2. Create a member, make him non-free
3. Create an invoice for the member for the past membership, cancel
the invoice
4. Note that membership state is not updated to `cancelled` (Problem 1)
5. Change the `date_cancel` on membership.membership.line
to a date in the past
6. Add an invoice for the current membership, note that the state is
updated to `cancelled`
7. confirm the invoice and register payment, note that the state is
not update to `paid` (Problem 2)
This line in `_compute_membership_state` causes the bug to appear:
```
if partner.membership_cancel and today > partner.membership_cancel:
partner.membership_state = 'free' if partner.free_member else 'canceled'
continue
```
To solve the issue, we remove the lines of code that made the state
to be stuck and use the membership lines only to calculate the correct
state.
opw-2978902
closesodoo/odoo#106179
X-original-commit: addd3fbfebddab7572a785a3c27c9f90ddc3408b
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
Current behaviour:
When we are printing a report and then the report fails to generate
(for ex. wkhtmltopdf memory limit/timeout),
the incorrect state is committed to the database.
Expected behaviour:
We should rollback when generating reports fails, since it is an error state.
Steps to reproduce:
To reproduce the behaviour, we need to force an error state.
- In odoo/addons/base/models/ir_actions_report.py:`_run_wkhtmltopdf()`,
raise an exception before spawning the subprocess (for ex. adding a 1/0).
- In addons/web/controllers/main.py:`report_download()`#L2126,
add this little code snippet:
```python
ids = [int(x) for x in docids.split(",")]
report = request.env['ir.actions.report']._get_report_from_name(reportname)
obj = request.env[report.model].browse(ids)
if getattr(obj, 'message_post'):
obj.message_post(body='This report was committed!')
```
- Install Inventory
- Pick a delivery order and try to print it, there should be an error
(whatever exception you decided to raise in `_run_wkhtmltopdf()`)
- See that in the message board we got a message that the report has been committed,
which isn't the case, it failed to generate.
Reason for the problem:
Controllers are catching the exception when generating reports,
but never reset the state of the database.
Fix:
Raise an InternalServerError with an error code of 500 to trigger
a database rollback.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3001950
closesodoo/odoo#106172
X-original-commit: ec185fcf7f32da05c83733af36bebe10ac22e2ad
Related: odoo/enterprise#34193
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
In PR 102662, we added a protection to manage the call to RPC in the new
form views when the component is destroyed.
This fix did not exactly reproduce the behavior of V15 and the new
relational model. The expected behavior of an RPC call when the component
is destroyed is a promise never solved. This commit will therefore
reintroduce this behavior.
In web, it is impossible to test this behavior because no rpc is
triggered when the view is destroyed.
closesodoo/odoo#106171
X-original-commit: 207f26ace6732c33d7169102f2a5a9695f5dda99
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prevent the kanban view progress bar
from overlapping the courses count.
Task-3069581
closesodoo/odoo#106170
X-original-commit: 9eca4d4a6df7d14cbe6cc268a393caa663dcf68e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some cases require usage of Markup in order to correctly display HTML content
and avoid escaped or invalid statements.
Fix: in hr_recruitment, support default_job_id from context, easing display
of job's alias in empty list helper.
Task-3074357
closesodoo/odoo#106061
Related: odoo/enterprise#34139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the listArchParser did not offer ways to be extended.
Specifically, when extracting fields and widgets, there was no way to add information
from the outside.
After this commit, the functions that parse fields, widgets and button are methods
of the class hence offering extension points. Specifically, studio uses those to add information.
closesodoo/odoo#105970
X-original-commit: 4c1e0ba228f294c7bd5dd067431a1b660960d8b5
Related: odoo/enterprise#34074
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce the error:
- Install 'Maintenance'
- Select 'Maintenance' -> 'Request Maintenance'
- Create a maintenance request:
+ TH1: Save > Change stage to Repaired > 'Close date' =
Date.Today()
+ TH2: Don't Save > Change stage to Repaired > Save > 'Close
date' = blank
closesodoo/odoo#106166
Problem: App will show 'Close Date' blank
Expected: App will display 'Close Date' as Date.Today()
Solution: When Click on Save button -> Automatically get current date as end date
X-original-commit: a73b918f9f38f36b98e5dede4216a58bd56e31fa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Prior to this commit, the image placeholder lacked contrast and wasn't
readable in small size (eg. in the kanban view).
This commit improves this placeholder.
task-2760590
closesodoo/odoo#105296
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since odoo/odoo#99660
the `depends` field attribute is no longer passed
from the server to the web client.
Because of this, the "Set Defaults" feature
of the debug menu is completely unusable,
as the list of fields on which to set a default is empty because of it.
The use of this `depends` field attribute has been introduced in
revision odoo/odoo@ce9bbf6c10
In the commit description, we can read that setting a default
on computed fields having depends has been disabled
because the defaults set were being overwritten by the call to onchange.
Note that only the fact the field has depends is required,
the actual list of field names is not used, just the fact the list is
not empty.
However, since revision
odoo/odoo@488e334fc8,
available since Odoo 14.0,
this is no longer the case, the defaults are no longer being overwritten
by the call to `onchange`, since the `default_get` has been integrated
into the `onchange`.
A video attached to the pull request of this revision
shows the behavior difference.
Hence, setting a default on a computed fields having depends
(with an inverse method, hence not readonly)
can be allowed again in this "Set defaults" debug feature,
therefore avoiding to have to send back the `depends` field attributes
to the web client.
opw-3031290
opw-3038711
opw-3055292
X-original-commit: 48ac799288e76a0256b9ce0712a70ed5abc0f62e
Part-of: odoo/odoo#105251
Before this commit, the auto-invoice flow did not consider `sale order`
lines with negative quantities. It led to partially paid invoices.
Now, invoices generated by the auto-invoice flow are considered final.
This will allow `sale order` lines to be invoiced, even with negative
quantities.
task-2887019
closesodoo/odoo#104277
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prior to this commit, payment was requested on sale orders with a
negative balance. Customers could settle transactions with a negative
amount. No payment provider allows negative transactions which would
lead to crashes and errors during payment.
Now, payment is only requested if the total amount of the sale order is
strictly positive.
task-2887019
Part-of: odoo/odoo#104277
Before this commit, when the user is just a planning user without any
access to the Employees and Contracts apps. A traceback is occurred
saying the user cannot access to the `hr.contract` model.
This commit adds a `sudo` in `_get_valid_work_interval` method to get
the resource calendar of resources within a interval (the one of the
gantt view). This sudo does not give any recordset in sudo since the
`_get_calendars_validity_within_period` method return a dict with
resource_id as keys and the intervals valid according the resource
calendar for the interval.
closesodoo/odoo#106138
X-original-commit: 0bf271eb41cd1622d8ba4c1882a8ea94f1bdb463
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Move code to support only the redirect from url containing double '/' in
the middle of the path.
Keep same behavior than v15 and default Apache behavior.
domain.com//shop/product/1 -> 404
domain.com/shop//product/1 -> 301 -> /shop/product/1
opw-3063387
closesodoo/odoo#106137
X-original-commit: fdd6bf9942e2807b6d1460dba1ca5f61404c7b06
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
RPC call may fail because of error in `base.automation` handler. In this case
the response contains attribute `exception_class=base_automation` to handle
error via custom dialog `BaseAutomationErrorDialog`, which provides extra
buttons (disable/edit Automated Action).
1.
`BaseAutomationErrorDialog` was incorrectly inherited from ErrorDialog, which
cannot extract traceback from `data.debug` value of jsonrpc. Fix it by replacing
it RPCErrorDialog.
RPCErrorDialog: https://github.com/odoo/odoo/blob/a75fcbe03f31fd10a74e609672b64dad165e68d7/addons/web/static/src/core/errors/error_dialogs.js#L62-L70
2.
Button `Edit Action` didn't work, because it tries the same rpc call before
navigating to the action. For example, it would repeat rpc call to create a
record, which doesn't work because of broken automated action.
It happens because form changes are saved automatically since Odoo v15.
Fix it by adding `target: "new"`.
opw-2845893
closesodoo/odoo#106134
X-original-commit: f54eef302323f1f6406e9b2ac8e02cec5b627fac
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since the "always edit" task in form view, the underline (border-bottom)
only appears when input is `:focus` or `:hover`.
The problem occurs because the rule for `.o_field_invalid` doesn't match,
so the transparent color is applied and the red underline only appears
when we are hover or when the field has the focus.
This commit fixes the problem by setting the border transparent only
when the field is not invalid, not hover and not focus and not in a form
`.o_field_highlight`.
So now, we better see the invalid fields without hovering it.
Steps to reproduce:
* Open Project
* Select a project
* Select a task
* Create a new task
* Try to save manually the task => BUG a notification appears but the
"task title" (name field) is not underline
Task ID: 3069662
closesodoo/odoo#106123
X-original-commit: 1666ee5515996fab8a843b36b4fd93b776172f75
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
To Reproduce
============
- create a subscription
- confirm it and create invoice for it then confirm it too
- go back to the subscription and renew it
- from *Action* generate a payment link
- a validation error will be raised
Problem
=======
we can't generate the payment link because the amount is 0, this value came from the fact that we substract
the sum of invoices amount linked to this subscription from the total amount.
Solution
========
The invoices from the old subscription are kept just as history in the new one, and must not be taken into account when
computing the amount, so a condition was added to remove theses kind of invoices from computation of amount.
opw-3052816
closesodoo/odoo#106104
X-original-commit: 62e6db19d6ec17805756f277ca6f17c50281f707
Signed-off-by: abla001 <abla@odoo.com>
The purpose of this improvement is to easily identify the module of a
test and to be able to run only the tests of a module.
closesodoo/odoo#105530
Task-id: 3062058
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As `_get_view` is cached,
and `_get_view` has been overrided to change the label of the fields
`company_rate` and `inverse_company_rate` according to the company
currency, the company currency must be added in the `_get_view` cache
key, so it returns the view with the correct labels
when you use two companies with distinct currencies,
and not the label using the currency of the other company.
closesodoo/odoo#105301
X-original-commit: b106361d60413940622b477f73cfdf1536f2ef38
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, creating a new leave as an officer
from the approval tab would have by default no time off type,
resulting in "Employee on False" in the display_name.
After this commit, the display_name will set "on Time Off"
instead of "on False" when there is no Time Off Type set.
task-3054318
closesodoo/odoo#104963
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps:
- Go to studio
- Open report editor in any report
- Use Text block
- Insert /checklist
Normal bullets without boxes are used in the report, because the checklist are styled separately in web_editor/static/lib/odoo-editor/src/checklist.css
opw-2995045
closesodoo/odoo#102072
X-original-commit: 9b4a1d3a45d294797813d653090b3a3c541210f5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
Fields `product_qty_available` and `product_virtual_available` on
stock_move are related on quantities fields of move's product_id. On
large database, those two fields will slow down every transactions that
updates stock move state (confirmation, validation, ...).
`state` on stock.move is a dependent field of computed field `qty_available` on
product.product which is dependent field of related field
`product_virtual_available` on stock move. This relation tree implies
that updating the state on one particular stock move will mark its
product (qty_available) as 'to be recomputed' and thus **every** stock
moves (product_virtual_available) of this product as to be recomputed.
On database will 100k+ stock move per product. Fetching all stock move
of some products take 90% of a manufacturing order validation time. This
is problematic knowing those two quantity fields are only used in the
stock move tree form so computed anyway at the view rendering.
This commit change the `depends` of those two related field to mark them
as to be recomputed only if the product_id change.
closesodoo/odoo#106070
Opw: 3047017
X-original-commit: 189e825e567e4c633d721ce9f0fee906535edf06
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The preview of a mailing was displayed twice:
- after a save and when clicking on the preview button
- when double-clicking on the preview button
This solves those problems.
Technical notes: quick explanation of the fixes:
- double display after a save: the click event was registered twice (same for
the code preview button), the fix unregister the click before registering it
again.
- double display when double-clicking quickly on the button: the modal is not
displayed immediately and the button remains active a brief moment allowing a
second click. The fix disables the button when the button is clicked and
reenables it when the modal is closed.
Task-3047479
closesodoo/odoo#105974
X-original-commit: 0403938c3e0103d97ae828afdae06fcda06bd406
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Joseph Caburnay