Add a test for exporting the source terms of modules.
This will allow automated scripts to fetch latest terms
Backport save_test_file with a parameter on date_format to have
predictable filenames
closesodoo/odoo#159373
X-original-commit: e7246ea48828746471a2e3a485bee30687eeee80
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When installing a new module, the access of the Default Template User
is propagated to any existing employee (introduced at
aefb05eb497a8a16a). This can be problematic in companies that don't
want all their employees to become manager by default. Allow to
disable this behaviour in a settings.
This is the version of the patch targetting stable version that is not
configurable through the interface, manually creating an ICP
base_setup.default_user_rights_minimal=True as the way to change the
behaviour.
Closesodoo/odoo#149224
Task-id 3685856
closesodoo/odoo#154816
X-original-commit: 70f66f147bb0c133be6ae3fd2b11438afe2366a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Everytime somebody leaves a review, it sends a message to every
follower of the subtype "Discussion". Portal users were subscribed
without realising it.
Issue 1:
When subscribing via the controller, a user was subscribed to the
"Discussion" subtype instead of "Presentation Published".
Issue 2:
When requesting access, if there is no responsible for a channel, the
activity_schedule method fallback on the current user (portal) and
subscribe him to the channel at the same time.
If there is no responsible, there is nobody to request access to.
Disable the o_wslides_js_channel_enroll to hide the request access
popup and skip the activity_schedule if the method was called anyway
(i.e. fix for stable without updating the view)
DELETE FROM mail_followers_mail_message_subtype_rel r
USING mail_followers f,
res_users u
WHERE u.partner_id=f.partner_id
AND r.mail_followers_id=f.id
AND r.mail_message_subtype_id=1
AND f.res_model = 'slide.channel'
AND u.share = true;
closesodoo/odoo#145742
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The website_page_controller_expose is a technical model for portal and
public, not for employee
The side-effect of the change was that, before this commit, the
category Website was no longer a selection but a list of boolean only
accessible in debug mode
closesodoo/odoo#144342
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
The language was added at dccc8f39d0
419.png as odoo thinks it's a country...
closesodoo/odoo#143439
X-original-commit: 3bb58958c8f5f98da21bdac411bd226d03e1591b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Was already signed in pallavisrivastavaa.md
closesodoo/odoo#142426
X-original-commit: d586acc0d08e8fc2f2221c4e8b6ff6fc2577e81b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Was logging
<ul><li>Test mailing successfully sent to foo@example.com</li></ul>
closesodoo/odoo#141327
X-original-commit: e382f505b2061e5043bfb79a5c0f2787e40fae8b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Those are no longer used and should never be displayed
Source: feedback of users that were wondering why they are subscribed
to very old unrelated mailing lists while those are all inactive
closesodoo/odoo#139442
X-original-commit: 35203a93dbb002e2e8c6943073c14acdfc5f90f1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit escape was needed to use a Markup object as a
parameter, hence loosing the fallback mechanism in translations
>>> escape(_("Order %s has been confirmed")) % Markup("<a>%s</a>") % order.name
Markup("Order <a>SO42</a> has been confirmed")
Now it is possible to explictly give a Markup object to the gettext call
>>> _("Order %s has been confirmed", Markup("<a>%s</a>") % order.name)
Markup("Order <a>SO42</a> has been confirmed")
Part-of: odoo/odoo#139316
Similar to d2edee2f6a6
Before this commit, web crawlers may endlessly index pages with tags,
the number of combinations were very large very quickly and could lead
to thousands of requests
opw-3525473
closesodoo/odoo#138718
X-original-commit: 953ac4bde2258d31c2d2f3f6233fb00c802b6e7f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The summary is a short char field. It should not contain carriage
returns.
The description is the longer text field.
Remove unnecessary spaces in both.
Automatically dedent the description to avoid this issue poping up
again in future modules.
closesodoo/odoo#138214
Related: odoo/enterprise#48695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The method get_resource_path is redundant with file_path but without
all the checks.
The method will be deprecated in master but make it use file_path in
stable.
closesodoo/odoo#136272
X-original-commit: 64ab4a6914dadd741cfe61d9bd1959ae4509a1ca
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
And load only two languages, not three.
Faster to load and avoids ambiguity when a Mexican sees es_ES content
closesodoo/odoo#134785
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before es_MX was informally considered as the "reference spanish" as
we have an office in Mexico.
Create a new language that will be used by all the local variations of
Spanish and that we can push without overlapping with es_ES content.
Part-of: odoo/odoo#134785
Since 69f911d994 it was no longer possible to post an HTML
message via a script. Allow to do it but log a warning to discourage
doing so. Markup object should still be the propoer way to do it.
closesodoo/odoo#130883
X-original-commit: a890db49935813d0794765492c057404592e5977
Related: odoo/documentation#5273
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The label was already Status on the field but not in the search view.
"State" is always used for the meaning location.
Sharing the same term meant it was not possible to have two different
translations.
closesodoo/odoo#130444
X-original-commit: 70fcdf30fc842410aafa9e61d2a1903589a15311
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If a user goes from "Access Rights" (base.group_erp_manager) to
"Settings" (base.group_system) he gets an error telling him he did not
belong to Access Rights group.
The reason was that the modification of accesses on the user profile
page was doing
write({'sel_groups_2_4': 4})
which was transled, after the _remove_reified_group call into
write({'groups_id':[(UNLINK, [2, 4]), (LINK, [4]]})
so the user was temporary in a state where he was in the group_system
but no in group_erp_manager.
When the implied groups where computed, an access error was raised as
the administrator was not allowed to modify res.users record (need
group_erp_manager).
Simplify the _remove_reified_group call to only convert the call to
write({'groups_id':[(LINK, [4])]})
closesodoo/odoo#129335
Task-id: 3265053
X-original-commit: 0ed2fa018a7716f0fb3abe587983209403445fc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Make the user be in at least one of the group employee, public or
portal to be more coherent with Odoo
closesodoo/odoo#125216
Related: odoo/enterprise#42628
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If a user is not present in the request, he is in no group at all and
can not access any model, including the one available for public
users.
Avoid ambiguity by using sudo or add a user specifically.
Part-of: odoo/odoo#125216
Specify explicit route for each ,, line
This is part of task 3230280 where global ir.model.access will be
forbidden.
The goal is to make access to public/portal explicit. Too often,
global access was granted with only employees in mind.
Remove ,,0,0,0,0 lines
mail:
employee already had read access to mail.group
still needed to subtypes as in ir.rule domain
mail_group: employee already had read access
pos_mercury: only needed for employees
membership:
move public access for website_membership as needed in the controllers
website_customer: employee already had read access
website_event_booth: no need for category
website_event_exhibitor: retrieved in sudo
website_event_track: not needed for location
Part-of: odoo/odoo#125216
The translations on Spanish (Mexico) are more active than on Spanish
Moreover, most other countries speaking a variant of Spanish are
located in Latin America and are closer to es_MX than es.
To solve this, when installing for instance es_AR, the translations
will be loaded in the following order:
1 es
2 es_MX
3 es_AR
In case a term is translated in both es and es_MX (and not es_AR), the
later will be used
closesodoo/odoo#121415
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
TestMailCommon was an empty class in test_mail kept for backward compatibility
while MailCommon is in mail. This is needed as we plan to move test_mail in
another addons path in order to isolate test addons.
Task-3263512
Part-of: odoo/odoo#117606
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If one of the theme was not migrated to the new tx api, still support
the previous notation.
Happened on the design-theme repository
closesodoo/odoo#113571
X-original-commit: a8355ba3dddb5f3c8a8e8e777aff85d558410971
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit the message was only containing a message 'Personal
information update.' but it was not clear why the person was receiving
this message nor why he was receiving it.
closesodoo/odoo#113550
X-original-commit: de0061326bbd9e2fc5319c05448395afa5b71afe
Related: odoo/enterprise#37492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When loading a module, the code in the tests directories should not be
loaded.
One does not need freezegun on a server without running the tests.
closesodoo/odoo#113536
X-original-commit: 705c5d5dd9b76850638bd5d36b8395314ba78248
Related: odoo/enterprise#37481
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Tansifex is deprecating it's client and switches to a go-based
solution in its API v3
The new client is still backward compatible with the old format but
the v2 API is going to be phased out.
See https://github.com/transifex/cli to install the deplyments using
the tx client
This PR is the result of the "tx migrate" command
closesodoo/odoo#112402
Transifex: adapt to new URL format
X-original-commit: 7ca55aec4f1faa8bc2ad80d730a7f0771df3998e
Related: odoo/documentation#3534
Related: odoo/enterprise#36950
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Using the word "Security" as a label may bring some wrong expectations
on what the value does.
Only on server action does this value is actually enforced at run
time. For window actions and menu, it is only for UX purpose.
closesodoo/odoo#111954
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When activating the option "Restrict Template Rendering" the employee
group no longer gets the group automatically via the Implied Groups
field. However this did not have much effect because
- all the existing employees still had the group
- new users had the group via the template user
Remove the group with active_test=False to include the Default
Template User in the list.
Before this commit it was a bit confusing that new users still got the
group by default, even after deactivating the option in the settings.
closesodoo/odoo#110900
X-original-commit: ea0f674ac15964aaeb3def31758cec558b354a99
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This method is used in Transifex synchronisation scripts and needs to
be called in RPC.
It was the case before 727ef9e0a2ca9308
closesodoo/odoo#110087
X-original-commit: 3b7e4535d358e554f7b089828efb82bc6b0a40e3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Nodes like
<attribute name="t-on-dragenter.stop.prevent">() => state.dropzoneVisible = true</attribute>
should not be exported in the translations files but
<attribute name="string">Hello World</attribute>
should be kept
It was already the case in the xml processing method for server side
templates.
Since 16.0, client side QWeb views also use the same inheritance
mechanism than the one on the server side so the exception needs to be
replicated.
X-original-commit: e05d1192481935b2cd7aae7e939f98e60e002899
Part-of: odoo/odoo#101053
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The trusted devices are valid for maximum 90 days (TRUSTED_DEVICE_AGE).
No need to keep them in the list of trusted device, it may even be
confusing.
closesodoo/odoo#95796
X-original-commit: 49130e60a3c43fa3df0adddbd3359e437f5bc0b2
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Until know, Transifex projects were organised as:
- odoo-14
- odoo-15
- odoo-master
with odoo-master changing frenquently to reflect the
last used saas version, to prepare the future odoo-16 version.
This was ok as most people used stable versions at that time.
Now the saas versions are frequently released and many users of
odoo.com are running these versions, the quality of translations is
more important and preparing for the future version is not the only
goal.
Having only one project synchronised with a saas version is not enough
as we frenquently have to support multiple versions in parallel
(e.g. saas-15.2 for users and saas-15.3 for odoo.com).
Switch to a project for each saas release to be more flexible.
Hopefully, it won't be too much additional work for translators thanks
to TM.
New organisation
- odoo-14
- odoo-15
- odoo-s15-2
- odoo-s15-3
and delete projects when it is no longer supported
closesodoo/odoo#94010
X-original-commit: bb071a903d5f0b2de4c3f945ed5f4ed7d13b1e94
Related: odoo/enterprise#28588
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If a list of emails is bigger than 500, the email was sent several
time to some people.
The mail_values content was not reset between each batch, so if 1200
emails are sent, 3 mail.mail records were created for the emails in
the first group.
closesodoo/odoo#93658
X-original-commit: f838a0cc36e51e0f47daeec6522df8e9832aad2c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove leftover translations from some modules that no longer exists.
closesodoo/odoo#93572
X-original-commit: d16d24a360ffe1a703e012746fb95efbe16536ad
Related: odoo/enterprise#28352
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The js content of the odoo-editor is located into the
web_editor/static/lib/web-editor directory.
Only the js code located into */static/src/* is considered for export
of translations. This is done to avoid poluting translations for code
not managed by Odoo.
The best solution is to move the odoo-editor code inside static/src
but as a workaround in stable, we can add the terms manually in the
.pot file.
This has the drawback of being lost in the next export of translations
so should be considered as a temporary solution.
Fixesodoo/odoo#93258closesodoo/odoo#93360
X-original-commit: d2e40ea2b36df8488402ec3401bd1bb3669dc05c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Translations of type model_terms are similar to model and the access
rights can be checked on the referenced record instead of
ir.translation
closesodoo/odoo#90101
X-original-commit: 992a919d09c3ba224a64241f4a6c16c1a086eb4b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Localisation modules are converted to English and published in a
separated project on Transifex
https://www.transifex.com/odoo/odoo-15-l10n
Every localisation module will progressively be converted to have the
source in English and translated via Transifex.
This will allow developers to improve the localisations without having
to work with translators directly.
closesodoo/odoo#88439
X-original-commit: e5dfe8613723ba522e20334568c5637188ff2252
Related: odoo/enterprise#26091
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The signature of the _load_module_terms was changed at ac63556e23 to
pass explicit parameters instead of values hidden in the context
The previous code used working on a copy of the context when modifing
the 'overwrite' key. This was no longer the case after ac63556e23.
In case multiple languages are updated at the same time (as when a
module is updated), the 'overwrite' value is set to True after the
first loop.
To reproduce:
1. Create empty db with language English and without demo data
2. Activate languages fr_FR, fr_BE and fr_CH
3. Install module "note"
4. Now change in the fr.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante FR"
and in the fr_BE.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante BE"
5. Now update the module note without overwriting translations
(--i18n-overwrite option not set)
Observed behaviour:
The translations are overriden
opw-2760359
closesodoo/odoo#85768
X-original-commit: 37b98d413debabcd966718b2834d34f349e3cfbc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Without ce342f42f21cad3 the new test fails because copying an
attachment requires write access to mail.template
closesodoo/odoo#85271
X-original-commit: d5ceaa13a36e86e97f14e870ade477f62234b304
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It was not possible to set a different value via the field datas
Add tests
closesodoo/odoo#83175
X-original-commit: b1f047430c97ad4c0da028c1654ce640378e2f51
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When trying to identify the user sending an email, do not match anyone
without email.
Sometimes we get an email without a valid From address (spammers or
bugs), the previous code was trying to find users with this email.
In historical databases, we often have many users without an email
address, they should not match the search.
This commit fixes two bugs:
_mail_find_user_for_gateway:
No longer match on the first res.users with no email when identifying
the user using the gateway. This was not problematic (as we have a
fallback on self._uid anyway) but it is more accurate for tracebality
of emails.
_find_members
This method is called from _alias_get_error_message to verify that the
sender is indeed in the group with the followers restriction. On large
mailing list, it is not uncommon to have members with empty emails
(migration, historical reasons,...). Sending an email without any From
was matching on these subscribers without email and the email was
accepted.
These emails are invalid and should not be accepted.
closesodoo/odoo#83122
X-original-commit: 8ec7b92467da2856a496210af1f2232eba6bafb4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The store_fname is calculated based on the checksum, as for file_size
and checksum, skip during create/write
Avoid replacing in place the attachments in base as this breaks some
tests reusing the vals_list content (e.g. test_complete_me
Set datas in the copy to keep the content when duplicating a record
(e.g. test_14_duplicated_css_assets fails without this)
running twice because of @warmup share the same self.vals)
closesodoo/odoo#82919
X-original-commit: 611e6794376b0d60291dec085485bb2fb4e31a33
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Test was failing since 2022-01-16, probably a max 2 years sync
FAIL: TestSyncOdoo2Microsoft.test_restart_synchronization
Traceback (most recent call last):
File "/usr/lib/python3.8/unittest/mock.py", line 1325, in patched
return func(*newargs, **newkeywargs)
File "/data/build/odoo/addons/microsoft_calendar/tests/test_sync_odoo2microsoft.py", line 21, in patched
return func(self, *args, **kwargs)
File "/data/build/odoo/addons/microsoft_calendar/tests/test_sync_odoo2microsoft.py", line 84, in test_restart_synchronization
self.assertMicrosoftEventPatched(event.microsoft_id, {
File "/data/build/odoo/addons/microsoft_calendar/tests/test_sync_odoo2microsoft.py", line 40, in assertMicrosoftEventPatched
MicrosoftSync._microsoft_patch.assert_called_once()
File "/usr/lib/python3.8/unittest/mock.py", line 892, in assert_called_once
raise AssertionError(msg)
AssertionError: Expected 'mock' to have been called once. Called 0 times.
Calls: [call._constrains(calendar.event(2049,)),
call._constrains().__iter__(),
call._constrains().__len__()].
closesodoo/odoo#82849
X-original-commit: 86911c4e9b9f86f3b9a5625b973e78103a7b0286
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Header of XML files should not be translated.
Before this commit, some users may translate the XML header and get
invalid XML if translating words like "encoding"
Fixesodoo/odoo#82155closesodoo/odoo#82439
X-original-commit: aaac6fc04f4e5aa4c9ad68d9e844f3e786044800
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before that, uploading a file from a kanban was adding res_id=0
Was missing from 5e81850ea6
closesodoo/odoo#82101
X-original-commit: 6b4b68a2682a233ca058f3b89ea0aa096061c0eb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The origin parameter must be an absolute link (starting with a /)
To be consistent and always have a leading slash (and avoid relative
links if the developer forgot to add a leading slash)
This will avoid spending half hour hunting why an inactive employee
was sendig a spam before realising it was from 2 years ago (true
story)
Modify the tree view to be coherent
closesodoo/odoo#81219
X-original-commit: cb3e34db1b2ce6ffe82ee15cc21ded9bbac91062
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A designer may not have access to ir.model.fields, use the fields_get
helper instead
Fixesodoo/odoo#80948closesodoo/odoo#81123
X-original-commit: 826100a5b5ecaf62dfe6870bf5ad48a37cd2d7f7
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
>>> u1 = self.sudo(False).browse(1)
>>> u2 = self.sudo().browse(2)
>>> (u1 + u2).env.su
False
>>> (u2 + u1).env.su
True
Ensure all attachments are always in sudo
Before this commit, a portal user could not go in debug asset
Introduced at 3a98996eed
closesodoo/odoo#80807
X-original-commit: 9f0ce611b2acf5927a7703a7811081c4adbc3f41
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When the public user is connected, allow him to print the report of
the open cart.
Since 61b4b6777d64 the sudo is not enough but with_user(1) is
required.
closesodoo/odoo#80803
X-original-commit: a4021965f1f049c69186e1f2acbc55ae59ee8730
Signed-off-by: Olivier Dony <odo@odoo.com>
Same as 5dde19c92ecee, sudo is not enough but the report needs to be
rendered with the user 1.
The access token proves the user has the access, the fact that he is a
portal, employee or public should not change the result
closesodoo/odoo#80491
X-original-commit: 66ab2ae213f05b055a032d0810de1de9334741ac
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If the subject is not set, the wizard set the subject as "Re: False"
closesodoo/odoo#80372
X-original-commit: 169775419e0f14723c19ff5f14e0907c179721d9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Martin Trigaux (mat)