sms_composer could crash in case you didn't pass it the active_id,
active_ids context keys or don't call the default_get
In that case it would try to access `self.env[False]` which would crash
in the `_compute_recipients_count`
We also have to ensure that we have a default value for `self.res_ids`
because `literal_eval(False)` will crash
closesodoo/odoo#38545
X-original-commit: 7ed0bd258d8a744716101d89cfa0bdf0f7990fb5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Initially a forward-port of 5aecd365d7b, which needed f407e60ad680371 to work.
The do_in_onchange was removed inbetween, but it is not needed anymore here.
The issue was caused by the fact that the cache values given for each
environment, whereas in the new ORM the values are now shared across all.
The other potential issue caught by this test was that the company of the taxes
could be incorrect. This is problematic for the end user, since relational that
violates inter-company rules mean that they won't be able to read or write
the records without sudo. However the model now has _check_company_auto,
handled by the ORM, so the issue should not arise anymore.
closesodoo/odoo#38543
X-original-commit: 30cf4b37327ac86584c3025d8fa11b4094f9cbda
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Because of 4b1cb41cf7, we might try to read
the field 'active' on a record on which we can't read fields besides the name.
This thus triggers an access error where there should not have been.
In particular, this is the case for portal users: most often the records they
can access point to records that they can't read
(e.g. the partner of the internal user assigned to the ticket).
As a result, clicking on any link creates an ACL, and thus redirects to the
home page.
It turns out that filtered_domain was primarily used on already loaded records,
typically for the write, so it was assumed that the records could be read
in the first place.
However in the use-case of the portal, there is an explicit check on the read
rights with the portal user, explaining the discrepancy.
Since in the general case filtered_domain should be able to read all fields
to evaluate the domain, we put it in sudo.
fix co-authored with @rco
closesodoo/odoo#38540
X-original-commit: cff5cc8cc78a32eb204368e84ec4980324046405
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The RUT is the Registro Único Tributario;
the NIT is the Número de Identificación Tributaria.
The number that is used is thus the NIT.
opw 2082599
closesodoo/odoo#38533
X-original-commit: 1db209acaf44731f1740f038d9fadf464677baf4
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Install l10n_co,contacts. Open contacts.
Several crash messages will popup because the override in l10n_co of
res_partner is not computing the 'l10n_co_verification_code' field for
every record. Changing the implementation to be sure to store some value
for every record fix the issue.
opw-2082583
closesodoo/odoo#38473
X-original-commit: 2489c40507abba5df833b0db7b5a02749b2f749a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when we have a list (editable top) in a form
with some mandatory fields and some existing rows. If we click on
'add a line', a new empty line appear on the top, then we click on
the last row, the empty row will disappear and we will have a
traceback.
After this commit, if we repeat this scenario, we click on the last
row, we will be able to edit this last row.
closesodoo/odoo#38471
X-original-commit: 996f77b03eaf6dd646b1816e7f70209d5ee6f8df
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>
Reconcile the stock output lines of the pos.order invoice
for products with real-time valuation. This is to be more
consistent with the sales module.
closesodoo/odoo#38437
Task-id: 2048668
X-original-commit: 1eaea47c647cc3c3ed2d2b732992f64a411e2bd7
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Example of workflow to reproduce the issue:
- Add a selection field 'Test' to `project.task` with Studio
- Go to Projects > Planning > By Project
- Switch to list view
- Add the newly created field to the view 'Task > Test'
The interface loops indefinitely because the server is stuck in an
infinite loop.
The loop is the following:
https://github.com/odoo/odoo/blob/89270ee39c0daa46ae8e2e3e57d7e512a1a65ddf/odoo/models.py#L5624-L5625
The root cause of the issue comes from an incorrect object ID added in
the list of fields to recompute. Since the method is set in a
`post_init`, the object `field` is different from `recs[field_name]`.
To prevent the error, we retrieve the object directly in the
`mark_fields_to_compute` method.
opw-2083852
closesodoo/odoo#38550
X-original-commit: 446cd3f3d610c9a872969f5d6843ccb6ebdb0d40
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Denis Ledoux <dle@odoo.com>
Fields created with Studio are case-sensitive, so we need to properly
quote the query.
opw-2083852
closesodoo/odoo#38544
X-original-commit: 2c50b663c7656b49e06804f30c5dc6d0dcff1af4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install timesheets and studio.
- In timesheets add a time of -0.5 (minus half an hour).
- Enter studio
- Switch to the Reports tab, and click Timesheet Entries.
Before this commit:
The time is displayed as 00:30.
After this commit:
The time is displayed as -00:30.
closesodoo/odoo#38542
Opw: 2036188
X-original-commit: b12374a266d4b5f2783d84e3a65b1c273e343a81
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Computed fields that depend on the context now have to be declared as such.
To reproduce the issue:
- go on the form view of any view
- update the arch of the view
- save
- click on action "reset view architecture"
- select hard reset
- no diff is shown
Expected: a diff should be shown
`arch_base` depends on `arch`, so even though no current flow actually uses it
when the context is changed, update its `depends_context` as well to be safe.
closes odoo/odoo#38536
Pr: #37363
X-original-commit: be658bb87a9e9dd84909e6e6d2cb9107b87a0d52
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This is necessary when writing view fields from a page record because the
generic page will put the given values on its cache but in reality the values
were only meant to go on the specific page. Invalidate all fields and not only
those in vals because other fields could have been changed implicitly too.
Pr: #37363
X-original-commit: 83f9a3e2608db34a319b985271d73f7de5bc73a1
-Import a subscription with end date beyond 200 in the future (ex: 2500-01-01).
-Open the subscription and click the Edit button.
Before this commit:
A stacktrace appears indicating that a date is not valid. It's not possible to
edit the subscription.
After this commit:
The maxDate of the date picker has been increased to 31/12/9999, allowing the
user to edit subscriptions whose end date is that far in the future.
A test `toggle datepicker far in the future` for this case has been created.
closesodoo/odoo#38527
Opw: 2079696
X-original-commit: 32b6131c04fef7a542a0ccbdb924d177627bfe38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We didn't check the status of the response of the server when getting
the url of the display. If the status was different from 200, we tried
to use the error response as URL.
closesodoo/odoo#38554
X-original-commit: 8854f910f5ac7ab5d2dfd0f51f3249a068d40885
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
As the responsible can be assigned directly in the list view, the assign
responsible wizard is now useless. The Country will not forget what you
did for us wizard, thank you.
closesodoo/odoo#38365
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
...Only on mobile device.
closesodoo/odoo#38469
X-original-commit: 484e7bdc5ac11f33f9aa8a0f697a5f23d8f20c4a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, on mobile, when you make a delivery for a tracked
product you can't find already existing production lot for this product.
The issue was the `company_id` wasn't passed in the context and we use a
domain related on this field.
How to reproduce the issue:
- Create a product tracked by lot number;
- Add some quantities for this product by creating a production lot;
- From a delivery order, try to specify the LN which are part of the
picking, none are visible (records not found).
X-original-commit: dd49f405690a423ae5959e721cbf41492df2d507
Before this commit, if you archive a blog, you will have a 500 instead of 404.
Serve page to show the 404 use request.website, so we need to force controller
with website=True to bind website on the request.
Probably need to check all controllers in website_* module.
opw-2066725
closesodoo/odoo#38539
X-original-commit: 74341c4fcba701fe5ce7ee742880bbf138131a0d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The field `number_entries` should have a `_compute_number_entries`
method defined on the model
Since the field does not seem to make a lot of sense in here so remove the
field
closesodoo/odoo#38487
X-original-commit: b15fbab8a85aca9ff0895d41d50af569db27fd3c
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Packaging oversight, the displayed version in the installer window was still
12.0.
closesodoo/odoo#38486
X-original-commit: c5bd1a4f9730064f53ff633592dbf83ca7c1e4f7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When pos_hr was installed, `load_models` was called twice for res.users
and calls to `load_fields` were not processed correctly.
closesodoo/odoo#38462
X-original-commit: 26274dbb9720743461be2a70de02bf4c1ea377f4
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
A scrollbar appeared every time a receipt was printed. To fix this,
we put a height of 0 to the div that contains the receipt.
html2canvas then had trouble computing the height of the background.
There's a `height` option that can be given to the library but if the
logo on the receipt was not loaded yet, the size we computed was wrong.
We then compute the height only once the images have been loaded, in
the `onparsed` method.
We also remove a CSS class that wasn't used anymore.
X-original-commit: 84418ae5bc1509c2c45323ecf6aed4ce4811f4d5
Before this rev., if the week_start param (the first day of week)
of the user language was changed, it wasn't reflected on datepickers
(however, it worked fine in the calendar view). This rev. makes this
work by updating the moment locale with the corresponding param.
Fixes#36450Closes#36532closesodoo/odoo#38472
X-original-commit: eeb518316f25d652bea3ec6d387db6ad93284fb2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Steps to reproduce**
* Define "Purchase Order" sequence for using date ranges checking "Use subsequences per date_range".
* Change sequence prefix to "PO/%(year)s/".
* Create a purchase order with order date in 2020 (a different year than current one).
**Current behavior**
Got a purchase order with 2019 (current year) number.
**Expected behavior**
Got a purchase order with 2020 number.
closesodoo/odoo#38468
X-original-commit: ce423e6adb6659a1d5885bad158c59b882cb4565
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
**Steps to reproduce**
* Define "Sales Order" sequence for using date ranges checking "Use subsequences per date_range".
* Change sequence prefix to "SO/%(year)s/".
* Create a sales order with order date in 2020 (a different year than current one).
**Current behavior**
Got a sales order with 2019 (current year) number.
**Expected behavior**
Got a sales order with 2020 number.
X-original-commit: 20baf00d07868a83cd73a13a6141bc0d36c85c44
Install the website, install a second language.
Switch the language on the website: error 500.
The function opened a new cursor, to update website_visitor.
It did so at the end of the query dispatch.
However when switching the language of the website, the lang is written on the
website visitor. This is done at the flush, done at the end (exit) of the query.
This is done on the cursor that was used for all the transaction.
Therefore that write would systemically fail on a
ERROR: could not serialize access due to concurrent update
opw 2080986
closesodoo/odoo#38453
X-original-commit: cc88a36744dc3c2949c47e8b163e1de98f5dbd95
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
[MERGE][FIX] product: make copy of variants just copy template
Variants are generated depending on the configuration of attributes
and values on the template, so copying them does not make sense.
For convenience the template is copied instead and its first variant is
returned.
closes#38151closesodoo/odoo#38452
Forward-port-of: odoo/odoo#38303
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Variants are generated depending on the configuration of attributes
and values on the template, so copying them does not make sense.
For convenience the template is copied instead and its first variant is
returned.
closes#38151
X-original-commit: 259f3b7fcdb88d1f458ee7ea3667964412b88ea1
In the backend, when a mailing popup was being edited, it was not
centered in the edition area (and went under the editor UI) and was not
using the correct style.
task-2083465
closesodoo/odoo#38449
X-original-commit: 6ccf3b618b4b0774deccb4f75bf33f3ea4dc8b75
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If there is no product in the recently viewed product snippet, it will
simply not be shown. It appears only if there are products (with some
flickering we may decide to improve in future versions).
Also fix the behavior when the last product of the snippet is moved to
the cart.
task-2076271
closesodoo/odoo#38438
X-original-commit: 02037bc20c6d3f5f2bad70a1a30b424ec432eb6b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
When recruitment is duplicated, `emp_id` should not be copied for obvious reason.
closesodoo/odoo#38442
X-original-commit: 68820340ce4adc5a31df23f0b5ff2c715a695fdc
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
It is possible to select "System (English)" as chosen language,
or False in v12 or earlier versions.
However, if the language has not been activated,
then record_lang is an empty recordset, so record_lang.date_format is False,
(respectively time_format), and so the formatting crashes.
Note that if this happens, the calendar notification mechanism generates a crash
at each page load.
Instead we use get_lang which defaults to the most appropriate activated
language: the one given in argument if it exists, or the company one.
co-authored with @mart-e
closesodoo/odoo#38445
X-original-commit: 738214f00dff33389e7211ee73eae76b196b7844
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Since 5cf9d55bbc, attachments are always records.
Before, they could also be named tuples, so helpers were needed.
Since they are now useless, we can remove them to clean up things.
closesodoo/odoo#38414
X-original-commit: 63a937a954c310af88cec214d683f61c64263407
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In fact, "not filename.endswith('.pdf')" does not
"Check if the attachment is a pdf".
Some pdf files have filenames with a pdf extension, but .PDF, .Pdf
work generally just as well, and it's also possible to live without a file
extension.
In any case, it doesn't prevent from crashes because of corrupted files,
or files that are not pdf files but have the extension.
opw 2075933
X-original-commit: 3f63447d8f25f6ff8a4d9951a74db069d41332f3
If a field does not exist, writing it creates a warning in the logs.
This would for example prevent a valid test to pass.
This is needed because extract_state is a field from account_invoice_extract,
which is not a dependency of account_facturx.
X-original-commit: bb03b05df39097a954388ba6b00c025989351f16
Since https://github.com/odoo/odoo/pull/34297, sudo() allows to keep
current user information when creating/modifying records.
There is no need anymore to use with_user(SUPERUSER_ID) to have sudo rights.
This commit ensures the user information is kept when creating pos sessions,
instead of having OdooBot as create_user.
closesodoo/odoo#38441
X-original-commit: aff1dc1ea68c345fb2632f9666dc298f685b8748
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
RomainLibert