Creating a location without name does not make sense, it is the only
field of the model
Fixesodoo/odoo#38571
Adapt in master to make the field required at the model
closesodoo/odoo#38718
X-original-commit: 0823062efa96c316b9bca743891c8a1c701d130d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, some images would display incorrectly orientated.
This typically happens for images taken from a non-standard orientation
by some phones or other devices that are able to report orientation.
The specified transposition is applied to the image before all other
operations, because all of them expect the image to be in its final
orientation, which is the case only when the first row of pixels is the top
of the image and the first column of pixels is the left of the image.
Moreover the EXIF tags will not be kept when the image is later saved, so
the transposition has to be done to ensure the final image is correctly
orientated.
closesodoo/odoo#38717
X-original-commit: 0f8e132ec0495fcdfa0a47d5b9c98a2f6f10c7d8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Create a sales order for a company with a contact name.
- Click the Preview button.
- The company and contact names appear on the same line, only separated by a
comma.
Before this commit:
it's not possible to easily override this behavior.
After this commit:
it's possible to override `Partner._get_contact_name` to change the format of
contact name.
Beware that this method is used in `_get_name` which is called from various
places. A check on the context may be necessary.
closesodoo/odoo#38712
Opw: 2077294
X-original-commit: 0b8f3f93a2cb05cc9c940964fe80acd23b86b8a0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, in base we use bus to notify the user but bus module
is not always installed and so we can't call it.
After this commit, now we use a client action to notify the success test.
Steps to reproduce:
* install a Odoo with no apps
* go in debug mode
* go to "Outgoing Mail Servers" technical settings
* create a valid SMTP record
* click on "Test Connection" button (BUG)
closesodoo/odoo#38709
X-original-commit: ea4113745024a72bd170d9ceef38e97acd420d4e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, it was not possible to show a message using a client
action. (e.g. show a success message only with core in Python)
Now, it's possible using a client action. This client action call
displayNotification and so we can use the same options also.
A test is added to be sure that this action do not change the current action
Note: in the future a custom registry may be created in a refactoring
to specific function action registry.
X-original-commit: 8775fd670b6b3ec19a77fc0eab72d2223baa36c8
Before this commit, if we use some client action like: reload, logout, ...
in the console a warning is show, because the action are function and not
AbstractAction.
After this commit, if the client action is not an function and not
a AbstractAction the warning is show.
X-original-commit: 122b76594aeb2c5d923d13c040c2da2048133aac
Purpose of this commit is to reorganize mail.message file in order to
better understand its content. It is done according to guidelines
* computed fields;
* CRUD and search / check access overrides;
* actions (discuss, moderation, fetch / failure);
* tools;
Even if this commit generates a big diff, there only some main blocks code
move. Nothing is changed and functionally as well as technically nothing
changes.
closesodoo/odoo#38695
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
-Define "g" as the default UoM for a product.
-Make a purchase order with that product.
-Select the "kg" UoM in the order line and a price of 50.
-Check the Purchase tab of the product.
Before this commit:
the UoM of the price created is the default UoM for the product, "g".
This is because it's a related field.
However, the price wasn't converted to the default UoM, it's still 50.
After this commit:
the price is converted to the default UoM, it's 0.05 per "g".
closesodoo/odoo#38688
Opw: 2076722
X-original-commit: 341b568773b28b2bbce02f3532215e9664b318ec
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fixes#38574
Assigning default value for non-stored compute fields is required in
13.0
closesodoo/odoo#38685
X-original-commit: 7fa80370f8e6fe814651627832d81abe9edebad3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
OPW 2082843
The communication on the register payment took the vendor reference or
the invoice name by default. Now, it first looks at the payment reference
value.
closesodoo/odoo#38683
X-original-commit: 6e1a821818e478c49407474446b2e0a521889194
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When an option group is opened, all the other opened option groups were
closed. The problem is that an option group may contain other option
groups, so when trying to open a sub-group the main parent group was
closed first.
Note: this case only occurs for one option in themes for now.
Part of https://github.com/odoo/odoo/pull/38495
task-2083198
X-original-commit: 102151da12c28746bf16dd7f009c1ca3933d06ba
* website_form
To support old theme options, a hack had to be made to allow access to
left panel UI. This will be improved in master.
Part of https://github.com/odoo/odoo/pull/38495
task-2083198
X-original-commit: 5ac6a7a5dbd2af1190d0d027d0239dd1cfc257b0
Only invoices/bills should create their equivalent credit notes when reversed (with tax tags coming from the related repartition lines), other kinds of journal entries should be reversed as misc entries, to negate them entirely in the accounting
closesodoo/odoo#38547
X-original-commit: cdb3ccf811d69dbd18f196614f380349a1335c9f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
We should always ensure to assign something in a compute method
Since sms_template_id is not required, we have to check that it is set
before trying to render the template
Also make sure to have a default value in case you don't have a res_id
closesodoo/odoo#38546
X-original-commit: b96bb2a00737339dc53ff06167c1a0cd424ad717
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Yenthe666