Some models would like to use the 'mail.alias.mixin' but it creates an alias
for each record in the parent model. This leads to a lot of unused aliases
if only a subset of those records really use aliases i.e. a lot of aliases
with 'alias_name' being 'False'.
In this commit we introduce a new mixin 'mail.alias.mixin.optional' that
behaves like the old 'mail.alias.mixin' but without having the 'alias_id'
field required i.e. without the "inherits". When creating a record without
giving an 'alias_name' no alias is created.
In future commit, we plan to use it notably to remove custom code in account
journal model and make it more standard. Using it in more models will be done
later, but it is a candidate to cleanup unused aliases related to discuss
channel model.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Linking some bug fixes about that subject (notably due to 'account.journal'
model that uses aliases without going through the 'mail.alias.mixin', hence
allowing to see differences between sanitize and constraint):
* odoo/odoo@33bd1a951a : non ascii aliases when installing COA and generating
journals automatic email aliases;
* odoo/odoo@e08ee893d1 : left-part should not begin or end with dots as well
as containing dots sequence;
* odoo/odoo@f1215389e8 : prevent international char in aliases;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Improve tests related to alias management in 'account.journal' model. In
order to support multi-company based alias domains we are going to cleanup
custom management of aliases in journals, moving towards a standard usage
of 'mail.alias.mixin'. This commit prepares this change by adding more
complete tests about current behavior of aliases.
This notably improve tests from odoo/odoo@339cdffb68 where the purpose is to avoid
issues when installing a COA, aka creating journals in batch.
This also adds tests for odoo/odoo@400b686027 where we ensure alias defaults are
synchronized with journal configuration.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently ICP parameter clean and check is done at create / write override.
However it should be done at ``set_param`` level to avoid messing with the
specific behavior of ir.config_parameter with falsy values.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
In addition to checking conflicts with existing aliases, we have to check
that given name list also contains only unique names. Otherwise creating
in batch with duplicates raises the SQL unicity constraint instead of the
expected UserError.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Aliases should be unique except when they are empty. Indeed each valid email
address should be unique, as it targets a specific behavior e.g. creating
a task in a project or a ticket in an helpdesk team.
For that purpose an SQL constraint exists that enforces the unicity. Null
values in DB are not considered as being the same, meaning we may have
multiples aliases with Null values in DB.
When voiding the alias we may end up with a void string, which is not the
same as giving False to the ORM in term of DB storage. Multiple void strings
break the unicity constraint where multiple False strings do not.
In this commit we therefore enforce that void alias names are forced to
False to avoid any constraint issue. Sanitize method is now independent
from the check method, to avoid calling multiple times the sanitization
as it is often used for other checks.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
CODE LINT / CLEANUP
Reorder fields definition per main usage: definition, owner, parent, gateway
configuration. Order computed fields accordingly.
Rename some methods (notably constrains), move an inner sanitize method as a
model method to allow its future usage.
Perfom a quick linting of code, simplify some lines.
TESTS
Add some tests related to alias management, notably copy, and multi-company
models using aliases. Those will help when moving to multi-company support
for aliases.
Add tests for current sanitation / cleaning of alias names and alias domain
parameters, to be more precise about accepted / unallowed characters, support
of unicode, ...
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
before this commit, in the forum post form view, the
closing related fields, is visible even if the post
is not closed and question field should not be shown
in the parent post.
after this commit, closing fields will be shown only
once post is closed and parent_id and is_correct
field will be shown only in child post(answer)
closesodoo/odoo#129299
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, in the forum validation queue filter,
along with the text filter instead of icon some hard coded
value(圾) is shown as text.
* create a user with very minimum XP
* create a post from new user login
* from admin login, click validation queue in the
forum
* click on filter in the validation queue
after this commit, the text will be replaced with fa-font
icon, so that all filters will look similar.
closesodoo/odoo#123636
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Information about iap services and current credit available to view from odoo
Can edit some iap services fields from odoo (warn me, warn threshold and warn email)
Change the redirect route of view services to view my IAP accounts
Add button to buy credits from the form view of iap accounts
closesodoo/odoo#121398
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
before this commit, on deleting a question from
forum is redirecting to the same question
page with deleted tag.
after this commit, user will be redirected to
forum home page after deleting a question
closesodoo/odoo#118686
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: bus, calendar, im_livechat, web, website_livechat.
This PR adds the possibility to set the current user during tests as
well as the mail guest. This will be used to test mail guest page and
livechat once the visitors will be treated as guests.
part of task-3332628
closesodoo/odoo#130811
Related: odoo/enterprise#45331
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
With the introduction of Bootstrap in the PoS, the navbar was still
accessible when showing a tempScreen as the PartnerListScreen. This is
not intended as the tempScreen act "like a big popup" where the user
must do the action on the tempScreen before doing anything else.
The problem here is that the Bootstrap integretion forgot to add the
correct style to the div "block-top-header" which is done in this PR
(background-color, width, height and position).
closesodoo/odoo#130736
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since [1] form fields cannot be moved outside of their form and since
[2] table of contents cannot be nested within another table of content.
Those were implemented with specific references to website classes
within web_editor.
This commit introduces declarative mechanisms for both situations:
- `data-drop-lock-within`: prevents dropping outside the closest parent
that matches the specified selector.
- `data-drop-exclude-ancestor`: disallows dropping within a parent that
matches the specified selector.
[1]: https://github.com/odoo/odoo/commit/638d0e875dcb05191fe833d2f889235891dfb46a
[2]: https://github.com/odoo/odoo/commit/55339cd6a7b7916184893c0fe27b5483683a047a
task-3131384
closesodoo/odoo#130477
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This PR adds the `add_guest_to_context` decorator in order to provide a generic
way to extract the guest from a request. It will be used to unified guest
extraction from cookie/param based on its provenance (external livechat/public
page).
This is better than the `pre_dispatch` method since it can be applied to
specific routes instead of adding this logic to every request.
part of task-3332628
closesodoo/odoo#130052
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
With this commit, users can send voice messages in channels and chat.
There's a new button in composer to record audio from the microphone,
up to 1 minute clip duration. This adds a voice attachment with its
dedicated voice player that shows waveforms and allows playback.
To ensure compatibility in all supported browsers, we choose to
encode voice recording with `audio/mp3` thanks to lib `lamejs`.
Task-3240168
closesodoo/odoo#117036
Related: odoo/enterprise#45482
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When the payment method was detached from the customer, trying to pay with the
linked payment token would end up with a crash because Stripe failed to send us
the payment intent, as it could not create it. In that case, a logger error
occurs on the server which creates noise in the sentry.
Error: The creation of the payment intent failed.
Stripe gave us the following info about the problem:
'Your card has insufficient funds.'
The logger is updated to use the 'warning' level instead of the 'error' level.
This change reflects a less severe logging level for cases where the creation
of payment intent fails.
sentry-4363481906
closesodoo/odoo#131334
X-original-commit: 772457554083847eb6088509ed57acff86702783
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Saurabh Choraria (sauc) <sauc@odoo.com>
When a customer requests an invoice in the `point_of_sale`, use the same
flow as in `account`: the "Send & Print" button.
It generates the pdf, the EDI attachments (Factur-X, Peppol Bis 3, etc)
and send it to the customers/governement. Indeed, in some countries, it
is required to sign the invoice to the government upon validation (e.g.
CFDI in Mexico).
closesodoo/odoo#131317
X-original-commit: 2cc9a35860b59063f536eea9234a1e9c5fa2f00e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since the use of Bootstrap, the money inputs using the useValidateCashInput hook are no longer correctly displayed when the user input is invalid.
Steps to reproduce:
- Open a session in a shop
- Open the "Cash In/Out" menu with the top right dropdown menu
- Enter an invalid amount, like "invalid" for example
The input is not displayed with red borders.
This commit fixes the display of invalid inputs in the Cash In/Out and Closing Session popups, using the Bootstrap is-invalid CSS class.
closesodoo/odoo#131246
Task-id: 3444048
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Since 16.4, the number of file made pylint reach the default memory
limit from time to time. This commit will remove the limit for this test
as it was done for chrome. The next step would be to split the test
per set of module or maybe analyze the memory consuption of some custom
check.
closesodoo/odoo#131336
X-original-commit: 8acb8d9a8bf5e19b53528275a4ddd5d4a289472b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce:
- Go to Contacts and open any contact (e.g. Contact X)
- Check its configured Account Receivable (e.g. 121000 Account Receivable)
- Configure that account and set a default Sales tax on it (e.g. Tax 15%)
- Create an invoice with Contact X as customer
- Add an invoice line for any amount (e.g. $100) and any tax
- Swith to "Journal Items" tab and display "Taxes" column
A line (with 121000 Account Receivable) has been created automatically to balance the invoice line.
This line has a tax (i.e. Tax 15%): the default one configured on the account.
There should not be a tax for a receivable account.
Another issue is that the tax is set on the aml but not tax line has been created.
- Go back to "Invoice Lines" tab
- Remove the tax on the invoice line
- Save
In "Journal Items" tab, the tax line has been created from the aml with the receivable account.
- Go back to "Invoice Lines" tab
- Add a tax on the invoice line again
- Save
- Remove the tax on the invoice line
- Save
In "Journal Items" tab, there are now 2 tax lines from the aml with the receivable account.
By repeating the previous steps, new tax lines can be created infinitely.
Solution:
To prevent the issue, the default taxes shouldn't be populated on the aml when the account
is a receivable (or payable) one and when the move type is an "invoice" type one.
As "display_type" field of "account.move.line" is set to "payment_term" when the account is
a receivable or a payable one and when "is_invoice" is True on the move, no tax will be set
in "_compute_tax_ids" computed method when "display_type" is "payment_term".
opw-3345953
closesodoo/odoo#131330
X-original-commit: c6076a272cfe997856f3026557900ce9718c45e5
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
`_get_starred_counter` method is obsolete now.
So, there is no meaning in keeping it anymore.
It's usecase has been removed by this PR
https://github.com/odoo/odoo/pull/83777closesodoo/odoo#131299
X-original-commit: cbf590bfa0999e99064e1a2bb337c8e63f00dd8c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Rahul Prajapati (rapr) <rapr@odoo.com>
Incorporate Alejandro Mellado (alejandromellado) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#131277
X-original-commit: 73ee076bb20245fde8629a9f16caea16424c105b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce this bug:
1- On a Bank type journal, set true the "Use electronic and deferred
checks" field
2- Do a new vendor payment with Bank journal and Manual payment method
3- Corresponding journal entry shows "Check False delivered"
closesodoo/odoo#131256
X-original-commit: 4f70fb08af830dd2fece740905c02e598a26b0f6
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Reproduction:
1. Install Note, create a new note
2. Start the Inspector, edit the placeholder <p> element in the
description
3. Replace the element as `<p style="color: rgb(32, 31, 30); font-family
: "Segoe UI", "Segoe UI Web (West European)", "
Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helveti
ca Neue", sans-serif; font-size: 15px;">dsfhislahflidsahisa</p>`
4. The saving icon appears, click it but it will always be there, e.g.
always dirty
Fix: instead of comparing the raw value of the prop value and editing
value, we parse them and compare after the parsing
opw-3341605
task-3434080
closesodoo/odoo#131245
X-original-commit: eda483bd3c3bdc42b95f17a5278c1a9eb83adb05
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Similar to what was done [here](https://github.com/odoo/odoo/commit/5d0111d079601c07c62717575cb22ead15c585d0) when the credit limit feature
was introduced, a `sudo()` is also necessary in
`_load_records_create()`.
This method is called when importing contacts from a CSV file.
So the access to the commercial fields is done when synching
fields from the commercial entity to its contact and should
not block the import.
Fixes#126567closesodoo/odoo#131225
X-original-commit: 266e22fc4ea5bb4343700f8d08f9ec2580fab365
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, the follower loading spinner was shown
for draft records until it was saved. This is incorrect,
follower count should instead be 0. This commit fixes this
issue.
closesodoo/odoo#131224
Signed-off-by: Didier Debondt (did) <did@odoo.com>
To reproduce the issue, follow these steps:
1. Install the Timesheet and Project.
2. From the settings menu, create a new company.
3. Create a project using the newly created company(e.g. New Company) and add
a task to it.
4. Open the Timesheet application and create a new timesheet.
5. In the timesheet, select the project created in step 3, and observe that the
dropdown for tasks does not display any task.
Cause for this issue:
-The timesheet application has a domain set for the task field where the company
associated with the task_id should be the same as the company selected in the
current environment.
-However, when a new project is created with a 'New Company', the tasks
associated with it also have the 'New Company' assigned to them. On the other
hand, the current environment has a default company called 'Your Company'
associated with it.
-Therefore, due to this domain setting, the task field does
not display any tasks since there are no tasks associated with the
'Your Company' in the current environment.
Fix:
Since the cause of the issue is related to the company domain set in the task
field, we can solve it by removing it from the domain.
task-3323027
closesodoo/odoo#131197
X-original-commit: 7b9f9a1323ecaeab2b248784e1493b39fe07b8f1
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The 'onsite' payment provider shouldn't be shown to the user
if the cart/order only contains services (or if there are no onsite carriers).
The logic was there but the filtering didn't correctly update the values.
opw-3437107
closesodoo/odoo#131177
X-original-commit: 78cd9a7ab5fb860021a906400a1907b1d8b45be2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, calls to record[fieldname][value/raw_value] in
the arch of a kanban view did not take into account updates on the Record
Datapoint. So if any data in the Record changed, the [raw_value/value]
was not modified.
In a custom KanbanRecord, you should never use the record containing the
value and raw_value. We will therefore replace this call by using the
datapoint record directly.
How to reproduce:
- Have a kanban view with a record.my_field.value and a widget allowing
you to modify the value of my_field.
- Click on the widget
Before this commit:
The value of my_field does not change
After this commit:
The value of my_field has been updated.
closesodoo/odoo#131165
Related: odoo/enterprise#45413
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Steps to reproduce:
-------------------
- go to Recruitment app and click on a job position;
- for an application without recruiter,
click on the "Assign" button on the kanban box.
Issue:
------
A traceback occurs.
Cause:
------
To find available user_ids,
we use the `"[..., ('company_ids', 'in', company_id)]"` domain.
But `company_id` is not in the context.
Solution:
---------
Add `company_id` in the context by adding it to the view.
opw-3450558
closesodoo/odoo#131159
X-original-commit: 4fa18ec336b9f44648c1eaa272d6e38f536b628b
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Steps to reproduce:
- Install `website_appointment` module
- Activate a second language on main website
- Activate debug mode
- Go to Website -> Configuration -> Online Appointments
- Share multiple appointment and copy the link
- Open the link in a new tab
- Switch to second language
- Open editor and click on `Translate` button
Issue:
Traceback is raised.
Cause:
When sharing multiple appointment and opening the shared link, we are
redirected on the page to select the right appointment and we have the
key `filter_appointment_type_ids` (with the IDs of the appointments)
with the value already encoded.
e.g: `[1, 3]` => `%5B1%2C+3%5D`.
When translating a page by redirecting to the same URL (but encoded)
with param `edit_translations` set to 1, the URL is re-encoded and
therefore the value of the key `filter_appointment_type_ids` is double
'encoded' and broken/not possible to parse.
e.g: `%5B1%2C+3%5D` => `%255B1%252C%2B3%255D`.
Solution:
Don't re-encode the updated URL; `goToWebsite` is expecting a non
encoded path and is in charge of the re-encoding it.
opw-3409757
closesodoo/odoo#131150
X-original-commit: 574d7847bda5c6e21934f815f64d0d4ce3f70b8b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since #119325, html2canvas is not used for the toInline process anymore.
Loading the script was still done in the web editor and mass mailing,
which is not needed anymore.
task-3446888
closesodoo/odoo#130862
X-original-commit: e3c9d3c4fb013124faf6d132297171a34854f991
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The goal here is to simplify the code of the insertion of a pivot in the
pivot core plugin. Now the domain/style for each cell of the pivot is computed
in the `SpreadsheetPivotTable` class, which simplifies the plugin a lot.
Also take the opportunity to convert all `anchor` array arguments
to `{ col, row }` objects since it's the direction we've taken every
where else: `position.col` is much more readable than `anchor[0]`
closesodoo/odoo#128981
Task: 3318865
Related: odoo/enterprise#44326
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Ths commit change the pivot/list function to defined them in a constant,
and add this constant in the function registry, rather than define the
function directly in the registry.
This allow for re-using the functions code and call it from other
functions.
Task 3318865
Part-of: odoo/odoo#128981
before this PR, some legal information were missing from our invoice layout,
for the l10n_cz and l10n_sk localization.
For l10n_cz:
- On move we add a taxable supply date
- On the company we add a trade registry field
- On report template we add the company_registry, the vat number
For l10n_sk:
- On move we add a taxable supply date
- On the company we add a trade registry field and income tax id
- On report template we add the company_registry, the vat number and income tax
id
closesodoo/odoo#126837
Task: 3374969
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
-Display the state of a time off that you open from the dashboard
-Rename Stress Days into "Mandatory Days"
-My Allocations
Remove "Employee" from the Group By
Replace filter `Current Year` with `Currently Valid`.
-My Time Off
-Remove Employees from list view and kanban view
-Create an allocation / allocation request form
- Create an allocation ux : employee side- compute the name of the allocation.
- Make field `allocation_type` invisible if there is no active accrual plan in the database.
-Accruals
-Add an "archive" in the action menu of the accrual plan.
-Show Employee button in the form view of the Accrual Plan.
-Renamed stress day into the mandatory days.
-Renamed string of the menu Approval into the Management.
-Remove two legends in the time-off Dashboard
- Public Holiday
- Mandatory Day
task-3084232
closesodoo/odoo#116472
Related: odoo/enterprise#40576
Related: odoo/upgrade#4472
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
If a given template T has two attributes lines:
* standard attribute (instant creation): one value
* no_variant attribute (never create a variant for it): one value
It will have one automatically generated variant V, which will be automatically
selected on the sale order line if you chose the template T.
If optional product(s) are added on the template T, the configurator will
open to choose the optional products.
But in this situation, the main product was shown as "Option not available"
on the configurator. This is wrong since there is the valid variant V that we
can use.
This is caused by a behavioral change in 16.0, we saved the variant V directly
on the sale order line, before opening the configurator. Previously, the values
were applied to the line after the configurator was closed (if there were optional
products).
As the values were applied before the call to `_openProductConfigurator`,
the product.template.attribute.value of V (the standard one, not the no_variant)
is given to the wizard opening, disabling the automatic fallback that previously
gave the two expected ptav's (the standard AND the no_variant one), leading to
an incomplete combination, which was considered invalid.
This commit restores the previous behavior, by setting the product on the line
only if there is no optional products. If there are, everything will be
correctly managed when the configurator is closed.
opw-3355216
closesodoo/odoo#131147
X-original-commit: 902c7112c75841ede560c51d54e12e9cf809ee8c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Values removed from the product should be hidden instead of being shown
as forbidden values.
opw-3434706
closesodoo/odoo#131145
X-original-commit: 9a581c46dca46ad44957cf1a47748f0c56ad07ca
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
before this commit, on reading data with default dict data
type is showing error to end user, without returning the
requested data.
for eg, if a read operation is triggered on model sale.order
it wont return the requested data, instead traceback is
shown in response.
in sale.order model the tax_totals field is a computed
field, with data as format default dict which was
causing the issue.
after this commit, without any traceback the requested
data will be returned to the user.
closesodoo/odoo#131123
X-original-commit: cc61b926f4daff26fb577e2f700d013ec15f4b4f
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
*:pos_hr,pos_hr_restaurant,pos_loyalty,pos_restaurant
Before when serializing a pos.order from the server, we are using
several methods for different use cases.
- table syncing: get_table_draft_orders
- order sharing: get_draft_share_order_ids
- ticket screen: export_for_ui
All of these methods had their own logic.
Now, to improve the maintainability of point_of_sale, order
serialization is only performed via export_for_ui.
Enterprise PR: https://github.com/odoo/enterprise/pull/45151closesodoo/odoo#130695
Taskid: 3449870
Related: odoo/enterprise#45151
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
before this commit, on creating a new db, the general
settings menu is not accessible for end users without
installing any app.
for eg, if user need to activate the developer mode,
no option without installing an app.
after this commit, on a fresh db base_setup module
will automatically installed on creating a new db,
and general settings menu will be accessible.
closesodoo/odoo#129298
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The current neutralization implementation for ir_mail_server deactivates
existing servers. This can still result in mails being sent if an SMTP
server was specified on the command-line. To prevent that from happening
a dummy SMTP server is defined that doesn't resolve to anything.
I've opted to use the "invalid" domain for this purpose:
https://www.rfc-editor.org/rfc/rfc6761#section-6.4 .
closesodoo/odoo#131138
X-original-commit: 4ceed406ead570b00e6e8973e55866bee4c84de8
Signed-off-by: Merel Geens <mege@odoo.com>
These flags should not be part of Odoo codebase. They have been
implemented internally.
closesodoo/odoo#130947
X-original-commit: 182e4475cef2f6d160381d58726f452169b738e3
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
**Steps to reproduce:**
- Install pos_self_order.
- Create a product with a price of any price, say 100.
- Assign a tax of 10% to the product.
- Create a new company and switch to it.
- With the same product, add a new tax, say 20%.
- Go back to the original company.
- Open a bar (restaurant pos.config) that allows self order which also loads the
product.
- Open self order page and add the product.
- [BUG] The product's price is not only 10%-taxed, but also 20%-taxed.
**Explanation and fix**
The issue is caused by use of sudo almost everywhere in the context of
pos_self_order. This commit removes/reduces this use of sudo in many places and
contextualize the records involved in the calculation such as pos.config,
product.product, etc. to be the ones of the company and the user who opened the
current pos.session.
After this changes, only the taxes that belong to the company of the pos.config
record are used in the price and tax calculations.
closesodoo/odoo#131140
X-original-commit: 7ce7f3e21ad8f457742e27f88b7146c7d8fff5f3
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Thibault Delavallée