Since the ir.sequence records linked to pos.config records are on
delete restrict, it is necessary to delete the pos.config records first
before deleting the ir.sequence's linked to them.
closesodoo/odoo#38775
X-original-commit: cdfa415829fa06f2860d65054fd8534180c8526a
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When selecting the "Continue shopping" option after adding a
configurable product from the products page with "Add to Cart" enabled
the top navbar was not updated.
Part of https://github.com/odoo/odoo/pull/37132
task-2070507
closesodoo/odoo#38732
X-original-commit: 433be848d4e2545a9962a54d2dba615b329f73de
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The animation was not waiting for the target to be displayed.
Part of https://github.com/odoo/odoo/pull/37132
task-2070507
X-original-commit: fb00568464e8d2a39975c373016616a2970aa501
From Accounting Dashboard, under the kanban card "Customer Invoices"
click on "Upload Invoice" and submit an e-fff invoice (xml) which is
actually an invoice (e-fff type 380, should be uploaded under
"Vendor Bills" card). The server will reply "Cannot create an invoice of
type in_invoice with a journal having purchase as type." because it will
fetch the type not from the destination journal but from the guessed
journal.
opw-2083545
closesodoo/odoo#38762
X-original-commit: a12e29c963201add0ea6b15a1e8e19a6af1db032
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Follow up of commit a3845ae3f0
Issue
=====
Since the above commit there is a confirmation dialog when clicking on a button,
for which the only options are to Discard or Cancel.
The problem is that when discarding it will revert the selected website back to
the default value. Therefore before the current commit it is impossible to
install a theme on a website other than the first.
Solution
========
The solution is to avoid showing this dialog when clicking on buttons for which
the result depends on the currently selected website. This leads to the same
behavior as what existed before the mentioned commit: the settings are
implicitly discarded because they are not saved, but at the time of the click
the transient model still holds the non-discarded value that the user selected.
This restores the "select a theme" feature, but also restores the unfortunate
side effect that the user might unknowingly loose all of his pending changes
when clicking on the button, but only for those two specific buttons.
Other considerations
====================
Saving instead of Discarding was considered but it is impossible to do because
saving might do a lot of changes that might even lead to the installation of
modules, so the settings page has to be reloaded to apply them, and then the
website field will be reset to its default value again.
Instead of changing website specific settings from the main settings, it was
considered to update them through a form view, but it is apparently too
complicated for on-boarding.
The last consideration was that the settings view should actually mark the
corresponding fields as unchanged when changing the website, but it is too
complex to implement for a case that is not supported in the first place,
especially for a fix in a stable version.
task-2083198
closesodoo/odoo#38745
X-original-commit: 2298ef19bcd9e7a14958dce9a93cea69258064d8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Go on the portal with a portal user
Drop a message in the chatter
The message is logged in the chatter from the right partner
Before this commit however, the email that was sent had
its address from of the OdooBot
After this commit, the mail is sent with the partner's email from
OPW 2074154
closesodoo/odoo#38553
X-original-commit: 2ce5d3840c7c43a2226b007a180cb91c5031312c
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When you are adding a line on your sale order that is a delivery line,
the carrier is not always set on the sale order which means that when
the carrier is not explicitly set on the sale order, the carrier won't
be set on picking created from the sale order.
When you are using the wizard on sale order, it works, but when the
carrier is selected on the e-commerce, it is not set on the sale order.
To avoid such difference in behavior, we are writing the carrier_id of
sale order in the function 'set_delivery_line' insread of the wizard and
e-commerce.
closesodoo/odoo#35855closesodoo/odoo#38740
Original-signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
X-original-commit: a15f9921fa1ce92c41c263a8a2c6a32342a8cb1b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- If the Timesheet entries all belong to the same project, the report
title should be
"Timesheet Entries for the name of the project Project" and here in
this case no need to show the project column.
- Split the Project - Task column into two separate ones: one for the
Project and one for the Task
task-2027729
closesodoo/odoo#38684
X-original-commit: 96d3bd7560f43847c758d149eaab14ecc9206058
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
It seems the grouping feature was lost during the accountpocalypse.
Add a test as long as I'm at it.
closesodoo/odoo#38500closesodoo/odoo#38552
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
If two snippet options are declared using the same data-js="..." and
that they end up targeting the same snippet in some cases, only one of
those two snippet options was shown.
This case occurred in a theme (avantgarde) for the map snippet.
closesodoo/odoo#38551
X-original-commit: 2072bfd9981eebc8c8d8d03d2f44f0e4a2489692
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Revision on https://github.com/odoo/odoo/commit/9a66619db33fca5f0cb81d9f6bfeb0fb0290cf68
Commit above improves the web client startup by not having to wait
for discuss widgets to fully load beforehand.
However, it introduced an issue with chatter when the 1st rendering
happens before messaging becomes ready: it displays
"Creating a record..." instead of the whole history of messages.
This happens because when messaging is ready, it updates data from
the chatter but it does not trigger a re-render.
This commit fixes the issue by triggering a re-render on messaging
ready. When messaging is not ready, thread field now displays
"Loading..." instead of the message "Creating a record...".
Task-Id 2078193
closesodoo/odoo#38751
X-original-commit: 93bdd7c91095025f4d6e7a058e0ab1c4e1a0ad60
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the editable quant list was editable by top, which
is not really pratical when the user creates (with the keyboard)
multiple quants tracked by SN because the focus always go back on the
top of the list. Now, this list is editable by bottom.
closesodoo/odoo#38743
X-original-commit: c7b069a16ae03066ed531a6b1da671ab994d0994
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The product copy was fixed in https://github.com/odoo/odoo/pull/38303
but the result is still not intuitive.
You could duplicate one of the multiple variants of a template and see
another variant form opened than the one you just duplicated.
closesodoo/odoo#38739
X-original-commit: b64e2f93465f16112d719ed0a28c82051066dbf3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when clicking on "Unstar All" from Discuss
'Starred' mailbox, it crashes with following error:
```
TypeError: unstar_all() takes 1 positional argument but 2 were given
```
This commit fixes this issue
closes#37994closesodoo/odoo#38738
X-original-commit: ec330d1668640d3ae75e23a70695006a63dbe217
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Revision on https://github.com/odoo/odoo/commit/e7aff236b8073b952a0e554d9897a8f88d5c4c91
Commit above remove cross icon on attachments from messages that are
not in the chatter, since this only makes sense in the chatter.
However, it also removed by mistake the possibility to delete
attachments from the attachment box in the chatter.
This happens because the template of attachments uses a newly
introduced contextual boolean `isDeletable`, and this is false by
default due to undefined being falsy.
This commit fixes the issue by explicitly enabling deletion of
attachments from the attachment box.
Task-Id 2081987
closes#38003
X-original-commit: 1a175686d493d9f289cf391b65a56adc80da82c2
When you try to create two users with the same login, the shown error message is
the Postgresql integrity error instead of a nice (translated) validation error.
This happens since bf88f3e which changed the way error messages are translated.
The reason is the manually created unique index `res_users_login_key_unique_website_index`.
The error handling and translation mechanisms don't know it exists.
The index was created for performance reasons in commit b5a12b4 where the
original python constraint was replaced with this custom SQL index.
In this commit, the python constraint is re-introduced to remove the index hack,
but the implementation now uses a single SQL query, which should be quite fast.
closesodoo/odoo#38737
X-original-commit: 817a811ec98b0c313b12e6464b5e98ca432cb3fc
Signed-off-by: Christophe Simonis <chs@odoo.com>
Go to hr.applicant view form, Edit and change something.
Each time you change a field, the Attachment box in the chatter is toggled
(as if you were clicking on the small attachment button each time).
This a wrong behavior of the `open_attachments` option of the `mail_thread`
widget.
Opening the attachment box should be done at the widget initialisation,
not at every render.
closesodoo/odoo#38720
X-original-commit: 400a1f7bc3d00f5bc95bdbfe1dfadf9d251d808b
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
When you try to delete a floor, an error is raised if a pos config has
an opened session. Even if the floor is not used in the opened pos
config.
The real goal of this constraint is to avoid deleting a floor plan
linked to a pos config having an opened session.
Github issue: https://github.com/odoo/odoo/issues/38581closesodoo/odoo#38719
X-original-commit: 9ec5a4c0126db767e17fc352fa184e0ee2bcc7e7
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
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
Joseph Caburnay