Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Following the rework of global ACLs here:
odoo/odoo@7dd1796eb7
Public users cannot access the event.sponsor.type model anymore.
This caused the sponsor "closing hours" modal to not be shown anymore, as it
raised an access error.
To fix the issue, we sudo the sponsor type access in the controller that
retrieves the sponsor data to render the template.
Task-3459726
closesodoo/odoo#131537
X-original-commit: 98c01e65277a816ec4010f3c6902953366d35cbc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
An error occurs when the user attempts to delete the 'database.secret' record,
either by following these steps:
- Enable developer mode.
- Go to Settings > Technical > System Parameters.
- Select the 'database.secret' record and attempt to delete it.
Or when the user tries to update the key for the 'database.secret' record using
the following steps:
- Open the 'database.secret' record.
- Update the value of the key field.
- Save the record.
- The server will stop running and not be accessible.
Error: ValueError: CSRF protection requires a configured database secret
sentry - 4291267997
closesodoo/odoo#131460
X-original-commit: fe694e5b8285ceed99b321c22af534eee25cf282
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since 6f182eeeab,
UoM should be created through the UoM category tab as the UoM form view is now unusable.
Previous bugfix commit 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef disabled
the menu from the different applications, but later changes in sale
brought back the menu again.
Since it doesn't hurt to have the menu in debug mode, the lowest solution
would be to disable the creation of uoms from the uoms tree view.
closesodoo/odoo#131237
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this PR we fix a number of small issues related to the pos ui.
In addition to the specific fixes, this PR also simplifies many
of the components, most notably the `category_selector`.
In the interest of providing a cleaner API, this PR introduces
a new folder called `generic_components` whose goal is to contain
stateless components. These stateless components would allow for more
reusability, while simplifying the logic. The `category_selector` is
the first component in this folder.
Descriptions of each of the issues fixed in this PR can be found in the
closesodoo/odoo#131038
Tasks: 3457213
Related: odoo/enterprise#45600
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before:
When number of available domains exceeded the display limit, user was
unaware of the other available domains as nothing in UI indicated so.
Visible entries change only when user starts typing something.
After:
This commit adds a 'Start typing...' entry after visible models in
dropdown menu whenever number of available models exceed the display limit,
in order to provide a hint to the user.
When user starts typing, 'Start typing...' entry disappears and all available
domains are displayed with a scrollbar.
Task ID : 3375332
closesodoo/odoo#126156
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
RATIONALE
This prepares the move of ICP to mail before replacing them by dynamic alias
domains.
Cleanup tests: try to use loops with input / expected to better understand
the various test cases, add some comments, improve logs when failing to
find the right sent email. Rename tests to have a better test structure
when reading logs.
Remove a test from odoo/odoo@3b6c20805c that adds nothing except testing
the test suite.
OTHER ADDONS
In test_mail: have a specific class for testing servers as other data is
not necessary, and it allows to have a tag for it.
In mass mailing: concatenate test about server finding, several tests can be
done in a single unit test.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#131492
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit there are no rollback if raise.
closesodoo/odoo#131490
X-original-commit: 0015662d166f5e07bcbd6c5e9e14f8837ffa58a3
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Issue:
The currency in the RFQ created from the list created RFQ on the Purchase Agreement is incorrect.
Steps to reproduce:
- Install Purchase Agreement
- Config multi currency
- Create a Purchase Agreement with multi currency (difference main currency) > Confirm
- Click smart button RFQs/Orders > Create
- RFQ will default currency is main currency
Fix:
Add a context on button `action_purchase_requisition_list` to default currency
closesodoo/odoo#131489
X-original-commit: ff001848a2e4906dbf5401508cc0ff2185265eac
Signed-off-by: Tiffany Chang <tic@odoo.com>
With this commit you wil have the function _get_gather_domain so you can
override and manage the gather_domain by your own logic
closesodoo/odoo#131476
X-original-commit: 92b6fd647c77ae88dfb685654ba9e9f14b7a1d03
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The _compute_amount_residual method computes residual amounts on reconcilable
account move lines. As it uses an sql query for an efficient computation it
discerns stored records from new records (having a new id) by filtering out
records with a falsy id field (new ids are always falsy). It then proceeds the
computation for stored records only.
The bug arises when the compute method is called on records during an onchange
call, as the records get reassigned a new id as well. This can be seen when
opening the total due followup view and toggling the blocked field on any of
the unreconciled entries. The problem is resolved by including records during
an onchange in the computation: in practice the computation can simply be
carried out on all _origin records.
opw-3388389
closesodoo/odoo#131465
X-original-commit: 3d52fca2979cc4bfe87540122ea7cc979040be4f
Related: odoo/enterprise#45591
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Versions:
---------
- 14.0+
Steps to reproduce:
-------------------
1. Settings -> Configure document layout
2. Select the Boxed layout
3. Go to Invoices -> create a new invoice and register payment
4. Click on Preview
5. The field “Amount due” is in the wrong color and barely visible
Issue:
------
The field “Amount due” is in the wrong color and barely visible in
invoice boxed layout
Cause:
------
The issue is happening because we have `<strong>` before the text
”Amount due” and it changes the font color to gray because of the CSS definitions
Solution:
---------
We need to make the text bold in a different way, to do it we can use the bootstrap
class font-weight-bold, this way we keep it bold and do not break the colors
OPW-3374092
closesodoo/odoo#131459
X-original-commit: 6e1b3f2fc36831a94c164ab281c7a6fde535cebf
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
the default model 'useAction' service is now named 'action' no longer 'actionService'
Changed the reference where needed
closesodoo/odoo#131452
Related: odoo/enterprise#45583
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Improve Send & Print general usability by making it more streamlined overall.
Options are not activated but preemptive problematic partners are shown,
and skipped during the sending process.
closesodoo/odoo#131448
Task-id: 3336623
X-original-commit: 4105994e778459c869d885d017118492ffcd2064
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Before this PR a huge padding was present when editing a message
on the chatter. This commit fixes the issue.
task-3458670
closesodoo/odoo#131432
X-original-commit: 332942109b0db7a96da3bd2e7f2cafe19ebb1df3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit replaces notification.notify with notification.add so that
it works without the legacy notification service.
Steps to reproduce:
- go to website settings
- add a new website with any name
- follow the steps and upload an invalid file as the logo
fix for https://github.com/odoo/odoo/commit/caefcb8590301a0ebbe947a875003b33ce7d537a
task-3338012
closesodoo/odoo#131422
X-original-commit: 0d7971e0ed7eee5b5e983c27a13c6a34457f4505
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
As explained by ANV (https://github.com/odoo/odoo/pull/123237#pullrequestreview-1537263584), the override of _set_authorized method of payment.transaction model is currently dangerous and should be removed.
Indeed, he explains that any error in the _set_authorized method will remove the transaction from the database, even if it is successful.
According to him, the current safe approach is to only override _reconcile_after_done to catch successful transactions and process them safely.
closesodoo/odoo#131408
X-original-commit: b12f6df9e497fd0546c91f88f94f92dc5b606373
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The template `web_editor.assets_edit_html_field` was not used nor
required anymore. The files under that bundle were already included
in the backend.
The template under the key `cssEditAssetId` in html_field.js is in fact
loaded in wysiwyg_iframe.js through the option iframeCssAssets.
Moreover, the line `await getBundle` was doing nothing meaningful as
the bundle assets would not be loaded after being fetched.
task-3446819
closesodoo/odoo#131365
X-original-commit: 4eebfcbdf5428cd1c53bafcd89da7095964ff384
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Description of the issue/feature this PR addresses:
When an accountant adds an invoice at another date than the date of the
said invoice, it is that date that is shown on the journal entries and
items views. This makes it impossible to order the lines by invoice date
as the only date field available on those views does not give the proper
piece of information.
Current behavior before the PR:
Prior to this commit, the Journal Entries and Journal Items views show no
column giving the date of the document for every line but only for those
that have been added the same day.
Desired behavior after the PR is merged:
Adding this, the Journal Entries and Journal Items views show a "Document
Date" column which represent the date of the document. The bank
reconciliation widget presents this column too. In each of these three
locations, filters, groups and ordering have been setup to be able to be
applied on this new column.
This allows to search and filter lines using that piece of information.
The column is hidden by default.
task-3388309
closesodoo/odoo#129040
Related: odoo/enterprise#44545
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
The South African chart of accounts needed an update regarding its content
This PR updates the CoA to its newer version.
task-3391846
closesodoo/odoo#128700
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
On a putaway rule, the "Having Category" condition is not always
respected.
To reproduce the issue:
1. In Settings, enable:
- Storage Locations
- Storage Categories
2. Create a Storage Category SC:
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- L2 only:
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock
- Having Category: SC
5. Create one storable product
6. Update its on hand quantity:
- 1 product at L1
7. Create a planned receipt R for one product
8. Mark the receipt as Todo
9. Click on 'Set Quantities'
10. Open the detailed operations
Error: The destination location is L1. The putaway rule has been
applied without the storage category constraint: the destination
location should be L2
When applying the putaway rules, we first check if one of the
relevant locations already contains that product. And, if it's the
case, we use that location as destination location. However, we
don't filter out the locations without the correct storage category.
This explains why L1 is found and used.
OPW-3437174
closesodoo/odoo#131361
X-original-commit: 66c11acdbedf8d1bcae6deb8ec54c5da5a3ae16d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
As described in #129974, the colorpicker cannot cache a promise
protected by `useService`. #129974 fixes the issue by through non
idiomatic practice (calling a service that is not protected by
`useService`). This commit fixes the issue idiomatically.
This commit caches the promise directly from a service and removes the
caching code from the `ColorPalette`.
task-3446691
closesodoo/odoo#130789
X-original-commit: 1d2e54088b0f0e28464ab6aa884fb2e1110e8e04
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This error occurs when the user manually attempts to change the mimetype of the
attachment, and then the base function `_postprocess_contents` tries to
determine the type and subtype of the attachment.
Error: `ValueError: not enough values to unpack (expected 2, got 1)`
To address this issue, this commit introduces a check for the mimetype of the
attachment before attempting to determine its type and subtype.
sentry-4283372480
closesodoo/odoo#131333
X-original-commit: fade78ed98e6902ab5465e40d2b1bf7aa282688b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
The "test_active": False context of the field specifies that this field
will ignore whether a record is active or not when fetching it.
Due to recent changes in the javascript, the "test_active": False
context of the tax_ids field on the account move model is propagated
through into the name_search query. This means that inactive taxes
appear in the dropdown when selecting a tax.
This is an issue as there are a few localisations that hide a number of
their taxes by default (by making them "inactive").
The solution is to add the key, value pair "active_test":False to the
context of the field on the view, effectively overriding the context
that gets used in the name_search query, thus only retrieving active
taxes.
closesodoo/odoo#131212
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
*: website
Some specific media items are meant to be editable even though located
in non-editable environments. The typical case in 15.0 is the website
"Team" snippet: it is made of multiple bootstrap rows, each containing
a column with an image and a column with texts. The columns with the
image are only meant to hold that image, it was therefore marked as
non editable to prevent users adding text in there by mistake... but the
image is still meant to be editable. See [1], later fixed by [2].
The problem now is that the system that [2] had to use is quite messy:
the column is marked non editable thanks to the `o_not_editable` class
but the inner images were to be declared editable via some custom JS
method overrides (`_getContentEditableAreas`). The debate about if we
should keep a class-based system and/or a method-override system will be
left to master. This commit although comes with an uniformisation about
this, introducing a new class to declare "an editable media despite its
non editable environment". This is not a counter-part of the class
`o_not_editable`: we do not want the media to be marked with the
`contenteditable` attribute. Indeed, this is actually required since [2]
was not enough to solve the problem. See those steps:
- Add a company snippet in your page
- Change one of the images by an icon
- (Save / Reenter edit mode)
- Try to change the icon again / edit its options
=> You can't. Indeed [2] relied on the media being an image to re-enable
edition on it... but even if it did not, it would not have been enough.
Indeed, icons are forced to being `contenteditable="false"` by the new
editor library (since 15.0 then), last update on that at [3].
We thus needed a different way to differentiate editable media, hence
the introduction of the new `o_editable_media` class.
Note: this system is not perfect, but so is not the whole system about
determining what is editable or not at the moment. In this case, it may
exist cases of a media marked with the class to be editable but end up
in an environment which is not editable by force (xpath somewhere etc)
... and ends up being editable anyway. Most cases work though and at
worse it will be about a non editable image being editable but not
possible to save in very rare cases. As advertised, the whole system
about what is editable or not should be improved.
[1]: https://github.com/odoo/odoo/commit/30db617bc8ff7727f40d7ef58c6578e84a13f284
[2]: https://github.com/odoo/odoo/commit/61270ee8bffb6e85f8ff0d19c7a3889fdce2f486
[3]: https://github.com/odoo/odoo/commit/7646429e894f28f398b7b212e893822c06c7b03d
task-3226172
closesodoo/odoo#131139
X-original-commit: 436265e815684046a37a8b80e4cd520c2bd637f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Commit [1] refactored the event handler code in charge of handling
double click on media elements to edit them. A mistake was made making
the code consider inner elements of the media instead of the media as a
whole when clicking on it.
Steps to reproduce:
- Enter edit mode on the homepage
- Add a text-image snippet
- Change the image to a video (after dblclick on the image for instance)
- Try to change it back with a dblclick => it does nothing
[1]: https://github.com/odoo/odoo/commit/8ca115b3b9dfe87b59b6b064a4d85ea152d9214c
X-original-commit: 4b47ae0022a3e50d53dc02e399412585fc2131ef
Part-of: odoo/odoo#131139
Before this PR, when moving the snippet's position, `d-none` gets added
which should not.
With this PR, removing the `this.$target.addClass('d-none')` from
`cleanForSave` method as it was adding `d-none` unnecessarily while
moving snippets position. The fact is snippet will be hidden if the
current user has no access to the mail group. So that case will be
handled using controllers route `/group/is_member`, if this return email
of the user, snippet is visible else the user has no access to the mail
group so we remove the snippet.
task-3107451
closesodoo/odoo#131131
X-original-commit: 51e92d022d50a7a4adaca872d42849eeaf64f88d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Usecase to reproduce:
- Set operation time base on last workorder
- Create 2 MO
- On first MO, set 15min as duration
- On second MO, set 10min as duration
- Validate both MO at the same time
- The duraction expected on the operation could be now 10 or 15min
It happens because the search in the compute is only base on date.
And when both MO are validated at the same time, it's not enough
closesodoo/odoo#131307
X-original-commit: cad75ac78b61046352c39d3f3b7717cfbad42c8b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
PURPOSE
=======
Starting from 16.0 we introduced some reports to log skills history, skills evolution.
It means that the skill model is linked to another model, preventing us to delete it.
Usually, we use the message "link to x, archive it instead", but archiving a skill will only be possible from v17 (new task)
So, we need to be able to delete a skill on v16
closesodoo/odoo#131300
Taskid: 3456843
X-original-commit: d9672b55e7a596778fd542541f39e5216c06cb40
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This PR cleanup service typing:
* Introduce `addons/mail/tooling/type/services.d.ts` to automatically type
services imported by `useService` hook.
* Correctly type service constructor, setup and start functions.
* Remove now useless `@type`.
* Removing `Object.assign` for services variables.
* Type OdooEnv.services to services.
closesodoo/odoo#131192
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prerequisites -->
1) Login with a user with just Inventory/User access rights
2) Product A with purchase policy set to `on ordered quantities`
3) Product category of A set to `AVCO` costing method
Steps -->
1) Create+confirm a PO with product A and create and confirm vendor bill
2) Switch to Inventory/User user
3) Try to validate picking
4) Access right error
This occurs due to the fact that `Inventory/User` does not have access to s`tock.valuation.layer` or `account.move.line`.
Solution -->
Add sudo to the lines where accesses to SVL and invoice lines are made.
opw-3357028
closesodoo/odoo#130929
X-original-commit: 8d2a77d1bdbe8f865d8f7177801786617e10058f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
RATIONALE
We plan to move from a single alias-domain configuration to a multi company
enabled support for alias domains and aliases. First step to prepare this
change is to cleanup alias usage through various Odoo addons.
ALIAS USAGE CLEANUP
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
ALIAS MIXIN WITH OPTIONAL ALIAS_ID
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 this PR we 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.
ALIAS NAME SANITIZE
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.
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.
MISC
Lint / reorder code, prepare future changes. Add tests, notably for alias
name sanitize and management.
Provide various fixes, see sub commits for more details.
LINKS
After odoo/odoo#130768 and odoo/enterprise#45204 this is another preparation
for multi-company aliases (see odoo/odoo#76734 and odoo/enterprise#20983).
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#130632
Related: odoo/enterprise#45118
Related: odoo/upgrade#5012
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current usage of aliases in 'account.journal' model is a bit low-level and
is done by hand. This is notably due to some specific requirements for
accounting: batch install of journals with aliases with names holding
non-ascii characters, easy support of multi-company when creating aliases
with similar names, specific heuristic to generate alias name to be
understandable if sanitize / encoding leads to stripping lot of name parts.
Inherit from the 'mail.alias.mixin.optional' that automates management of
alias without requiring the "alias_id" field. It handles aliases like other
Odoo models, notably for security, readable / writable field, alias reset
or values synchronization. It allows to remove unwanted sudo().{write/unlink}
and have code more aligned with current standards.
Using this mixin allows to skip the inactive alias creation and instead keep
a void m2o. When having a lot of journals to create for some COA this helps
saving DB space and reduce number of inactive and useless aliases.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
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>
Louis Wicket (wil)