Steps:
Enable recurrence feature.
Go to Project > Office Design > Customer Review.
Enable recurrence on this task > Change month to year.
Issue:
Crash.
Cause:
`_get_next_recurring_dates` is called without a `repeat_month` arg.
Is is supposed to be a string which is going to be found in MONTHS keys.
Except it is False and so it is not in the list.
Fix:
If we don't receive it, deduce it from `date_start` arg.
closesodoo/odoo#112506
X-original-commit: 566c4904129dc7e81458871656d9b20b19b36246
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
Changing the expected payment date for an invoice with several installments is unclear, as there's no clear indication of what is expected when, except in the aged report.
This commit:
- Changes the default label of journal items if there is a payment term that splits it into several installments. Each journal item will now have "installment #<number>" appended to it.
- The installment label is added on all types of moves.
task-3137957
closesodoo/odoo#110955
Related: odoo/enterprise#36266
Signed-off-by: William André (wan) <wan@odoo.com>
Following this PR odoo/odoo#97398 website_slides module was forgotten
This commit add 'sanitize_overridable' parameter to the html_content
field. This will allow one to use the embed snippet in an article
type slide.
Task-3134690
closesodoo/odoo#112534
X-original-commit: 627833e77eb8f7ef7850f1fdeeb115ee8870c7f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this PR, all this localisation was written in Spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#112160
Task-id: 3166093
Related: odoo/enterprise#36801
Signed-off-by: William André (wan) <wan@odoo.com>
Version 16.0 removed the price different account following this pull request #99411
This decision has been made because it was only used anymore by standard cost method and real time valuation.
We thought that standard was not a valid accounting method and we didn't want to maintain code for it.
But:
- Standard could be valid if you manualy complete the accounting entries
by yourself (e.g. employees/machines cost in mrp).
- It's also valid if you record the difference between standard price and
vendo price (price diff)
If you want to have an estimation of your cogs (benefits and loss) during an
accounting period. People just do a manual correction at the end but they have
a real time reporting on the situation.
It's a too big regression to be acceptable. We apologize and reintroduce it for
16.0 and future version.
This PR reintroduce the fields in purchase and the fix module in 16.0 is
not needed anymore.
closesodoo/odoo#109924
Related: odoo/upgrade#4315
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Adds a new picking type code, 'dropship', and adds a new action/menu
item to display only the dropshipping's operations.
task-3076044
closesodoo/odoo#109511
Related: odoo/enterprise#35613
Related: odoo/upgrade#4252
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In the Inventory's Configuration, the option to enable expiration dates
depends of the activation of lot and serial numbers.
But if the user disables the tracking and the expirations dates were
enabled, they still are.
Also, if the module `product_expiry` is installed directly, the tracking
numbers aren't enabled alongside.
To fix that, this commit modifies the `res.config.settings` onchange
`_onchange_group_stock_production_lot` to disable automatically
expiration dates when tracking is disabled, and this commit also adds a
hook in the `product_expiry` init to enable tracking numbers at the
installation.
Part-of: odoo/odoo#109511
Now, the button "Update Quantity" and the stat button "Qty. On Hand" on
the product's form view will both call `action_update_quantity_on_hand`,
which who can call `action_open_quants` is an advance option is enable
(multilocation, owner or package) or if the product is tracked by lot or
serial numbers.
Also, displays the product's UoM in the `stock.change.product.qty`
wizard and changes its style so labels have more space.
task-3076044
Part-of: odoo/odoo#109511
Makes the `product.packaging` `product_id` required in the model instead
of the view only, since a packaging is supposed to always be relative to
a product.
Edits some views to add the default product in the context and makes the
field readonly if there is no `product_id` (that way, the user can't
no more create packaging without product).
Also, removes the domain in the action to display the packaging list
view so the user can see if there are some packagings without product
and can eventually delete them.
task-3076044
Part-of: odoo/odoo#109511
In `_check_backorder`, changes the condition so it checks if the qty
done is enough compared to the actual reserved quantity (instead of the
demand).
Also, removes an unused bloack of code and makes minor visual changes.
task-3076044
Part-of: odoo/odoo#109511
In the inventory menu, the "Operations" menu has now three sub items:
- Transfers
- Adjustments
- Procurement
All the existing `menuitem` go now under one of these sections.
Also, for the old transfers menu itme, this commit replaces it by three
other menu items: "Receipts", "Deliveries" and "Internal Transfers".
Each of them will display only the transfers with the matching picking's
type (depending of the picking type's code).
When a picking is created from there, its picking type will be set by
default according to it and the field will be filtered by its code.
When `mrp` is installed, adds a menu item for the manufacturing
operations in "Transfers" submenu too.
task-3076044
Part-of: odoo/odoo#109511
- The `picking_type_id` field in the pickings form view is not openable;
- Display the `description` field (optional) in the SVL list view;
- Add the `expiration_date` field (optional) in the quant list views;
- Add a description text for the landed cost;
- Renames field `requisition_id`: "Purchase Agreement" > "Blanket Order"
- In Inventory Adjustment, hides the "Apply All" button is at least one
record is selected;
- In `product_expiry`, renames two views to stick to the XML's coding
guidelines: https://www.odoo.com/documentation/16.0/contributing/development/coding_guidelines.html#xml-ids-and-naming
- For the replenishment:
- Places the field `product_id` as the first option when the user
writes something in the searchbar;
- Renames `route_id`: "Preferred Route" > "Route";
- Renames the button "Automate Orders" into "Automate";
- Set the `route_id` field as "optional=hide" until `mrp_purchase` is
installed (in this case, it will be set as "optional=show") because
in this case, there is at least two routes (Buy and Manufacturing).
task-3076044
Part-of: odoo/odoo#109511
- Places the buttons added in `stock` before the "Print Labels" button,
that way, the "Update Quantity" button is always the first button;
- Adds some depends on compute's methods, so that way it displays the
"On Hand" and the "Forecasted" stat buttons, and the weight and volume
UOM even if the product is new and the record wasn't saved yet;
- Adds the "Update Quantity" button in the product's forecasted report
and removes useless attributes of the "Replenishment" button;
task-3076044
Part-of: odoo/odoo#109511
Taxes field is not defined in the pos.order model, so, if you call
the onchange you get the next error:
```
File "/home/odoo/instance/odoo/addons/point_of_sale/models/pos_order.py", line 1159, in _onchange_amount_line_all
line.update(res)
File "/home/odoo/instance/odoo/odoo/models.py", line 5520, in update
self[name] = value
File "/home/odoo/instance/odoo/odoo/models.py", line 5860, in __setitem__
return self._fields[key].__set__(self, value)
KeyError: 'taxes'
```
closesodoo/odoo#112524
X-original-commit: af35c97866fdb271881b7d2b007a3d79f41a910a
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The function `_sync_dynamic_line`, which is called everytime we edit a
`account.move` or a `account.move.line` is tracking the values before
and after something changed.
Some part of that process was computed in `O(n^2)` where `n` is the
number of `account.move.line` related to the records; this commit is
making it `O(n)`, like the function is supposed to be.
Even though, these are light operations (no database queries, all in
memory), they obviously start to matter at a certain point.
The time to populate `account.move` (using the `populate` command) goes
from 224ms to 170ms per record (1000 moves with ~10 lines per move)
closesodoo/odoo#112522
X-original-commit: 99d2b818238b848125ec6696185ff1fca53d24cf
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit: In some cases where some events won't sync to
Odoo properly you got the "Unable to use a closed cursor." error. The
problem is that `_from_google_ids` function returns a recordset, and the
underlying cursor may be closed.
Steps to reproduce the issue:
1. Create user_A and user_B in Odoo
2. Sync user_A and user_B with Google calendar
3. Create an event with user_B on the Google calendar
4. Run the "Google Calendar: synchronization" cron
5. Change the created event's owner to user_A on the Google calendar
6. Run the "Google Calendar: synchronization" cron
=> You will get this error on the log, and the event won't sync:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 99
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/fields.py", line 1061, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(99,).google_id'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 91, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 70, in _sync_google_calendar
synced_events = self.env['calendar.event']._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 147, in _sync_google2odoo
existing = google_events.exists(self.env)
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 180, in exists
events.odoo_ids(env)
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 88, in odoo_ids
found = self._load_odoo_ids_from_db(env, model)
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 111, in _load_odoo_ids_from_db
mapping = {e.google_id: e.id for e in odoo_events} # {google_id: odoo_id}
File "/home/odoo/src/odoo/addons/google_calendar/utils/google_event.py", line 111, in <dictcomp>
mapping = {e.google_id: e.id for e in odoo_events} # {google_id: odoo_id}
File "/home/odoo/src/odoo/odoo/fields.py", line 1087, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/odoo/models.py", line 3276, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/addons/calendar/models/calendar_event.py", line 436, in _read
super()._read(fields)
File "/home/odoo/src/odoo/odoo/models.py", line 3343, in _read
cr.execute(query_str, params + [sub_ids])
File "<decorator-gen-20>", line 2, in execute
File "/home/odoo/src/odoo/odoo/sql_db.py", line 89, in check
raise psycopg2.OperationalError('Unable to use a closed cursor.')
```
The solution is to use ormcache on a function that returns the ids of the
events.
opw-3098799
closesodoo/odoo#112517
X-original-commit: 831e2e916541a95a1b932d9f58b3592ecee0c685
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Bug
===
When an error occurs, the error received is wrongly stringified.
closesodoo/odoo#112504
X-original-commit: b0641c5e85bf9d2e2c64ba548f7243e0a4196602
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Bug
===
When we remove some mail messages, we invalidate the cache of the
related documents. But in the same loop we call _invalidate_documents
which invalidate the cache, and so at the next iteration we will need
to make a new SQL query to know if the message is a "thread message".
So because of the prefetch ids, and because we invalidate in the loop,
if we unlink 1000 message, we will make 1000 SQL queries to fetch the
fields values of the 1000 messages.
Note that the unlink method will invalidate the entire cache anyway,
so unlike the write / create methods, we shouldn't need to invalidate
manually the related documents.
Task-3171093
closesodoo/odoo#112494
X-original-commit: f8958e9bbd4c7c37f614b20f7ed4d4825d438362
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The `member_values` argument of `action_add_member` is no
longer used in any call of `action_add_member`. We can therefore
remove it in standard, as it's completely unused.
Besides, after grepping the code for all calls to `action_add_member`
to check `member_values` was indeed unused, I saw this method
wasn't used by any views or Javascript code, but only
through Python routes, and therefore it can be converted
to a private method by prefixing it with `_`,
as our guidelines states to make private methods which are not used
by the web client.
closesodoo/odoo#111908
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Currently, it is possible to assign the same "Cash" payment method to multiple PoS.
At the moment, when creating a new PoS, Odoo tends to assign it by default. Although this is highly not recommended as it can only lead to incorrect cash control (two PoS devices rarely share the same till and therefore needs their own cash payment method).
This commit makes sure payment methods of type Cash aren't set by default when creating new PoS.
it also blocks the user from setting the same Cash payment method to multiple PoS configs.
closesodoo/odoo#92664
Task-id: 2857417
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The previous code had a lot of repetition and made use of deprecated
features such as useListener. This commit refactors the resize logic by
creating a simple ResizeHandle component that encapsulates the drag
handle logic, it then communicates delta in x and y to the EditableTable
which applies it to the correct side and adds constraints on the
coordinates.
It also slightly improves the UX for round tables by also giving them
"corner" drag handles, which let you resize two dimensions at once
instead of just one, this also makes the code more uniform between the
table types, the only difference being where we position the drag
handles so that they're visible.
closesodoo/odoo#112430
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps to reproduce the bug:
- Enable “Storage location” option
- Create a storable product “P1”
- Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock/shelf1
- product: P1
- Go to operation types -> “Receipts orders”
- Enable “Show Detailed operations” and
“Pre-fill detailed operations”
- Create a purchase order:
- Add 2unit of “P1”
- Confirm the PO
- Go to the receipt:
- the destination location is correctly set “WH/stock/shelf1”
- set the qty done to 1
- validate the delivery and create a back order
Problem:
The destination location is “WH/Stock” instead of “WH/stock/shelf1”
because the ```_apply_putaway_strategy``` function is not called on
the ```stock.move.line``` when there is no package
opw-3162934
closesodoo/odoo#112400
X-original-commit: b4c83ab2b202702e096c775ae73f4646ba93eae4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The filter can be assigned in the history directly with its
"id". No need to copy the object
closesodoo/odoo#112309
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Remove custom open introduced by bpo-26789 as we do not need it.
closesodoo/odoo#112453
X-original-commit: 8eaac9744b93e7132827edb2a59c28bb43732ec1
Related: odoo/enterprise#36978
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
__Description of the issue:__
When something goes wrong while downloading a report file, a 500 error
is sent as JSON. However the frontend interprets this response as HTML
and then try to parse the text content as JSON.
Most of the time this works, but if the response contains any HTML tags,
like `<lambda>` from a Python stacktrace, the JSON response will get
misinterpreted as HTML instead of regular text, causing the subsequent
JSON interpretation to fail.
The end result for the user is that empty tracebacks will be displayed
instead of User Errors or actual tracebacks.
__Desired behavior:__
The JSON response is HTML escaped before being sent and will therefore
be correctly parsed and displayed to the user.
This basically restore what was done prior of #104594.
Enterprise: odoo/enterprise#36523
X-original-commit: 5999a7d336553053c5638f69344cdfbc84a8c681
Part-of: odoo/odoo#112453
To reproduce
============
- create a vendor Bill
- add the PDF (from ticket attached files) in chatter
- go back to list view and select the bill -> print Original Bills
a traceback is raised
Problem
=======
for some excptional PDF files (like the one attached in the ticket),
the library PyPDF2 that we use to manage PDF files crashes.
Solution
========
a [fix](https://github.com/odoo/odoo/commit/e55196375aa124558b87ebd50012d5664295ca07) was backported from 16 and updated
so that we don't block the flow, we let a message on chatter that there was an error and we ignore adding the banner.
opw-3141143
closesodoo/odoo#112467
X-original-commit: d73a6261b9c7de41a1de6a2cd888c131ecee023b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Since website was moved from frontend to backend in 16.0 with [1], there
was an issue with the page list view which would not show the homepage
record when multi website group was not enabled.
Indeed, we have our own `recordFilter` method which is based on the
`website_id` field.
But the framework ignore this field (it doesn't read the property at all
and so don't have access to its value) if it's hidden by a `groups`
property. In such cases, the field should be duplicated and hidden with
`invisible`, as those fields will have their value retrieved depsite
being hidden.
Step to reproduce:
- Install website with no demo data (to have only one website)
Or go to runbot / install website with demo data and disable the multi
website group
- Go to Website > Site > Pages
- You don't see the homepage in the list, because there is 2 homepage
(one specific and one generic) but since the website_id is not fetch,
both are considered generic (which is not supposed to be possible)
and the filter is then considering those to be shadowed by the other,
ultimately filtering out both.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#112461
X-original-commit: 5ff5daee518d23c3b6958133eb1f99bc5fc1063f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
An exchange journal entry must not be reset to draft manually. It's done by odoo itself automatically when breaking an existing reconciliation.
closesodoo/odoo#112472
X-original-commit: ad9d53c8976ed78f3f6fdd65795c582d533de436
Related: odoo/enterprise#36999
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Benchmark:
A batch of 1000 payments and a move of 1000 lines to reconcile each payment separately.
Current observed time: +-288s
Improvement:
Adds some context keys when creating the account.full.reconcile to avoid the recomputation of dynamic lines (invoices), synchronization of payments/statement lines and check if the move is well balanced.
=> +-288s => +-34s
X-original-commit: 17c039788365065830dd9d7d2559fcb11f77606c
Part-of: odoo/odoo#112472
This commit fixes the case where portal_customer is not added in the
recipients group by the portal mixin.
Steps to reproduce:
- Go on a purchase
- Log a note and tag a user who handles notification by email
- Traceback:
```
File "/home/odoo/src/odoo/addons/purchase/models/purchase.py",
line 346, in _notify_get_recipients_groups
customer_portal_group = next(group for group in groups if group[0] == 'portal_customer')
StopIteration
```
Current Behavior:
- Traceback StopIteration
Expected Behavior:
- Log a note with the tagged (boomer) user.
See odoo/odoo@f879cf2867closesodoo/odoo#112465
X-original-commit: 7b9dd53a5573141275d41436189c782bccb96c3d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if hr_expense module was installed it was
impossible to configure alias_domain in the settings, the change
wasn't taken into account. This was due to the presence of the
field at two separate place and one of them having the readonly
parameter set.
This commit fix this issue that was introduced by :
5eca7b7378
Task-3127163
closesodoo/odoo#112443
X-original-commit: fc1c20cb5ce471b65120ec3eff7abd18ffd3a9fb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, late close events were not handled properly. This
could have led to non-reconnecting websockets. The problematic scheme
is the following:
- Close the socket (eg. upon the reception of an `offline` event), let's assume that
the other end will not perform the closing handshake, the connection will be
closed once the browser presumes it is dead.
- Create a new socket (eg. upon the reception of an `online` event)
- The browser assumes the connection is dead and dispatches a `close` event,
the worker switches to the `reconnecting` state and expects an `open` event to
update its state to connected. Since there is already a running socket, the worker
won't open a new one and will never receive the `open` event.
- Server closes the connection (eg. `KEEP_ALIVE_TIMEOUT`)
- The close handler is called but since it is in the `reconnecting` state, it assumes
it shouldn't do anything thus, no reconnect attempt is made.
This PR fixed this issue by ignoring events linked to outdated sockets.
closesodoo/odoo#112456
X-original-commit: a2454739156d8742f7606f090126f32735fb15df
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The goal of this commit is to convert the last legacy client actions from
/hr_attendance to owl.
Client actions:
hr_attendance_greeting_message
hr_attendance_kiosk_confirm
hr_attendance_kiosk_mode
hr_attendance_my_attendances
closesodoo/odoo#110095
Taskid: 3138068
Related: odoo/enterprise#35884
Related: odoo/upgrade#4296
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Tansifex is deprecating it's client and switches to a go-based
solution in its API v3
The new client is still backward compatible with the old format but
the v2 API is going to be phased out.
See https://github.com/transifex/cli to install the deplyments using
the tx client
This PR is the result of the "tx migrate" command
closesodoo/odoo#112402
Transifex: adapt to new URL format
X-original-commit: 7ca55aec4f1faa8bc2ad80d730a7f0771df3998e
Related: odoo/documentation#3534
Related: odoo/enterprise#36950
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
1/ The mexican DIOT report is now a tax report.
This in order to enjoy more Reportalypse' features (less menuitems,
tax_tags engine). The export functinality will remain in enterprise
version.
2/ Add missing tax "RET IVA RESICO 1.25%" tax.
3/ Add migration script for taxes.
As a new tax (RET 1.25%) has been added and the DIOT refactoring updated
many invoice_repartition_line_ids and refund_repartition_line_ids with
tags, the migration script will be run on module update.
task-id: 2925736
[community](https://github.com/odoo/odoo/pull/109300)
[enterprise](https://github.com/odoo/enterprise/pull/35515)
closesodoo/odoo#109300
Related: odoo/upgrade#4224
Related: odoo/enterprise#35515
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
after #111448, the structure of text field is changed. The Translate Button css
hack for ir.ui.view's form view doesn't work.
1. enable the multiple languages
2. go to the form view of a ir.ui.view record
3. the EN button for the view disappears
This commit fixes the bug by adapting the css to the new structure
closesodoo/odoo#112420
X-original-commit: 4dc94998f295b32567472d87bcf7e44af621e4c2
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Steps to reproduce:
- Create a parent analytic plan with no analytic account
- Create a subplan for this analytic plan with no analytic account.
- Create a subplan for the above subplan and create an analytic account for this subplan.
- create an invoice and try to put the created analytic account
Issue:
The analytic account is not availble (nor the subplan, nor the root
plan are displayed)
Cause:
We only fetch root plans (plans without parent_id) that have an
analytic account set. In this cas, the root plan is not retrieved
since the account_id is defined on the sub-sub-sub plan and not on the subplan nor the direct child of the root plan.
Solution:
Fetch all plans that have account_ids set and append the root plan to the relevant plans
opw-3107652
closesodoo/odoo#112419
X-original-commit: d725c74336feb27bd02e0f05491b24cb51627374
Signed-off-by: William André (wan) <wan@odoo.com>
This commit changes the event snippet tag option which was
misconfigured. Using the option fakem2m is indeed the way
to go to filter the events based on the given tags.
This commit also changes the way the domain works with tags:
tags from the same category will apply an OR condition
between them and tags from a different category will apply
an AND condition.
Task-3105126
closesodoo/odoo#109538
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In werkzeug 2.2.2, the following characters "$!'()*+,;" are now
considered as safe by url_quote. This makes the filename_secure test
fail with the hard coded expected string containing a single quote as
'%27'.
This commit adapt the filename_secure test in order to work with all
versions of werkzeug.
closesodoo/odoo#112298
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The path matching logic got reimplemented in werkzeug 2.2[^1] and the
new router is no more compatible with regexp groups[^2]. Our custom
converter for slugged-records in urls (`'/partner/agrolait-5'` => `5`)
has been adapted to match the route using non-capturing groups. It still
extracts the slug/id pair using the groups-capturing regexp.
[^1]: https://github.com/pallets/werkzeug/pull/2433
[^2]: https://github.com/pallets/werkzeug/pull/2519
Part-of: odoo/odoo#112298
Since Werkzeug 2.1.0, the Response.autocorrect_location_header is
disabled by default.
As it's RFC compliant and supported by browsers, the base_url is simply
removed from the assertions.
Part-of: odoo/odoo#112298
Archiving an allocation creates bad behaviour
in the use of the time off application.
For example, an employee who has several allocations some of which are archived
in the same period will create a problem in the counting of remaining days off.
Steps to reproduce:
- for an employee;
- create a 5 days type A allocation with a validity from 01/01/2023 to 31/01/2023;
- create a 5 days type A allocation with validity from 01/01/2023;
- archive the first allowance;
- set time off for this employee in this period.
Issue:
The employee's days off are not deducted until he has taken at least 5 days off.
Cause:
The process of deciding which allocation to use first will depend
on whether it has an end date or not.
It will therefore use the allocation with an end date first
(in our case the archived one).
Solution:
Archived allocations cannot be ignored by removing them
from the calculation process, as they have a use.
The solution that respects the business flow is to prevent archiving
for allocations that are not in a draft or refuse state.
opw-2991368
closesodoo/odoo#112401
X-original-commit: 199bd4acebfc905595ddf0525b4f69e38c336853
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Following up on the gst increment from 1 January 2023, some more changes:
- Change the default taxes on to Sales Tax 8% SR for sales and Purchase Tax 8% TX8 for Purchase
- Changing tax grid for Purchase Tax 8% TXCA
2963811
closesodoo/odoo#110611
X-original-commit: e6bab21dcf2e467fe8a79d1ef82e2cab87d4790c
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
After this commit, the user will be able to clone a question
inside a survey, the cloned question will have the same sequence
as the original and thus will be displayed just below it.
This commit also remove the is_conditional icon on the overall
questions tree view and the misplaced warning which was
previously introduced in commit [1].
[1] : b1d1856245
Task-3088848
closesodoo/odoo#112385
X-original-commit: bdcc2e6c4bec23c200a3fa2a2b4dd1bb06943f39
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Audric Onockx (auon)