Pillow 9.1 deprecates most if not all toplevel Image constants:
https://pillow.readthedocs.io/en/stable/releasenotes/9.1.0.html#constants
These constants have been moved to thematic enum classes (e.g. all the
resampling constants in `PIL.Image.Resampling`).
This triggers warnings in Odoo, and the removal delay is quite short
(slated for Pillow 10, release planned mid 2023). Pillow 9.1 is also
already in Debian Bookworm (current testing).
Fix by shimming at the import level: if the enums are available import
them into the local namespace, otherwise alias `PIL.Image` itself as
to the enum.
closesodoo/odoo#96799
X-original-commit: 7be04d31bad078681ef0a2919234c11840a2e8e2
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit:
On pasting image to editor, the default width was set to auto.
After this commit:
Now on pasting image to editor, the default width is set to 100%.
Task-2862892
closesodoo/odoo#96779
X-original-commit: 2e4811b751960548dc66f6e4ff00495e5226fdbc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: website_livechat
This commit is a step towards refactoring the JS of public livechat,
so that it reuses the same architecture as the code of Discuss.
This implies code that uses JS models and OWL components.
Task-2928837
closesodoo/odoo#96690
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This nomenclature was taken straight from the old Summernote options
when the new editor was merged in 15.0.
While perfectly correct from a technical point of view, the use of the
word "Auto" in this context is confusing because the user might think
that the system is going to choose an optimal size for them while this
is not what this option does at all. What it does is simply removing any
width style property that might be set on the image, thus letting the
image be sized appropriately by the browser in accordance with active
CSS rules at that position in the page, hence its "Default" width.
closesodoo/odoo#96679
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
It now uses the new owl code, instead of the legacy list view, which
will be removed in the future.
closesodoo/odoo#96595
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Show a help message in the "mail gateway allowed" list view that
explains why this model is useful and what the email limit is.
Remove the normalized email from the list view and rename the label of
the email field.
Task-2885455
closesodoo/odoo#96588
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Without this the payment line amount is overridden before the request
is made to Mercury.
When a Mercury payment method is clicked a payment line with the right
amount is created. When a card is swiped it types a sequence like:
%B999000090000009^TEST...
The "typed" numbers are immediately interpreted by NumberBuffer and
will result in the payment line amount being updated to something like
9990000.... When the "barcode" is finished credit_code_transaction()
in pos_mercury will do the request using the amount from the
payment line (swipe_pending_line.get_amount()).
As a result a request is made to Mercury with a huge amount which
results in an error: "Error 1000211: Invalid Field - Purchase Amount".
Luckily NumberBuffer already supports barcodes, so the problem can be
solved by setting useWithBarcode. A small method was extracted to
override this cleanly.
opw-2892608
closesodoo/odoo#96392
X-original-commit: 49df357a3b897bc06aa5978c4b77c4cfda29070c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
A field input always asks for a record update when it is the target of
a "change" event but such an event might occur after some keyboard
events (e.g. a "Enter"). In order to make keyboard navigation work, it
is necessary to make a dirty field communicate its new value before a
change event and make sure the record is correctly updated before being
saved.
Before this commit, this was done via a system based on a special event
triggered on the model each time a record is saved but that solution was
not appropriate:
- the updates done in that way were not correctly awaited.
- they would be asked for even if the save would not be the result of
a keyboard event.
Here we replace the old system by a simpler one that works. When some
specific keyboard events occur, a dirty field ask for an update that is
correctly awaited.
closesodoo/odoo#96101
Related: odoo/enterprise#29873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes most of the calls to checkValidity outside of the
(Basic)RelationalModel.
The validity checks in ListRenderer were not useful
because the operations done after them (like a switchMode) would make
a validitity check and the expected goal would be achieve in any case.
Part-of: odoo/odoo#96101
When rewriting the Form view, we wanted the keyboard navigation using
"tab" and "shift+tab" to use the native browser behaviour. The purpose
of this commit is to remove the custom behaviour of X2many in a
form view when a "tab" or "shift-tab" make it be focused.
Before this commit, a new empty line would be created automatically.
After this commit, the button "Add a line" takes focus but no new line
is created.
If one wants to add one, that can be done by pressing "Enter".
Part-of: odoo/odoo#96101
In this commit, we improve some tests by making them use the util
function "editInput". Indeed those tests were incorrectly reflecting
the edition of an input: normally, change the value of an input should
trigger an "input" event.
Part-of: odoo/odoo#96101
Before this commit, in an X2many in editable list mode with a handle
field, if you passed a record in edit mode, the handle field was focused.
The expected behaviour is to focus the first editable field.
Part-of: odoo/odoo#96101
Before this commit, in an X2many in editable list mode, creating two
valid records in succession by pressing Enter caused the first record
in the list to go into edit mode. The expected behavior is to add a new
empty line.
How to reproduce:
- Create a first valid record
- Press the enter key to validate it and a new line is created
- Complete this new line in a valid way
- Press the enter key to validate it
Result before the commit:
The first record switched to edit mode and there is no new empty line.
Result after this commit:
A new blank line is created in edit mode.
If you press enter again the empty line is validated and a new line is
created.
Part-of: odoo/odoo#96101
Before this commit, in an x2many in list mode, it was possible to switch
several records to edit mode.
Normally, it is not possible to have more than one record in edit mode
in a list mode X2many.
How to reproduce:
- Have an X2many with at least two record already.
- Modify a field of the first line and make it invalid
- Click on the second record
Result before the commit:
Both records will be in edit mode.
Result after the commit:
The invalid record stays in edit mode and the other record stays in
readonly mode.
Part-of: odoo/odoo#96101
When you are eon the details form of partner in POS UI, you have a
button 'More Info' that redirect you to the backend partner form. This
button is always displayed and can lead to a traceback if you are
clikcing on it while creating a new partner.
To avoid such issues, we are only display the button when we are
editing existing partners
closesodoo/odoo#92967
Signed-off-by: Masereel Pierre <pim@odoo.com>
In the customer list, the partner email and phone number are displayed,
but if the partner has a mobile number, it is not displayed and also not
editable in the details.
We have added the possibility to register the mobile number directly
from POS interface, and we display it in the list of partners if it set.
Task-id: 2817067
Part-of: odoo/odoo#92967
Steps to reproduce:
- Install Studio, Contacts, l10n_in
- Go to Contacts, open studio on the form view
- Edit the GST Treatment field name
-> No changes are made
Cause of the issue:
When combinings views to generate the final arch, extensions are
ordered by priority. Studio edits have a priority of 99 but in this
case, there is an override with a priority of 100.
opw-2899654
closesodoo/odoo#96713
X-original-commit: b97daa993347acd763c080eb8f5f4157a3359ab8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce:
- Install accounting module
- Ensure there is 2 companies
- Activate both companies (with company switcher)
- Go to Accounting -> Configuration -> Currencies
- Select currency `EUR`
- Add a rate and set second company as company
- Disable second company (with company switcher)
- Click on `Show Currency Rates` in action menu
- Click on create
Issue:
Access Error
Cause:
Currency Rate model have a compute field `rate`.
This last one calls `_get_latest_rate` that will retrieve the last
rate for the currency. To do so, it will first retrieve all rates for
the currency (that might include rates with company not same as the
current one) before fitering regarding company.
Solution:
Use sudo(). Same issue/fix for `_get_last_rates_for_companies`.
opw-2832708
closesodoo/odoo#96714
X-original-commit: dda5c9084b9913968e67c8b280de870c81227e16
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Impacted versions:
- 15.0
Problem A) Date not showing at proforma at newly opened orders.
Steps to reproduce:
1) Enter Point of Sale module
2) Configure a PoS as a Bar/Restauran with Bill Printing before payment (with or without Floor and Tables).
3) Start a new session in the configured PoS.
4) If Floors and Tables is configured, select a Table. Otherwise skip
this step.
5) Add some products to the order.
6) Push the Bill Button.
7) A bill ticket will appear at screen.
Current behavior:
In the bottom part of the bill the date is not showing at its place
between Order Reference and PRO FORMA text.
Expected behavior:
Date should be shown after Order Reference at the PRO FORMA bill.
Problem B) Date showed at proforma with different timezone (more/less
hours).
Steps to reproduce:
1-5) Same steps as Problem A) but Floor and Tables configuration must be
active.
6) Push the top green button to return to Tables screen (or wait one
minute).
7) Return to the same Table with recently created order.
8) Puss the Bill Button.
9) A bill ticket will appear at screen.
Current behavior:
The date in the bottom part of the PRO FORMA ticket is showing a time
with a different timezone (with more or less hours). Besides, the time
printing correspond to the time where the order was saved, not the
current time of printing the bill.
Expected behavior:
Date must show the correct time accordingly to the actual timezone and
to the moment of printing the PRO FORMA bill.
Video/Screenshot link (optional):
https://youtu.be/-2Td-RjhR9Uclosesodoo/odoo#96776
X-original-commit: 0ca6e48b3662432dfb128ed8d6625cd598ca5e32
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In the `write` method, accessing the `ms_organizer_event_id` field of
`self` leads to an exception if `self` represents several records.
So, the idea of this fix is to set the `need_sync_m` field of all modified
records to `True` when at least a field to sync with Outlook is modified
(see `_get_microsoft_synced_fields()`) and then, at the end of the `write`
method, really patch or delete records that are already linked to Outlook
(that means they already have their `ms_organizer_event_id` field set).
closesodoo/odoo#96761
X-original-commit: 1a66343327f9ea9f59ba25ea63e26331cabb65b5
Signed-off-by: Arnaud Joset <arj@odoo.com>
Previously, attempting to add a class to a button box would crash
because the button box divs are compiled to ButtonBox component which
did not accept a class prop. This commit fixes that.
closesodoo/odoo#96726
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: im_livechat, snailmail_account, survey, web_editor.
The callback registered by the bus service method onNotification was
not the same unregistered by offNotification. Since those method were
superfluous, they have been removed in favor of (add/remove)EventListener.
closesodoo/odoo#96684
Related: odoo/enterprise#29819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Auto retry can be usefull to avoid breaking a build because of a
small tour or query count, but for long tests like qunit, this can be
painfull when a real error is triggered.
This commit proposes to disable autoretry on demand for some tests
to solve this issue.
This may be applied on all tests longer than a few seconds.
closesodoo/odoo#95440
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When using the wizard to add a bank account, it should be added to
an existing journal only if the journal has no bank account set
and no journal entries.
We also want to be able to remove a set bank account.
When using the wizard to add a bank account (Create it button ;
not Connect button), it should be added to an existing journal
only if the journal has no bank account set and no journal entries.
We remove an unwanted constraint on the bank journals that
prevented the removal of an Account Number (IBAN).
Some UX changes. In the Journal Items list view, specific views
open depending on their move type. This commit also changes
the "View" button of the invoice payment widget on the Journal Entry's
form view in order to align behaviours.
The core open_move method is also moved from the account move line
model to the account move's one for more flexibility.
The "1 Statement" button of the payment's form view now links to the
new reconciliation widget.
The Journal Items lists accessed from the Journal report now show
the partner by default.
The "Unreconciled" filter now filter out partial reconciliations which
have a residual amount != 0.
The Partner column should almost always be shown by default in a
Journal Items list view.
task-2893208
closesodoo/odoo#94923
Related: odoo/enterprise#29092
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In some case, users use custom `address_format` with keys that do not
exists. This lead to errors in odoo and upgrade process. Avoid
`KeyError` by using defaultdict with `str` value.
upg-361146
upg-361241
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 457, in load_modules
force, status, report, loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 349, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 227, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
migrate(self.cr, installed_version)
File "/tmp/tmp1bew9m7l/migrations/website/14.0.1.0/post-adapt-footer-data.py", line 69, in migrate
address = html_escape(partner._display_address(without_company=True))
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 950, in _display_address
return address_format % args
KeyError: 'town_name'
```
closesodoo/odoo#96703
X-original-commit: 81bf1d2101202a4a6cb832004500129905c2d3be
Signed-off-by: Christophe Simonis <chs@odoo.com>
The top popup, by default, confirm/cancel when Enter/Esc key is
pressed. This behaviour should be ignored when the focus is in
text input fields.
closesodoo/odoo#96769
X-original-commit: 29b34ff8d6ee368add91f58cc4db9533d2779a77
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When a user exports a picking with the option 'import-compatible', he
won't be able to import the record later.
To reproduce the issue:
(Need stock. Use demo data)
1. Inventory > Operations > Transfers
2. Select a transfer (without opening it)
3. Action > Export:
- Enable the option "import-compatible"
- Add the field "Operation Type"
- Export the transfer
4. Back to the transfers list view, click on Import
5. Load the exported file and click on Test
Error: An error message is displayed ("No matching record [...] in field
'Operation Type'"). However, the option "import-compatible" was enabled
and the operation does exist, so the record should be found.
When exporting a record, if one of the selected fields is a relational
one, we use its `display_name` as value:
https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L883-L886
Then, when importing, we use `name_search` to retreive the record:
https://github.com/odoo/odoo/blob/662ecf4e20ceab92b62804cb2a06e51f6b897623/odoo/addons/base/models/ir_fields.py#L406
Back in the use case: if an operation type has a warehouse, its display
name will be the combination of the warehouse name and its name:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L146-L151
However, the `_name_search` does not handle this type of search key:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L157-L164
Therefore, using that value ("Warehouse: Operation name") in this
`name_search` will not work.
According to the review from odoo/odoo#95526, such a model is considered
as broken: "if the display name (`name_get`) is overridden, then the
`name_search` should be overridden to match". Moreover, the generic
solution proposed in the previous PR would not work in case of
multi-warehouses.
OPW-2739786
closesodoo/odoo#96768
X-original-commit: 456784ca98b3e3bc30c40b1cffe46574930ae492
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Since [1] the back button did not navigate within the steps of the
website configurator anymore.
After this commit the window location change that happens within the
browser is copied back into the state - thus causing a redraw of the
correct configurator step.
Steps to reproduce:
- Create a new website
- Go to second step
- Press browser's Back button
=> Did not navigate to previous configurator step.
[1]: https://github.com/odoo/odoo/commit/56cc3dfab156f21c7ef97b3c407f1480b094fe93
task-2789075
closesodoo/odoo#96766
X-original-commit: d32f8a9d64f0487e1e61ec7cee7cffde21b8ddb2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Also includes a fix that properly opens the pos ui when clicking
the button (link) "Click here to close the session".
closesodoo/odoo#96765
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
When canceling a transfer, all its moves and move lines having qty done
(if any) are canceled as well. But this doesn't happen on package levels
having such move lines with qty done filled, the state was set to
'confirmed' while all its move lines are 'cancel', which was not
consistent.
closesodoo/odoo#96764
X-original-commit: d9b16c3732c7e935c21a0396bb01ed4f19456827
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
New styles on forms had broken the full height / no sheet style of
note's form view.
closesodoo/odoo#96741
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Due to the new form and list views some of the customisation of loyalty
were not working properly anymore.
This commit adapts the js customisation inside of loyalty to wowl 2.
TaskId-2929488
closesodoo/odoo#96731
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Create an accrual plan and an allocation request such as described
in the added test and validate the allocation request
- Run the scheduled action for accrual plan computation
- Check the number of allocated days
Expected behavior:
The first level should bring 6 days, the second 3 days and the last
1 day for a total of 10 days
Current behavior:
The 3 level give non integer values closed to the expected for a
total of 9,... days.
Explanation:
When transiting between two levels the nextcall was the last day
of the current level to have the right level, this creates an
inconsistency as the end_date of the _process_accrual_plan_level
level should go up to the first day of the next level to have the
full number of days expected. To solve the issue we change the
level selection so that if the date is the first day of the
level it is still in the previous level. We also modify the places
where the nextcall was modified when transiting level so that there
is no more one day delta anymore.
opw-2868297
closesodoo/odoo#96665
X-original-commit: 5d055130c97c5d8367c2b71fc617f588c5e15741
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When displaying the price of a shipping method, if its type is "Fixed
Price", the option "Tax-Included" is not considered.
To reproduce the issue:
(Use demo data)
1. In Settings:
- Product Prices: Tax-Included
2. Create two shipping methods:
- SM01:
- Provider: Fixed Price
- Set a customer tax of 15% on the associated delivery product
- Fixed Price: 100
- Published: True
- SM02:
- Provider: Based on Rules
- Set a customer tax of 15% on the associated delivery product
- Pricing:
- If weight >= 0: Cost = 100 + 0 * weight
- Published: True
3. Open the eShop
4. Add the Customizable Desk to the cart
5. Process checkout
Error: When displaying the delivery methods, the price of SM01 is
incorrect: $100 instead of $115. In other words: the tax is not in the
price, as it should according to the settings. (The price of SM02 is
correct: $115).
The displaying of the shipping method price depends on the shipping
method type:
https://github.com/odoo/odoo/blob/68b08164e5de353ea0c48de92d0c0e028b49bc52/addons/website_sale_delivery/views/website_sale_delivery_templates.xml#L35-L46
If the type is `fixed`, we display the `fixed_price` field of the record
(that is the value encoded on the shipping method form, so it does not
include any tax)
If the type is different, we just display a text: "Select to compute
delivery rate". And, when loading the page, a JS widget gets and
displays the rate for each shipping method (including SM01!)
https://github.com/odoo/odoo/blob/204a2bb5553a275e785fbb9ccefbe26b06ef4ba1/addons/website_sale_delivery/static/src/js/website_sale_delivery.js#L38-L47
And in that case, the rate returned by the RPC includes the tax (if
needed):
https://github.com/odoo/odoo/blob/bc2615d8ab5135f21c488c5a260c59605b0da498/addons/website_sale_delivery/controllers/main.py#L57-L60
That is the reason why the displayed price of SM02 is correct.
When the widget gets the prices, it uses the classes to find and replace
the rate with the one returned by the server:
https://github.com/odoo/odoo/blob/204a2bb5553a275e785fbb9ccefbe26b06ef4ba1/addons/website_sale_delivery/static/src/js/website_sale_delivery.js#L95-L105
However, if the shipping method type is `fixed`, it does not have the
class `o_wsale_delivery_badge_price`, so the SM is not found and its
type is not updated (that explains why the displayed price of SM01 is
not correct).
Because the widget gets the rate of all shipping methods, we should take
advantage of that and let the widget apply the result on each method,
even if the type is `fixed`
OPW-2854341
closesodoo/odoo#96657
X-original-commit: ba210fe1dbcfe3026e6f34b94a5defd2fb4cd15d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
_description of the `hr.payroll.structure.type` should be "Salary
Structure Type" instead of "Contract Type"
closesodoo/odoo#96653
X-original-commit: 49ecc72b2971edc57f85d4bea50901021b4f3f7b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since odoo/odoo@2dd37982e6 , Kanban
column's width is flex based. But sadly two types of columns were not
adapted properly:
- Kanban small column didn't reduce the column width
- Quick create kanban column shrinked too much
This commit fixes both these issues by properly setting the flex-basis
size for one and disabling shrinking for the other.
closesodoo/odoo#96650
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When navigating backward to step 2, the website purpose is reset in
order for the navigation to not automatically advance to step 3.
Because of this, when navigating to further steps with the browser's
forward button, that field remains empty. This ultimately produces
an error when the configurator state is extracted to generate the
website.
After this commit the former selected purpose is kept when no purpose
is selected anymore. It is then used when collecting the configurator
details if there is no selected purpose.
task-2789075
closesodoo/odoo#96640
X-original-commit: d874958aa44c0bd96ab7b84f7066c9b8d28642d6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With the conversion of views to the new webclient, the o_xxl_formview
class was no longer applied as expected, which broke the layout and the
width calculation in embedded list views (as the chatter would take up
more space than intended during the width computation). This commit
fixes that by adding the class when needed.
This commit also moves the css rules relative to that class which are
mainly used for the side-chatter, from enterprise to community, as the
side chatter has been made available in community as well.
closesodoo/odoo#96627
Enterprise: odoo/enterprise#29803
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As the `color-contrast` function provided by BS5 basically fulfill the
same need as the custom `o-get-most-contrast` function and the later one
isn't used, we can safely remove the custom one.
closesodoo/odoo#96626
Note: last (and only) usage was in mrp_workorder's tablet view.
Related: odoo/enterprise#29802
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps to reproduce:
- Create a leave request for multiple employees
- Go in the employee list
Current behavior:
The leave request is not visible in the list view
Expected behavior:
The leave request is visible in the list view
Explanation:
Previously a domain on the list view restricted the
records to the one that had an employee_id with the
right company but this condition was never met by the
the multi_employee leaves as they have no employee_id.
To solve the issue we add to the domain a condition to
accept multi_domain employee that have the right state
and the right company.
opw-2917291
closesodoo/odoo#96625
X-original-commit: f1c7c3737d3420a1356fd8e24d7970edcdb571c6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose: Allow users to make product 'expense available'
(or the opposite, unset them as expense products) by making the
field 'can_be_Expensed' available in the base product view.
task - 2909067
closesodoo/odoo#96619
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit refactors the way we handle the "<>" case in domain
evaluation, for the sake of consistency with the "==" case. Indeed,
we tried to avoid using JSON.stringify as it could have an unwanted
behavior (e.g. it could crash, or it could have been overridden on
the value we manipulate).
closesodoo/odoo#96614
Signed-off-by: Géry Debongnie <ged@odoo.com>
By enabling the method '_employee_values_sync' the original behavior is
keep. Furthermore, by overriding the method now is possible to decide
either a field is synced or not into employee.
closesodoo/odoo#96609
X-original-commit: 46c12cc0f72b2a6aba907fe903a255aed61a1695
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since the revamp of the Kanban View in mobile and the migration of the
Settings view to the OWL views, the jQuery.touchSwipe library is not
used anymore.
closesodoo/odoo#96608
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- A user has accounting permission but no employee permission, when that user creates a payment in spending it gives an error that does not have access to the bank_account_id field
- This commit allows the user to read the bank_account_id field when creating a payment
closesodoo/odoo#96607
X-original-commit: 8045780cbf2dc36d533dbfd3315bab31a229351d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Xavier Morel