Modified the description of bank statement import in accounting settings. As it is now possible to import in xls and xlsx format and this feature has been adopted with the already existing module account_bank_statement_import_csv, the description to import CSV files has been improved to make the user understand that he is also able to import in xls and xlsx formats as well.
task-3086543
PR:107737
related PR (enterprise): #34700closesodoo/odoo#107737
Related: odoo/enterprise#34700
Signed-off-by: Laurent Smet <las@odoo.com>
Because of a faulty float comparison, additional taxes information would sometimes be uselessly displayed on invoices,
specifically when only one tax was applied.
Fixed said float comparison.
Modified usage of built-in 'round' since check_style doesn't allow this anymore.
closesodoo/odoo#109084
X-original-commit: 23a12c496cd7688b0021083bce2c84ce7ea2a3fb
Signed-off-by: Laurent Smet <las@odoo.com>
Partial revert of #109033
The global filters were removed in 16.0 because the pivot "9" does
not exists in this dashboard.
But it exists in master.
See #104125closesodoo/odoo#109099
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps:
- Install knowledge on a fresh db
- Install and set fr_BE language
- Open knowldge
- Traceback
The traceback occurs because `emoji_registry.js` fails to load `emoji_data.js`
because of some translated string that contains non-escaped characters for JSON
opw-3110823
closesodoo/odoo#109086
X-original-commit: 455b335ae773ae4c8f5197c2a6f517947e6a7009
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Rendering the clickable cells is not a negligeable operation.
And it happens at every rendering (every scroll operation).
Especially, detecting which functions the cell contains.
The slow operation is parsing formula.
On the "CRM Leads" dashboard, depending on the visible cells:
closesodoo/odoo#109085
Before: 10+ms (almost the full 16ms allowed to reach 60fps)
After: ~2-3ms
X-original-commit: f132145c941ca79960aa697d6e98e4ee5193150d
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, in the search view, it is not possible to filter the
employees to only have those ones who is a subordinate of the current
user. That is, if Pierre is the current employee/user and he is the
manager of Paul and Paul is the manager of Jacques. Pierre could want to
see his subordinates in his view of so Paul and Jacques instead of just
Paul.
This commit adds a new boolean field called `is_subordinate` in
`hr.employee` and `hr.employee.public` models. This field will be True
if the employee is a subordinate of the current user.
task-3061362
closesodoo/odoo#108060
Related: odoo/enterprise#34181
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, it was not possible to have two vimeo videos playing
at the same time on the same page.
Steps to reproduce the bug:
- Drop two blocks containing an image
- Replace the two images with vimeo videos
- For each of these videos, enable the autoplay feature
=> Only one of these videos is played automatically. When you play the
other one, the first one is paused and vice versa. It is impossible to
have both videos running at the same time. This commit allows to correct
this by allowing to play several vimeo videos at the same time when they
have the autoplay feature activated. Note that if the option is not
enabled, the behavior remains similar to before, only one video can be
played at a time.
opw-3107447
closesodoo/odoo#108945
X-original-commit: 9e9d8691826d5504f613f529ee998a22d1bf3888
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Since 2013 we have a kind of a URL hack that allows to redirect to the
initial URL after installing a lang through the website, see [1].
It was even tested in python unit test with [2] but sadly it was still
broken by a combination of [3] and [4] which actually broke it at the
javascript level: the python view was correctly still outputting the
correct URL and the python part was correctly handling that return URL
when passed, but the javascript was not actually passing the URL from
the view/href to the python side as the lang install wizard was now
called through JS instead of a normal backend URL redirect (since the
website frontend > backend imp at [4]).
Step to reproduce:
- Go to any page other than the homepage
- Click on footer > add a language
- Add a language
- You are redirected to the homepage always instead of the URL you came
from
Note that this is only true if done through the backend / iframe preview
as clicking on the "Add a language" from the frontend will work as it
should. Indeed, when clicking on it from the frontend, it's a simple
link redirect but when click in the iframe preview, the click is
preventend to let the JS open the action in the top window instead.
[1]: https://github.com/odoo/odoo/commit/5cfbcc3aff5a28022b397ec7a28ebaca6db43673
[2]: https://github.com/odoo/odoo/commit/269aa594111a152ad4b7714856ea745bfef57155
[3]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
[4]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#108869
X-original-commit: 05caf6e697461176326ee61beeccb1193472267c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The French localisation was written in french which was wrong, all the localisation have to be written in english and then translated back to the native language thanks to PO files.
Thanks to this PR, all the french localisation has been translated.
closesodoo/odoo#108816
Task-id: 3112366
Related: odoo/enterprise#35296
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, typing an emoji source in composer like
emoticon `:)`, it may not substitute to the corresponding emoji.
This happens because the emoji substitution requires loading
emoji data. It was only loaded when opening the emoji picker.
This commit fixes the issue by lazy loading emoji data when
focusing the composer.
closesodoo/odoo#109035
X-original-commit: 066e8029c0d66974c59bfe9e430affb4bf0604b9
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup, i.e. construct some
fake groups. It also populate those groups by assigning them some
previously created fake records. It turns out that those fake records did
not have the right type when the first group by is a date/datetime field.
The record values created (during the group assignation) for that field
were luxon.DateTime instances instead of strings like "2022-12-15".
This was the root cause of the following problem.
Have a kanban view in sample mode and grouped on a date field, then
switch to a pivot view grouped on the same date field. A crash occures.
That crash is linked to the above mentionned problem in the following
way:
- open the kanban view (with sample="1" in its arch)
- some existing groups are fetched by the relation model but no records
exist
- the kanban view switches to sample mode and some fake invalid records
are created in the sample server (the invalidity of records do not
cause visible problems at that time)
- switch to the pivot view
- the sample server is reused but existingGroups is set to be null, so
that _mockWebReadGroup uses the invalid records to create the groups
it needs. The crash occures at that step.
Forward-Port-Of:: cdd583f74f51086c8d5f243a2a761622229ccc26
closesodoo/odoo#109031
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup. It turns out that
this construction was invalid: the value returned for the first group by
in each group had the wrong type in many cases. For instance, when the
first group by is a date field, the value returned could be an array
with a luxon.Datetime instance as first element and a description as
second element while it should be a description only (e.g. "December 2022).
We fix that problem.
Forward-port-of: 59c7c8c9adcad468ad9d985113a2b88e745b7414
Part-of: odoo/odoo#109031
Steps to reproduce the issue
-Go to Document and create a spreadsheet document SD (for example Sales Commission)
-Display SD and notice that there is some data in it
-Add lang Czech and set it on your profile
-Display SD
Bug:
There is no data in SD
The issue arise because `read_group` values are already translated to
the user's language.
e.g. let's we group by `create_date:month`, in Czech, we get
`"create_date:month": "září 2022"` (september 2022).
The previous strategy to map the `read_group` result to the PIVOT functions[1]
was to let momentJS parse the result, then format it to the PIVOT function format.
However, we can't realistically assume momentJS can parse any date in any language.
About the adapted tests:
The tests were actually wrong because the mock server is also wrong.
The mock implementation of `read_group` returns days formatted as "2022-09-08" ("yyyy-MM-dd")
instead of "08 Sept 2022". Because the business code didn't expect this format,
it resulted with wrong values.
See odoo/odoo#105546
[1] PIVOT function argument is "09/2022" for september 2022
opw-3052858
closesodoo/odoo#109026
X-original-commit: efb59010e3029ff4d5c77c0b2402093c8df4c44e
Related: odoo/enterprise#35395
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Current behavior:
Partial and reversed payment were not taken into account for the
product margin calculation.
Steps to reproduce:
1. Create a product with an common avco setup.
2. Go to purchase 1 unit at 10 dollars.
3. Upon confirming the invoice your cost is updated in the product margin
report.
4. Create a partial payment on the bill. This creates issues as the
product margin report is looking for paid or open not partially
paid so it won't show up in the cost calculation.
5. Once the bill is fully paid then it shows up in the cost section
of the product margin report again as its payment status moves to
Paid.
6. Create a sales order for the unit at 100 dollars.
7. Invoice for the full amount then cancel it by creating a full credit
note to put the original invoice in reversed status. This will have
only the credit note show up in the turnover calculation as it is in
paid status while the original invoice doesn't have a paid or open
status so it isn't taken into account.
opw-2887240
closesodoo/odoo#108992
X-original-commit: ddca80ebee20f75ee9b9da2828de5a9170ea683e
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
An `IndexError` traceback that occurs in `hr_expense_predict_product/HrExpense:_onchange_predict_product` was caught by Sentry
This tuple index out of range happens because we are trying to access the first record of a recordset returned by `records.filtered()` without checking that it actually contains records.
since https://github.com/odoo/enterprise/pull/34994
opw-3111577
closesodoo/odoo#108720
Enterprise: https://github.com/odoo/enterprise/pull/35232
X-original-commit: 0a74cc1175377826a0adfb52ac68286b17630894
Related: odoo/enterprise#35245
Signed-off-by: Achraf <abz@odoo.com>
The chat icon in the form view was not properly aligned in the public
profile.
closesodoo/odoo#109029
X-original-commit: ef67c32af08494b9d20a47763d988c608e923f3b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, the modified test sometimes failed on runbot,
because it might happen that the hashchange event is triggered in
the next animation frame (the event isn't triggered synchronously).
This commit ensures that we wait for the hashchange event, and for
a nextTick before checking that the next action is in the DOM.
Fixes runbot issue 6946
closesodoo/odoo#109028
X-original-commit: 6aba445e2b4a1f6321cefb04fb07584df615dfa2
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps to reproduce:
- Install Odoo with demo data, multiple companies and multiple users
- Go to Documents app
- Finance workspace
- Select a demo pdf
- Create invoice
- Error because of 'Mail Compose Message Rule'
The fix removes a non-necessary line when creating an invoice from a pdf
closesodoo/odoo#109032
X-original-commit: e5b60e6af030374972b36cb3cb61a38109da78e7
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
before this commit, on clicking top reinvoiced orders section in the expense dashboard throws traveback saying invalid field analytic_account_id.
as analytic_account_id field is now replaced by analytic_distribution, removing the usage of analytic_account_id from json files.
closesodoo/odoo#109014
X-original-commit: baea94b9e7e5e5d120e11d454194fbfd70dee4ef
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
All the localization of syscohada was written in French instead of English.
To correct this, this PR changes the COA, tax group, tax template and char data and adds a French PO file to have all translations in the language used in those countries.
closesodoo/odoo#105187
Related: odoo/enterprise#33714
Signed-off-by: Laurent Smet <las@odoo.com>
*calendar,test_main_flows
This commit tries to unify the name of the create buttons in different
apps. "New" is used over "Create" to avoid confusion regarding its effect.
"Create" could be interpreted as we want the current record to create a new one.
But "New" implies that the user will land on an empty page that can be filled.
task id: 3074472
closesodoo/odoo#108439
Related: odoo/enterprise#35139
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
**Before this commit**
When a breadcrumb is restored, the props resId is overwritten by the
res_id of the action.
**After this commit**
The props resId is kept if it is defined.
closesodoo/odoo#108996
X-original-commit: 810a1d29bfa7c497627a37e0cec64df51b75bb4b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On scanning customer barcode, POS updates pricelist, but not fiscal position.
Fix it by using method `updatePricelist`, which both updates pricelist and
fiscal position.
STEPS:
-On a customer, define a fiscal position, a price list and a barcode
-Go to the POS, in settings, define that several price lists & fiscal positions are possible
-open a session and scan your customer.
opw-3102568
closesodoo/odoo#108968
X-original-commit: 9107dc8305699dc29d3c85d02c65d0f86ec03955
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
The function used to group fake records in _mockReadGroup was
overcomplicated. We simplify it.
closesodoo/odoo#108921
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Before this commit**
Calendar filters and gantt pills have almost same colors.
**After this commit**
Both calendar filters and gantt pills share standardized colors.
**Changes**
The SCSS variable "$o-colors-complete" has been merged with the calendar
variable "$o-filter_colors" (which has been removed).
This variable is only used by gantt and calendar views in the Odoo code.
The complete colors list now has 56 values instead of 30.
First color was replaced by "$o-colors-complete-first" but this is not
the case anymore ("$o-colors-complete-first" has now been removed).
Task id: 2518854
closesodoo/odoo#108597
Related: odoo/enterprise#35208
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Stock moves don't have a `partner_id` if they are created before setting
the picking's `partner_id`
Steps to reproduce (from v15):
1. Create a new transfer with operation type 'Delivery Orders'
2. Add a move, then a delivery address and save
3. Mark as todo and validate
4. Print the delivery slip
5. The warehouse address is printed but it should be the delivery
address
Solution:
Replace `onchange_partner_id` of `stock.picking` by a compute method in
`stock.move`. It assigns the partner_id of the `stock.move` to its
picking's partner_id if the move is part of the picking's
`move_ids_without_package` (in purchase_stock, also check that it is not
a dropshipping)
Problem:
When creating a picking, its moves' `partner_id` is only set if the
picking's `partner_id` was already set in the form
opw-3091139
closesodoo/odoo#107625
Signed-off-by: Tiffany Chang <tic@odoo.com>
after this commit: https://github.com/odoo/odoo/commit/8b91cab67f122667ecc250a8b016b152929c61e2 sales warning fields sale_warn and sale_warn_msg fields in the partner form is displayed always without respecting the option in sales settings.
the fields will be displayed always even if the feature is unticked in the settings.
after this commit, the fields will be shown only once the feature is activated in settings.
closesodoo/odoo#108987
X-original-commit: d247279c9e42469d0a120fa8d673fec69186c7e5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
remove non existing dashboard view type from action in dashboard json files.
closesodoo/odoo#108986
X-original-commit: cebe0eb3ff581fd2827ddc3e2329ed4bdcddc2b5
Related: odoo/enterprise#35365
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
action options
Steps to reproduce:
- Install Accounting
- Go to Accounting > Create New Invoice > Fill it and confirm.
- Reister a payment for the invoice.
- Click on the "i" icon next to the total (bottom right).
- And in the popup window click on "View"
Issue:
When we open the payment from the invoice, the dropdown action options
are not properly displayed, we cannot delete or duplicate the payment
until we refresh the page.
Solution:
We removed the context (which was setting some options to false) from
the action that is used to open the payment through that view.
opw-3092601
closesodoo/odoo#108963
X-original-commit: 7aa635fe74a8593379bc62466ea99af26eae3b52
Signed-off-by: William André (wan) <wan@odoo.com>
Problem:
In the UI, from the form view of a journal (`account.journal`), you can
set a bank account (`default_account_id`) which is not of the same type
as the journal.
In v15, it was not the case.
Cause:
Since refactor [1], the domain of
`default_account_id` has been changed in order to replace the
`user_type_id` conditions, but it seems like an unwanted '|' has been
left.
Solution:
Remove that pipe.
[1]: https://github.com/odoo/odoo/commit/26b2472f4977ccedbb0b5ed5f08be2c04313fd21closesodoo/odoo#108711
X-original-commit: ee7a4f9afee6cb4f359aea1759246c8c67fb75bf
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Arnaud-Sibille <arsi@odoo.com>
In Algeria, it is a legal requirement to write the total amount of an invoice in letters. The commit enables this feature. A futur feature will be available to enable a generic solution for all localizations.
task-3083537
PR number-107084
closesodoo/odoo#108353
X-original-commit: aefbd7d942f12ab32fed8331b9941d778b1c22a4
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
The geoip resolver was moved from http_routing to code/http.py in #86015
and is always available since then. The `_geoip_resolver` global
variable is a leftover we forgot to remove.
closesodoo/odoo#91337
Related: odoo/documentation#2151
Related: odoo/enterprise#27399
Signed-off-by: Julien Castiaux <juc@odoo.com>
request.geoip is no more a dictionnary cached in the session. It is now
a full blown object with lazy and smart geolocalisation capabilities.
Among other things, the previous dictionnary API is now deprecated. The
changes are:
* `request.geoip['country_name']` -> `request.geoip.country_name`
* `request.geoip['country_code']` -> `request.geoip.country_code`
* `request.geoip['city']` -> `request.geoip.city.name`
* `request.geoip['latitude']` -> `request.geoip.location.latitude`
* `request.geoip['longitude']` -> `request.geoip.location.longitude`
* `request.geoip['region']` -> `(request.geoip.subdivisions[0].iso_code if request.geoip.subdivisions else None)`
* `request.geoip['time_zone']` -> `request.geoip.location.time_zone`
It is safe to access all the attributes. Doing `request.geoip.city.name`
when the geolocalization failed (missing db, invalid address, ...)
evaluates to None. It does not raise an AttributeError.
Task: 2848206
Part-of: odoo/odoo#91337
Maxmind offers multiple ip-geolocalization databases, historically we
have been using the City database which contains records on a
city-basis. Many years later it turns out we are primary using geoip to
know the country of the user. Geolocalization in the City database is
considered slow by our standard and we have been clever in order not to
geolocate each request by saving the info in the session.
On the other hand, the Country database that is offered by Maxmind is
much more lightweight and geoip using that country is considered a fast
operation by our standard.
In this work we make Odoo compatible with both the City and the Country
databases. Using multiple database at the same time, we can be smart and
only query each of the two on-demand. If a user ask for its country,
we'll use the fast Country db. If a user ask for its city/timezone we'll
use the slower City db.
By default it loads both database from the `/usr/share/GeoIP/` folder,
respectively the files `GeoLite2-City.mmdb` and `GeoLite2-Country.mmdb`,
you can provide alternative paths using the `--geoip-city-db` and
`--geoip-country-db` CLI options.
In the same mindset as #86015, geoip is still lazy. It is done on-demand
and the result is cached on the current request. The different with the
related PR is that as we know consider geoip to be fast, we no longer
cache the result in the session.
Task: 2848206
Part-of: odoo/odoo#91337
Currently, when the partner phone has space, Razorpay throws an invalid phone exception error.
In this commit we sanitize the partner phone.
Case 1:
If partner phone is empty then validation error will be arrived. 'Phone number is required'.
Case 2:
If partner phone is not sanitized then validation error will be arrived. 'Incorrect phone number'.
EX: (+91 96385 44240) -> (+919638544240)
task-3113199
closesodoo/odoo#108969
X-original-commit: 38af5ee6a4feba802d50305fab8c001494f4e538
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit moves the tooltip from the parent element of the list
aggregate to the value itself to avoid having a tooltip that is
not connected to its intended target (here the tootlip's arrow does
not point at the value at all before this commit).
Task-3106190
closesodoo/odoo#108894
Related: odoo/enterprise#35351
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit the name field in spreadsheet.dashboard.group and spreadsheet.dashboard is not translatable, and it always appears in english in the dashboard.
after this commit, the name will be translatable and values will be shown in users language in the dashboard.
closesodoo/odoo#108972
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Starting from 1 January 2023, the Goods and Services Tax rate (GST) will
change and go from 7% to 8%
task-3098705
closesodoo/odoo#108964
X-original-commit: 9b039531bd0073f8abe1e6e949c2031615aa15a3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Simon Morais Da Cunha (smdc) <smdc@odoo.com>
Before this commit, the test "field matching is removed when filter is
deleted" failed on 2022 to 2033 year's transition.
Now a patch date is added to avoid the test to be time dependent.
closesodoo/odoo#108947
X-original-commit: 9d08a20d4c84c45799f766529d054b7df8fe0d66
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The mock server's mockReadGroup function would not properly compute the
range and domain of the returned groups for datetime fields with groupby
hour.
The year of the range/domain should be the same as the record and not
the current year.
Consider the following:
- a record with a datetime field of value "2016-12-14 12:34:56".
- a read_group with groupby "['datetime:hour']"
The corresponding group would have had the following metadata (considering current year is 2022):
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 12:00:00"], ["datetime", "<", "2022-12-14 13:00:00"]]`
- range: `{ from: "2022-12-14 12:00:00", to: "2022-12-14 13:00:00" }`
It now has the following valid metadata:
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2016-12-14 12:00:00"], ["datetime", "<", "2016-12-14 13:00:00"]]`
- range: `{ from: "2016-12-14 12:00:00", to: "2016-12-14 13:00:00" }`
X-original-commit: cca1fad650efc13cd1695acb723b9aa9a54ba184
Part-of: odoo/odoo#108947
Co-authored-by: Bruno Boi <boi@odoo.com>
hupo-odoo