It is possible to get to a situation where Odoo would try to send an email without a `From:` header address.
In such case, you're unlucky if you don't have access to the underlying deployment, or if you use multiple databases in a single Odoo instance and each of them uses a different mail configuration.
To make this configuration easier to use and cover those use cases, here I add support for a new ICP: `mail.default.from`. It will be used when present, so it shouldn't affect existing deployments. When present, it will allow a admin to configure the default sending address just with Odoo itself.
closesodoo/odoo#38874
X-original-commit: 5010ce630a7f0e01d45d99c9083318b50f9f624a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
After the refactor of mail sending with the newest python API
(18299d7e50),
the order of multipart/alternative was wrong for email.
Indeed, in the MIME protocol [1], for The Multipart/alternative subtype
the order is significant: "In general, user agents that compose
multipart/alternative entities should place the body parts in increasing
order of preference, that is, with the preferred format last".
This bug caused some issues with mail marketing (see related task)
with Gmail web client (see the plaintext instead of html mail).
The fix is to inverse the order of adding alternative in the mail
content.
[1] https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
TASK_ID : 2084989
closesodoo/odoo#38490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* use an editable tree to edit the supplier info
* keep the original forms because they're used in the "vendor pricelist"
menuitem
* updated tour
* change the position of requisition_id
Task-2029380
closesodoo/odoo#35972
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In 12.0 it was 3.5 but for 13.0, it is acceptable 3.6.
Debian Buster has 3.7 and Ubuntu 18.04 LTS has 3.6
This will avoid undeterminist errors with OrderedDict
CentOS 7 still does not ship python3 by default but it is possible to
install it and CentOS 8 with python 3.6 was released in septembre 2019
closesodoo/odoo#38827
X-original-commit: 14e3e7524c2edd08ddf19afe512cb4462d070c0b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Let a model M define a Many2oneReference field F1.
- Let a model N define a One2many field F2 whose inverse is M->F1
- Define a computed field N->F3 that depends on N->F2
If, for whatever reason, a recordset of M contains records that have
been unlinked already and we try to unlink them again, the system will
crash with a MissingException error.
This happened because, while most _modified_trigger cases cover the case
of a MissingException (i.e. record not in cache), the case for a
Many2oneReference didn't.
This is fixed by simply ignoring these "stale" records in the
_modified_triggers section for Many2oneReference fields.
closesodoo/odoo#38816
X-original-commit: f3b05032f0576befda4dca870718afd429c21b0f
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: mreficent <miquel.raich@eficent.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>
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>
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>
Steps to reproduce:
- Export a partner with country set to False, using EXCELL
- Try to import it with the xls file
Bug:
It raised: "No matching record found for name 'False' in field 'Country' at row 2"
opw:2080376
closesodoo/odoo#38379
X-original-commit: 01caf1e44f653a8e9bf5edd583bc2421905d9464
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- fix condition to correctly display company logo placeholder
- use avatar_grey on the "Contacts & Addresses" as white on white is not visible
- use `cover` to avoid excessive zoom on mobile
closes#38001closesodoo/odoo#38319
X-original-commit: 1210cb70bec421936c9d332b1347797bc83845cf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Commit 5a9e1af64a has the unfortunate side-effect of crashing early
if for any reason the content cannot be decoded.
However, simply ignoring that the content cannot be decoded is no better idea:
some functions pipe the result to decoding functions that crash the same.
The resulting traceback pollutes the log with uninformative message such as:
binascii.Error: Incorrect padding 5 0.002 0.016
In case the content cannot be decoded (data corruption, or simply missing file)
we return a clean 404 instead, which is morally almost equivalent,
and is clean even from functions that depend on binary_content.
opw 2072586
closesodoo/odoo#38318
X-original-commit: a68f7e6e72dbfd44e14c2f293fa6dc6aa402308a
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Starting with Python 3, queries sent by psyocopg2 are stored as `bytes()` objects.
Logging those raw makes them appear unformatted, harder to read than in v10 or lower Odoo versions (i.e. `\n` instead of a raw newline character).
Decoding the query into unicode makes it easier to read in the logs.
closesodoo/odoo#38074
X-original-commit: 329accde2ed6d4dbfdde6d3d99d71e21d15396b7
Signed-off-by: Christophe Simonis <chs@odoo.com>
One2many fields can use it actually
closesodoo/odoo#38193
X-original-commit: 765566032e60252ec8fb7800200ed05addbfce65
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Fine-tuning of a8dbbc029d1e86c84, similar to d76cd50f0e
Avoid error of 'user_type_readonly' referenced before assignment.
This can happen during database migration or if the module category is deleted.
closesodoo/odoo#38190
X-original-commit: cf1e5198e32e9239a6d3cbbfdc325dbd3e0952de
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Remove individual m2m indexes and replace with a single mirrored
composite
This will help for logical replication strategies (postgresql BDR)
closesodoo/odoo#37963
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The write override recomputed the mimetype when changing the datas
It may give a different result
closesodoo/odoo#24397
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since the field was defined twice the view was not working properly.
Closes#37999closesodoo/odoo#38108
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Previously, the argument
--logfile=~/logs/odoo.log
Would create the <cwd>/~/log/ directories with the odoo.log file in it,
which is typically not the behaviour one would expect.
closesodoo/odoo#37194
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Usecase to reproduce:
- User1 in company A and company B (default company A)
- User2 in company A and company B (default company A)
As user1 select company B in company switcher.
-> You never see user2 as he's hidden by a record rule.
This issue was present in older version when disabling the “Common Contact Book” feature,
because it was then enabling the faulty record rule. Since [1], this faulty record rule is
always enabled.
(Note that res.partner record rules are applied to res.user through _inherits)
We chose to remove the faulty record rules so that the present usecase is now working,
but the drawback is that you now see partners from other companies.
Also remove [2] that try to fix the issue and become useless if the
rule is removed.
[1] commit 25714692b2
[2] commit d6c65aa4d4closesodoo/odoo#37712
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently when creating an attachment in backend, history section holds
a "Creation: on" void line that is populated after create with "creation:
administator on 2019..." . This is quite ugly and not usability oriented.
Let us hide the history line while create information are not set, aka
before first save of record.
closesodoo/odoo#37940
X-original-commit: 9ef4cb3ada349b34ba8a5daa5ca9f9765bc43437
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Change decimal point, thousand separator and date format for Mongolian
language
closesodoo/odoo#37934
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
`method` has no effect, so currently XML-RPC can be called via other
methods, e.g. GET, which is against XML-RPC specification.
closesodoo/odoo#37917
X-original-commit: c2fe13d31f6b55900ad139d4e75b8c1a0c4ac165
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It is possible 29723e351d5 through the interface, in debug mode,
to create a portal or a public user.
Because of 29723e351d5, doing so raise: the user that it tries to create also
has internal user rights, which is forbidden for obvious security reasons.
The goal of 29723e351d5 was to restore normal behaviour when changing rights of
a non-internal user, i.e. to respect the groups given in arguments and their
implications. Most user creations happen programmatically, e.g. when a user
signs up on the website, so without that commit it was not possible to set up
the groups correctly in case of modifications, etc, since both create and write
did not use the provided group arguments.
However when passing through the interface, for portal or public users all the
other groups are hidden, but their values are not removed. Since these groups
confer user privileges, they imply internal user rights, which is forbidden for
a portal user, and raises.
Note that before a user created this way could not have the exact same rights
a portal user should have had, since technical groups should have been added
through the implied ids.
For this reason as well the fact that groups can be badly manipulated manually,
it is discouraged to use debug mode to to these actions, but still possible.
Since both flows simply use create, we fix the data that is sent by
the interface.
We cannot use an onchange to clean the groups since we are in the reified view.
So to avoid the JS sending the commands, we need to put the fields in readonly
if they are invisible.
To do so we also need to process the "user type" groups first.
Note that the sorting is stable, so the order is identical as before.
closesodoo/odoo#37839
X-original-commit: 3c44a5afe83465a76d16356e0fd6336b4d9c9196
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Adding `tabindex="-1"` is the only way a button could be set to not
have a hotkey when user presses <kbd>Alt</kbd>
closesodoo/odoo#37835
X-original-commit: 9e5b8db72e789064f99f58c4f64867307846acc9
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Before this commit, the assets were not found when the user is connected
in mode debug assets in a multi-website and multi-company. This occurs
because the attachments (assets) were created with the number of the
first website accessed, and cannot be loaded when trying to access the
second website.
The website_id is added in the creation of the views see:
092870270e
Now, the attachments are created without the website number and is
shared between all the websites.
opw-2076768
closesodoo/odoo#37789
X-original-commit: 42eec88e5da164e4930c48113109f2c8d4b73da3
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Because of f206714af0 and subsequent commits, adding groups may raise.
Thus, it is always safer to first remove groups and then add new groups.
The converse could raise, making settings save impossible.
Closes#37481
Forward-Port-Of: #37517
In an onboarding situation, the company doesn't have a logo
make an invoice, send and print, print
The document layout editor's layout opens, because nothing is set up
on the company
Click Save
Before this commit, it was impossible to make the invoice print
because each time the document layout was displayed
After this commit, the invoice prints when clicking on Save
There is no default external layout for main_company
Also, the heuristic used to evaluate whether a company
has been set up, onboardingly speaking, has changed.
Before we used the existence of the logo, after we check if
a layout has been setup. When saving the document layout
modal, a report layout is written on the company
So, practically, the document layout modal only appears once
when trying to print invoices (or other documents)
closesodoo/odoo#37137
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Redirect_type was renamed from 3xx to redirect_3xx, but name is used as http
status code. It is better a redirect(301) instead of redirect(redirect_301)
Re-add the bind_to_environ, it was removed because it seems not useful, but
once you are behind a proxy, werkzeug need the environ to find the correct
hostname and more ... Transformed relative url into absolute by werkzeug was
wrong.
closesodoo/odoo#37733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Werkzeug 0.15 modified ProxyFix such that by default it only forwards
the REMOTE_ADDR when enabled, whereas before 0.15 it would also
forward scheme and host. This breaks proxied odoo as the base url
becomes incorrect (cf #34412).
Use properly configured ProxyFix when running with werkzeug 0.15, old
configuration otherwise.
Backport of 4057227def which was merged
in master, because many people apparently run 0.15 now.
Closes#35085closesodoo/odoo#36212closesodoo/odoo#37708
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
fw-bot