As we will move those from other localizations to base,
we add those for Mongolia to base already.
closesodoo/odoo#34281
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A special folder named `0.0.0` can contain scripts that are run on
upgrade of any version.
They are useful to make some sanity checks or other verifications to
ensure database consistency.
The first version of this patch used the more eye-catching `any` for
the migration folder, but it was problematic for upgrading from an older
version that doesn't contain this patch.
Using a version "number" containing two dots is required to avoid it
being prefixed with the server version (see `convert_version` method) and
resulting in a version like `10.0.any`.
Such version would have been executed, even without this patch, when
upgrading from an older major server version (9.0.1.0 < 10.0.any).
closesodoo/odoo#34268
Signed-off-by: Christophe Simonis <chs@odoo.com>
- Create 2 included taxes: 21 % and 6 %
- Create a product A with 21 % as default tax
- Create a fiscal position to map the tax 21 % to tax 6 %
- Allow the fiscal position in the POS
- Add product in a POS order
- Apply the fiscal position
The subtotal is not recomputed correctly. On the other hand, if the
fiscal is first set then the product added, there is no problem.
This is because the `fix_tax_included_price` is only called by
`add_product` and not when changing the fiscal position.
opw-2020755
closesodoo/odoo#34260
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).
1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).
Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.
2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.
closesodoo/odoo#34243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the No Change status wasn't properly set because
the `filehash` wasn't passed to `_binary_set_headers` and because
the status was not changed to 304 if it was already set to 200 earlier.
This commit fixes this issue and also prevents images to be processed
in `content_image` if the status is 304.
opw-2008426
closesodoo/odoo#34032
Signed-off-by: Christophe Simonis <chs@odoo.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
closesodoo/odoo#34284
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
For some strange reasons, the e-learning ranks are created in data but
the demo data override their motivational message fields.
Unfortunately, the demo data were ok but the normal data had broken
images in them.
closesodoo/odoo#34282
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The new editor of https://github.com/odoo/odoo/pull/29775 came with a
fullscreen option. When using the toggle when the editor is in inside
a modal, the editor stretched only to match the size of the modal
instead of the viewport.
This is because the 'position: fixed' rule which is used to achieve the
fullscreen layout cannot work if a parent of the element has a CSS
transform applied on it. Indeed in that case, that element acts like the
viewport for 'position: fixed' elements.
closesodoo/odoo#34272
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* Setup an IoTBox connected to a receipt printer
* In POS Config:
- IoT Box: check "IoTBox", set the IP of the Box and check "Receipt Printer"
- Pricing: Select "Tax-Included Price"
* Start the POS, select any product
* Click on "Disc" on the virutal keyboard on the bottom left of the POS
* Enter the amount of the discount
* Validatate payment (Click "Payment" > "Cash" > Enter Amount > "Validate")
* A ticket should print on the receipt printer:
- The price in the rigth column is correct
Current behaviour:
* In the left column, it shows : Product name, Base price, Discount: X%, 1 x Price --> This price is not correct, it shows the price with the discount applied twice.
Expected behaviour:
* Discount applied once everywhere on ticket.
task-1978564
closesodoo/odoo#34278
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, if a user select option 'tax-Included Price' in pricing
from pos.config and sale product with a discount, it is first displaying
price without tax instead of the price including tax.
Task-2002464
Closes#33733closesodoo/odoo#34259
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following the new editor at https://github.com/odoo/odoo/pull/29775,
the html field to edit the mass mailing popups in the backend appeared
entirely broken.
This was because the editor css was not loaded for that field.
closesodoo/odoo#34250
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When computing `is_absent` for multiple employees
(multiple records in `self`), if one employee is really absent
(leave), all employee in the recordset are also considered
absent.
Note: it never happens in saas-12.2 but in master
and possibly custo.
closesodoo/odoo#34241
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Before, a portal user who tried to share a slide by mail got
a Odoo Server Error. He will now be able to share it without
any error.
closesodoo/odoo#34320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, using google geoloc, we only provide a string as address
withtout more information.
Now by defaut, we force the country as components:
https://developers.google.com/maps/documentation/geocoding/intro#geocoding
Related to task-2030886
**setup:**
```python
url = "https://maps.googleapis.com/maps/api/geocode/json"
```
**before:**
```python
params = {'address': 'Georgia', 'key': apikey}
requests.get(url, params).json()
```
> ==> Return coordinate of "Georgia, United States"
> What is completely wrong
>
**after:**
```python
params = {'address': 'Georgia', 'components':'country:Georgia', 'key': apikey}
requests.get(url, params).json()
```
> ==> Return Nothing
> What is strange but less wrong than US
>
```python
params = {'address': 'Belgium', 'components':'country:Belgium', 'key': apikey}
requests.get(url, params).json()
```
> ==> Return coordinate of Belgium
closesodoo/odoo#34582
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, 50% of the time, the design of the editor in the
website appeared broken. This was because the two editor assets (the
web_editor one and the website one) are lazy loaded... but their load
order was not deterministic. The bug was introduced with the new editor
merged with https://github.com/odoo/odoo/pull/29775.
In fact the lazy loading system introduced by the `loadLibs` function
of the ajax module was designed to allow sequential and/or parallel
loading of JS files... but not of assets bundles (for CSS it is always
forced to parallel because only the DOM order matters anyway). This
commit shares the code to allow sequential and/or parallel loading of
assets bundles. It also forces the asset bundle resources to be loaded
after css and js resources.
closesodoo/odoo#34544
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since changes made on 'product.product' model in rev: 30e4d89a62
the domain is not represented as a string, but as a function, and that
leads to error as the javascript function is sent to the server instead
of a string representing a domain.
So we check the type of domain to see if we have to evaluate a function
or send the domain as a string
closesodoo/odoo#34453
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This fix correctly displayed motivational of next rank to achieve depending
on current karma. Indeed description_motivational field is not the
motivational to reach next rank but to reach the current rank, taken from
previous rank point of view. That way a given rank is configured by modifying
only 1 data.
When not having any karma points (newly created user) the next rank is computed
as being the first available rank. Motivational phrases and badges are updated
accordingly. This commit partially reverts 489c8623e2.
Result
* new user with no karma: next rank is the first rank;
* user with karma and next rank: as currently;
* user being at final rank: next rank is just current rank with a 100%
circle;
Linked to task 2005840
Related to PR #34220
Contains some small fixes
* correctly order leaderboard by descending karma, not creation date;
* top 3 users displayed in footer banner should be published, otherwise
displayed images do not match the top 3 displayed in the page displayed
when clicking;
* correctly say Leaderboard is an overall leaderboard, not only limited
to the current week;
Linked to task 2005840
Related to PR #34220
As user is a loop variable we can directly use its index instead of a rank
position that is not always correctly computed when not being logged due
to access rights issues.
Linked to task 2005840
Related to PR #34220
After this commit https://github.com/odoo/odoo/commit/ff870099c588e56 some of the events are left
in website_forum, that caused some buttons to be inactive. In order to fix that
events moved to website_profile.
Note: code is moved as it is. Cleaning class / namespace will be done in master
to avoid issues due to stable version.
Related to task 2006045
closesodoo/odoo#34138
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fix added in 3a0f05f334 doesn't work if an already existing user in company A
trys to modify his address on a website linked to company B. The form will try to change the company_id
of the res.partner which will then conflit with the company_id of the associated res.user, ultimately leading
to a UserError and a 500 error on the website.
opw-2025457
closesodoo/odoo#34262
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Commit 6b14ceb225 introduced a smarter way to find the default
journal based on the currency. However, it missed the fallback if no
journal is found.
opw-2009934
opw-2024204
opw-2011321
closesodoo/odoo#34263
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Such move lines can be created by POS, when closing a session. Because of commit https://github.com/odoo/odoo/commit/d3453f7d152d486cb5df01b4e40dbde57f59b49e , the cash basis entries are now created *after* reconciling everything (and not during reconciliation anymore). This causes multiple lines of the move created for the sessions to be reconciled together in case a refund was made (partial or not).
Solves ticket 2008085
closesodoo/odoo#34237
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Steps to reproduce the bug:
- Create an hr.leave.allocation with mode = 'By Employee Tag'
- Select Employee Tag = 'Employee'
- Set all the other required values
- Log with Demo User(Marc Demo)
- Go to Leaves > My Leaves > New Request
Bug:
An access right error was raised due to the record rule: "Allocations: employee: read own"
With this record rule the user can only read the hr.leave.allocation linked to his employee's user.
But with allocations in mode 'By Employee Tag', in the function get_days it tried to compute
the 'number_of_hours_display' of all the allocations linked to the current employee's user and
in the function _compute_number_of_hours_display, it also computes the parent_id of these allocations.
As the parent_id is not linked to the employee's user, it raised an access right error.
opw:2006686
closesodoo/odoo#34236
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The months name in momentjs used an arabic translation with the month
then some crap (or the month said a second time) after.
This does not seem expected, and has been solved in moment.js library 2
years ago:
https://github.com/moment/moment/pull/4271
This PR apply this change in moment.js localization included in Odoo.
opw-2006265
closes#34248
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
There is no guaranty that both the request body and the response body
will contain JSON data. This fix corrects the logging by printing the
raw text in case of json decode error.
opw-2006561
opw-2024242
closesodoo/odoo#34221
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Christophe Simonis