PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Update settings to configure your company's current alias domain instead
of the global 'alias.catchall.domain' configuration parameter. As domain
configuration is globally done per company, this is now a related on the
company. Advanced configuration and management can still be done manually
in settings.
Field 'external_email_server_default' triggering display of mail configuration
is moved to mail. It is defined in 'base_setup' but used only in mail hence
moving the field to be coherent.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
Some sudo() are included in post_* methods, as portal may go through the
posting method, see 'test_portal_acls' in test_message_post.py file.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
When computing reply-to of message or documents, classify them per company
and use alias domains when computing catchall emails. Reply-to computation
based on alias is also simplified as aliases are now complete and use
alias domains. They do not depend on configuration parameters anymore.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Currently alias search is done only on 'alias_name' field. Now that alias
domains can be multiple we have to be able to search on complete alias
email definition e.g. when checking destination aliases of incoming emails
in mail gateway.
We add a new 'alias_full_name' field that is computed based on alias_name
and alias_domain_id.name. It is stored so that search is possible on it.
Allow to search on 'alias_full_name' from the 'mail.alias.mixin(.optional)'
by making 'alias_email' field searchable, based on 'alias_full_name'.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are multiple and can be linked to companies it is
easy to end up with configuration where an alias is using a domain of
CompanyA while the owner and/or target record belongs to CompanyB. We
want to avoid that situation and strengthen company separation.
When changing alias domain of an alias check that it is not used in another
company than the one define on
* the owner record (using owner fields like the 'project.project' for
'project.task' creating aliases);
* the target record (using update fields like the 'mail.group' for group
aliases that routes emails to a specific group);
If the new alias domain is linked to a company that is different from the
company of any related record, raise an error as it could lead to invalid
multi-company setup and record creation.
If the new alias domain is different from the company domain but is not
used in any company it is a valid configuration. It is just flexibility
offered by multi-domains aliases.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
As 'alias_domain' is now dynamic and not based on a configuration parameter
it makes sense to be able to change it when having several alias domain.
We now allow writing on 'alias_domain_id' in 'mail.alias.mixin(.optional)'.
Users may now change the alias domain of the alias coming with the mixin
when they have write access on the record.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add 'mail.alias.domain' information on alias model. Aliases do not use global
configuration parameters anymore. Instead they are linked to an alias domain
e.g. 'sales' linked to 'mycompany.com' alias domain: 'sales@mycompany.com'.
It is now considered as a different alias compared to 'sales@mycompany.in'
which has the same alias_name but a different alias domain.
Constraints and checks are added, as
* uniqueness of aliases is now checked inside a given domain;
* an alias name must not clash with its domain bounce or catchall;
* a combination of (alias_name, alias_domain_id) must be unique;
Crm multi-company environment is also updated to match the new alias domain
behavior.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add a new 'mail.alias.domain' model storing information previously stored
as a unique value in 'mail.catchall.domain' configuration parameter. Domains
are not completely linked to companies, allowing to have a mono-domain MC
setup, or mono-company multi-domain setup.
A main email domain is present on companies for all default domain computation
when being in that company while keeping flexibility of having other domains
defined.
Now that a new 'mail.alias.domain' model exists we move bounce and catchall
aliases definition directly on this model. Update related computation on
company model. Default_from is also moved on this model, allowing an higher
level default from computation for mail servers when having knowledge of
alias domain environment. Filtering configuration based on default_from_filter
is kept as an ICP as it is mainly used for odoo-bin with smtp-host.
Usage of 'mail.catchall.domain' will soon be completely removed to be replaced
by proposed company-based email alias domain usage.
Constraints are added so that each bounce and catchall defined on domains
do not clash with existing aliases. Sanitize of bounce and catchall is also
performed to ensure they make valid emails. This matches previous behavior
of ICP parameters. Domain name is also sanitized like alias names.
Currently only base modeling and computation is done. Their usage is about to
be gradually added in mail stack.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Composer tests now use the multi-company enabled model by default, allowing to
test company-dependent behavior. This has no impact on current tests, as there
is no company-dependent fields on composer model, and all tests are anyway
run into the main company (except multi-company specific tests, suffixed
by '_mc' generally).
We therefore also add some multi-company oriented tests to check notably
return-path or environment companies in various scenarios. Go until the SMTP
generation to test mail server choice, smtp_from and filtering, notifications
email.
Followup of odoo/odoo#136318 and odoo/odoo@3ffa1a0611 notably.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Perform some code cleanup not really related to other commits notably in mail
gateway where alias domains will have some impact. Extract some processing
in sub-methods, allowing to better distinguish code purpose. This implies
notably some checks in mail gateway (write to bounce or catchall detection).
In mail.message, reorder some fields according to their usage, just to keep
definitions / section.
Also improve docstrings and/or fix some of them.
This is mainly a "reduce diff in other commits" commit. No change should occur
with this commit.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
This may have an impact when trying to find an outgoing mail server based
on from and filter, as first match wins when checking matching filter on a
bunch of mail servers.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Due to current implementation of mocks context is lost when accessing methods
'connect' and '_find_mail_server' of IrMailServer. Indeed self is replaced by
an instance of IrMailServer and code relying on context could not be called as
planned.
This commit aims at doing a custom mock so that we can correctly rely on self
and context in those methods. This is necessary for incoming changes in mail
notably to allow testing SMTP feature in multi domains environment.
Logged information when having failed SMTP check is improved: we now also
log found From in order to ease debugging failing tests due to invalid from.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
When composer runs in 'rendering' mode, it is often based on a mail.template
record that gives information about recipients. When having no template
default recipients are added to be sure to contact 'intended people'.
When rewriting code in 16.2, support of batch-comment was added in addition to
mass mailing. Result is that now default recipients are also computed when
posting in batch. However when posting we consider recipients are already set
on records using followers. Adding default recipients to avoid dummy emails
is present mainly for the mass mailing mode.
Followup of odoo/odoo#107356
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Before this commit, live chat would fail for guest portal. In this
scenario, there is no guest token. Before this commit, the guest
token was sent anyway with `null` as value which caused a crash.
closesodoo/odoo#139585
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps to reproduce:
-------------------
- install `account` module;
- create an employee;
- add a bank account;
- add a related user and save;
- remove the user and save;
Issue:
------
A traceback occurs.
Cause:
------
We synchronize the `partner_id` of the `bank_account`
with the `work_contact_id`.
If the latter is `False`, this triggers an error.
Solution:
---------
Do not trigger the logic that updates the `partner_id` of
the `bank_account` if the value is `False`.
This keeps the logic that the `partner_id` field
in the `res.partner.bank` model is required.
opw-3558983
closesodoo/odoo#139570
X-original-commit: c19574e26d8814a745152489eb16915f13b2a6c0
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Problem
---------
When zoomed in, the peppol buttons would be displayed inline with
previous buttons in the journal cards. This is not user friendly.
Objective
---------
Make sure the buttons are displayed under (new line) the previous one on
the kanban card.
Solution
---------
Encompase the buttons in div tags.
closesodoo/odoo#139567
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Before this commit, the KanbanRenderer was rendered twice.
Why:
---
The "getGroupsOrRecords" function used in the KanbanRenderer templace
uses the "sort" function on "list.groups". The "sort" function modifies
the array on which it is called, which will generate a rerender because
"list.groups" is reactive.
Solution:
---------
Call the "sort" function on a clone of "list.groups".
closesodoo/odoo#139547
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the goal of simplify assets loading, in this commit we create a new
assets bundle for chartJS and its luxon adapter.
With this, we can now use loadBundle instead of load these two libraries
with loadJS.
task-3562357
closesodoo/odoo#139544
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
This commit is a backport of odoo/odoo@f065276a46
Before chrome 116, programmatic clicks on disabled buttons weren't
actually fired. With chrome 116, they are. As a consequence, some
tests fails on chrome 116 because they click (on purpose) on
disabled button to highlight the fact that nothing happens.
This commit improves the click helper to make it throw an error
when the target is disabled. It also adapts the tests that were
clicking on disabled button, in general to simply assert that the
button is disabled instead.
closesodoo/odoo#139537
X-original-commit: 0e8b50d540c9eee0837282883d603937b94b2fd2
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Current behaviour:
When checking "All users" then saving,
it unchecks it then checks "Employees only"
Steps to reproduce:
1. Install auth_totp_mail_enforce
2. Go to Settings
3. Check "Two-factor authentication enforcing policy"
4. Hit Save
5. ("Employees only" is selected)
6. Select "All users"
7. Hit Save
8. ("Employees only" is still selected)
Cause of the issue:
Because of onchange, _onchange_auth_totp_enforce is
called when refreshing the page, which causes
auth_totp_policy to default as 'employee_required'
opw-3523880
closesodoo/odoo#139535
X-original-commit: 1d8423e397e7646eec9eebab8a1fd40e39605404
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Steps:
- Install `website_sale`
- Enable `Lock Confirmed Sale`
- Enable `On Site Payments & Picking`
- Enable `Pay in-store` payment provider
- Login with demo user and go to shop
- Add a random product and go to checkout
- Confirm and choose on-site payment/picking
- In the backend with admin user confirm the newly created sale order
- Go to Payment Transaction
The transaction is marked as confirmed without payment. Without `Lock Confirmed Sale` it works.
The solution is to mark transaction as confirmed only if it is `wire_transfer`
opw-3501140
closesodoo/odoo#139533
X-original-commit: 71db47cff99ce3b2090c3be5dfa3205654625d51
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
When a company is created and then archieved there will be
tracebacks upon acessing res.companies records because the company
is not active and in _compute_parent_ids at company.parent_ids[0]
an empty recordset will be returned since the company is inactive
With (active_text=True) the company is returned in the recordset
even being inactive.
opw-3565757
closesodoo/odoo#139527
X-original-commit: b15975739810fe0c94ae5965cef3038ac54a58ba
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce:
refer to ticket
Bug:
if there's no available pickup points on the selected delivery method
the pay button is disabled but clicking on a payment option reanbles the
button
eventhough "_onClickPaymentMethod" doesn't enable the button since
_isPayable is false,
"_onClickPaymentOption" already enabled the button.
Fix:
disable the button before updating the payment method
also disable the button at the start when changing shipping method
(to avoid client clicking pay while carrier data is loading)
opw-3432905
closesodoo/odoo#139522
X-original-commit: 6a91e63504cb45d2f80162d2a91b76e733c0facf
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
To reproduce:
* Populate mail.message as medium or more
* Open odoo and click the messaging menu
* The messaging menu take an unreasonable amount of time to open.
This PR cache the threads getter to avoid unnecessary computations
task-3551625
closesodoo/odoo#139519
X-original-commit: aa92a630d5146b7a4ee5eb5d09bb6db04c1ba146
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue:
------
When we use stripe to pay for a subscription via ecommerce,
we get the following error message:
```
The provided setup_future_usage (off_session) does not match the
expected setup_future_usage (null). Try confirming with a Payment Intent
that is configured to use the same parameters as the Stripe Elements.
```
Cause:
------
On the JS side, the value of `is_tokenization_required` is set to `False`,
which doesn't set the value of `setup_future_usage` to `off_session`,
causing the mismatch with the PY side.
The `_is_tokenization_required` method uses `sale_order_id` which comes from the template.
The template finds this value in the `sale_order_id` variable,
which is passed via the context.
Unfortunately, this key does not exist in the context.
As a result, the method _is_tokenization_required`
returns False instead of True.
Solution:
---------
Add `sale_order_id` in the context to render the template
and therefore detect the sale order afterwards.
opw-3541316
closesodoo/odoo#139518
X-original-commit: c6b803baf26b3f26ace6464de944f681c7078c2e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
png images not shown on ir.attachment kanban
Attachment that use db_datas have no checksum by default, which is used
to compute the stream's http ETag. Skip updating the ETag when it is
missing and determine freshness using the Last-Modified header instead.
closesodoo/odoo#139498
X-original-commit: 2d43bbae72fddf17e7d9045e90dbc070b2f57a19
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
On a picking, it is not always easy to make the difference between a
waiting SM and a cancelled one.
To reproduce the issue:
1. Create two storable products P1, P2 with on hand qty > 1
2. Create and confirm a SO with 1 x P1 and 1 x P2
3. On the delivery, set the done quantities
4. Edit the SO: 0 x P1
5. Validate the delivery
Error: The SM of P1 is a bit confusing. Its demand is 0, which makes
sense because of step 4. However, its done quantity is 1 although
nothing moved according to the quants. Actually, the SM is cancelled
but nothing gives this information UI side, hence the confusion.
Step 4, we decrease the qty. It creates and runs a procurement of -1,
which creates a SM with a demand of -1. We then merge it with the SM
of the delivery and since its demand becomes 0, we cancel it:
https://github.com/odoo/odoo/blob/aebe6e616c4d62010aba67e7c4fbcc82f1385bea/addons/stock/models/stock_move.py#L1003-L1007
However, nothing displays this information client side. When the
picking is not done, the line will be red because the done quantity is
greater than the reservation (see `decoration-danger`):
https://github.com/odoo/odoo/blob/aebe6e616c4d62010aba67e7c4fbcc82f1385bea/addons/stock/views/stock_picking_views.xml#L254
When the picking is `done`, both lines will be grey (see
`decoration-muted` in above code). Therefore, the information is not
clear for the user, he could beleive that the SM has been processed.
Moreover, the user has completed the line with a done quantity. We
can't decide for him that this quantity no longer has any value. If
he really has moved the product, we have to consider it on Odoo side.
Else, he has to update the done quantity himself.
OPW-3478871
closesodoo/odoo#139495
X-original-commit: d5a1c6bfadc28503a6928580e854264e94074fa0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
To reproduce
============
- connect with a portal user and try to consult your opportunities
-> 403 error
Problem
=======
after this [commit](https://github.com/odoo/odoo/commit/604a47ead80eb8a07102a978f364d82776f69da3), only internal users can read `crm.stage`.
which leads to this error.
Solution
========
portal user must read `crm.stage` only through the portal, so we give
back the right to read when `website_crm_partner_assign` is installed
opw-3559043
closesodoo/odoo#139490
X-original-commit: 9b64a6b29cdafaee044bc4bdcd8693225d05b1ca
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, the follwing traceback was sometimes raised.
Error message
ERROR: TestCalendar.test_event_creation_mail
Traceback (most recent call last):
File "/data/build/odoo/addons/calendar/tests/test_calendar.py", line 339, in test_event_creation_mail
m.write({
File "/data/build/odoo/addons/calendar/models/calendar_event.py", line 574, in write
self._rewrite_recurrence(values, time_values, recurrence_values)
File "/data/build/odoo/addons/calendar/models/calendar_event.py", line 1084, in _rewrite_recurrence
update_dict = self._get_time_update_dict(base_event, time_values)
File "/data/build/odoo/addons/calendar/models/calendar_event.py", line 993, in _get_time_update_dict
raise UserError(_("You can't update a recurrence without base event."))
odoo.exceptions.UserError: You can't update a recurrence without base event.
closesodoo/odoo#139486
X-original-commit: bd1c46a79ea3d41a374fac47dd16af802d18045d
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
This commit adds new optional props to the Message and Thread Components:
closeThread, openThread, avatarPlaceholder and showDates.
* `closeThread` is a function that enables the user to close an active comment
thread.
* `openThread` is a function that reopens a previously closed thread.
* `avatarPlaceholder` is a boolean that will add an avatar placeholder
(fa-user icon) when needed. For example when using Knowledge via the portal.
* `showDates` enables us to hide the dates showed inside the Thread component,
it may not be useful for certain comment threads.
We also added a button inside the actionBox in the Message Component and it is
only rendered if we are on the first message of the thread.
The button can trigger either of the new function props depending on what is
provided to the component.
task-3317056
closesodoo/odoo#127380
Related: odoo/enterprise#41951
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
´extends´ generates a lot of css rules.
So in this commit, we remove it by replacing it by the ´h5´ html tag.
closesodoo/odoo#139484
Related: odoo/enterprise#49408
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The source packaging was a bit left behind, it was still using Debian
buster to build and test.
With this commit the Debian bookworm is used. As the installation of pip
packages as root is now forbidden, the build and tests are now using a
python virtual environment aka venv.
closesodoo/odoo#139482
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
As [postgresql 15] changed the permissions of the public schema,
when testing the rpm package with Fedora 38, the test fails with
`InsufficientPrivilege: permission denied for schema public`.
With this commit, we properly create the database with the odoo user.
While at it, let's do the same with the poor left behind tgz package.
[postgresql 15]: https://www.postgresql.org/docs/release/15.0/
Part-of: odoo/odoo#139482
When building the rpm package with Fedora 38, for an unknown reason, the
`python3-ofxparse` package refuse to be installed in the Docker image.
When specifying the `.noarch` specification the magic happens.
The reason remains obscure, nor I can't tell if it's linked to the
container itself.
Part-of: odoo/odoo#139482
...when voip addon is installed.
We want to avoid predictable rpcs that are systematically done at
webclient startup. In particular, the voip service needs to know if
the user has group "base.group_user", which produces a rpc when
the service is started.
To avoid this, this commit adds the information in the page
directly. As this information is also useful at other places
(even though it's not at startup), we directly add it to the
groupCache of the user service (and we do the same for the
"base.group_system" group, which we also receive in the page).
closesodoo/odoo#139477
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The attendance systray item needs data to determine whether or not
it should be displayed, and what to display. Before this commit, it
fetched it in the standard way, in onWillStart, and returned the
fetch promise.
However, for a systray item, it's better not to wait for the
promise, such that the webclient doesn't wait for it to be mounted.
In the case of this item, it is simply not displayed until data is
fetched, and when it is displayed, it's the right most item so it
doesn't produce any flickering.
This allows to save several ms on specific screens (e.g. home menu).
Part-of: odoo/odoo#139477
Improved header (billing/shipping address instead of 'my details')
Keep the use_same input value on invalid form refresh
closesodoo/odoo#139474
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the clickbot avoid testing modal menus.
Now, the clickbot open and closed the modal menus.
task-id 3535596
closesodoo/odoo#139389
X-original-commit: 60e16f1e32a0e1448c91826ec06c1e0e8a7bb1fc
Related: odoo/enterprise#49352
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Prior to this commit when the ticket screen was opened from a table, the
orders were filtered by context. This commit displays the filter in the
search bar so it can be removed. This allows the user to simply remove
the search to display all orders. This commit also removes the display
order count when null from the POS burger menu.
closesodoo/odoo#139357
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Back-port test with `contains` from `master` and specify text present
on command before clicking it.
runbot-24981
closesodoo/odoo#138087
X-original-commit: ddc9da828ad338678bfa6e3b44461f87683b828f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In this commit we simplify the POS kanban view by replacing some
of the text shown to the user with more relevant versions.
Task 3562493
closesodoo/odoo#139246
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Thibault Delavallée