This commits makes the TagsList component able to display icons as well
as images were previously supported. A test has been added to verify the
presence of the icon set in each tag.
closesodoo/odoo#117751
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: project
This commit adds test to this component and removes unused props. Since commit (1),
it is now considered as a core component. Those props have been removed from the
props declaration, to better match the real usage of the component.
Since the className props was not present:
- The o_kanban_tag class given in theory were not set in practice. The rules
corresponding to that class were already adapted to fix the display of tags in the
kanban view. It was possible to get rid of the references to the o_kanban_tag class.
- The o_field_property_tag_readonly class was also missing, and the logic to prevent
the click on tags was duplicated in the onTagClick function. This makes the class
useless. I removed mentions to this classname. Instead, each tag has the pe-none class
using the same condition, but set in the tag declaration.
(1): 129fa3f150
Part-of: odoo/odoo#117751
steps:
project > kanban card > task analysis > list view of report
cause:
trying to open a project from the list view
issue:
looking for __count in read_group
fix:
add no_open to project_id in the list view because we can open a project from
kanban card and configuration
task-3111378
closesodoo/odoo#117773
X-original-commit: aa051ccf9566cb0eb74d6357de7f069165349e48
Related: odoo/enterprise#39360
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
By checking the script checking if all the account supposed to be in the BS are.
The account 1380 of skr03 and the account 9090 of skr04 seems to be miss
configured.
For the first account, we went back to task 31826 when the account was added.
And we think that the account 1380 was indeed misconfigured. For the other,
by comparing with skr03 which has the same account, we can see that the type
of the account is wrong.
Also, the balance sheet works with tags. Some accounts added after the load of
the chart template were missing some tags. By overriding those methods,
we can add tags afterward and be sure that those account are present in the
Balance sheet.
closesodoo/odoo#117881
Task-id: 3041738
X-original-commit: 44e8295b2df5db73efa7a85003332c092fbfca7b
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
When generating invoice for PoS orders, if a cash rounding is applied,
a cash rounding line is generated. Thus it is not possible to have
`rounding_applied` and NOT `rounding_line`.
closesodoo/odoo#114122
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
PaymentScreenTotalDueWithOverPayment result to random runbot error because the
test is performing a series of steps that clicks the validate button which will
randomly result to going to the ReceiptScreen which is not the goal of the test.
In this commit, we replace the use of `pay` method with a more granular series
of steps to make sure that the test doesn't click the validate button and will
properly make the succeeding checks on the amounts in the PaymentScreen.
closesodoo/odoo#117844
X-original-commit: d51fa82d1fa9e154b9f9d57a5532e8c5fe48e33d
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer
have a relative positionning. As a result, most elements having an absolute
position and placed relatively to those elements will be incorrectly placed.
In website_event, the badges of the event cards are currently placed on
the upper border of the card because they are now placed relatively to
the whole card instead of the card body container having a `col-*` class.
As a result, the badges isn't where it should be and get cropped by the
container.
Steps to reproduce the issue:
1. Create a new event
2. Set a template
3. Go to the /event page
4. Click on the edit button from the Odoo navbar to edit the page (editor)
5. Go to the "Customize" page
6. Click on the "Templates" toggle button
To fix that issue, we will add a `position-relative` class on the card
body container having the `col-*` class. This ensure that the badge will
be placed as before between the card body and the card image.
task-3251110
closesodoo/odoo#117872
X-original-commit: 08f98194c095c541bf24d8ba55b440b189fd0766
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Issue:
With the "Extra Step During Checkout" setting,
it is possible to click on the "Configure Form" button
which should redirect us to the form in order to edit it.
However, we will always be redirected to the first website
(even if we have modified it in the settings).
Furthermore, if we don't have a cart in progress,
we will be redirected to the shop.
Solution:
Add a parameter specifying that it is for editing.
In this way, we can modify the form without having to create a cart.
Due to a technical limitation (reloading settings after saving),
we will always be redirected to the first website.
But it is possible to change the website (with the website editor)
and modify the second website if necessary.
opw-3245772
closesodoo/odoo#117870
X-original-commit: a3169ede4f609b56c83da04756d20b1c7a07251f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce:
- Install website_mass_mailing
- Go to the frontend and activate the editor.
- Add a newsletter block, change it to subscription form.
Issue: The name of the newsletter is displaying also the number of
subscribers (e.g. "Newsletter (1)").
Solution: Change the name we are using to display the newsletter name to
use the `name` and not the `display_name`.
opw-3145571
closesodoo/odoo#117846
X-original-commit: 3930df6c06197b70a019caa4d6782453095a7c66
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behaviour:
When creating a timesheet, if in the vals passed the AAL doesn't
have a company (possible since it's not required), then the `uom`
of the timesheet is False, which doesn't make sense.
Expected behaviour:
The timesheet `uom` should fallback on the uom of the company
of the project.
Steps to reproduce:
- Install hr_timesheet, Accounting
- Activate the AAL in the settings
- Create a project with an AAL
- Remove the company on the AAL of the project
- In that project create a task and log some timesheet.
- `uom` field should be empty
Reason for the problem:
When setting the `product_uom_id` in the vals when creating/writing
a timesheet, we just take the `project_time_mode_id` on the company
linked to the AAL. The problem is that the company on an AAL is not
a required field, so it can be `False`, leading the setting the val
for `product_uom_id` to `False`.
Fix:
In case the AAL has no company, we get the `uom` from the company
linked to the project.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3245671
closesodoo/odoo#117834
X-original-commit: 4cce77bd0288eeb3326ba57e91ef11d436f8a0ce
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
This commit fixes the components destructuration for the
AttendeeCalendarYearRenderer extends.
closesodoo/odoo#117845
X-original-commit: 340e9c2416537fc2e46a914e6038e5233dd876b6
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The analytic distribution json field may contain a deleted analytic account.
This causes 2 issues:
- When retrieving plans - the analytic account ids are used to force additional plans (maybe applied by a model) - causing a record does not exist error
- Opening and closing the popup is required to 'clean' the distribution. this is not ideal as a draft invoice will not display the deleted account, but it is still in the json.
With this fix, the analytic accounts existence is checked, and the distribution json is saved without the deleted account.
closesodoo/odoo#117835
X-original-commit: ce5045d4ba5633790dfce1ef44c10b5770432829
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit: if there wasn't any mail group, and you add a
"Discussion Group" component to the website it will raise an error. The
problem is that the `'website.prompt` wasn't loaded.
The solution is to add the `website.xml` file path to
`web.assets_backend` in the website manifest.
opw-3184203
closesodoo/odoo#117824
X-original-commit: feed4ba6f0e904911de419a94998e22a2033f9f7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When only Invoicing app is installed, trying to switch from a CoA with
reconcile model result in the following error:
You are not allowed to delete 'Preset to create journal entries during a invoices and payments matching' (account.reconcile.model) records.
This operation is allowed for the following groups:
- Technical/Show Full Accounting Features
Contact your administrator to request access if necessary.
As we already checked that user doing that operation is an admin., we
do remove the preceding CoA a superuser (like it was done precedingly
in saas~16.1).
To reproduce:
- Install a database without demo data and choose "Germany" as country
- Install "Invoicing" app
* this automatically install SKR 03 chart of account *
- Go to Settings / Invoicing, switch chart template to SKR 04 and Save
* raise the error above *
closesodoo/odoo#117788
X-original-commit: 87af732ba99b0fd79a98aa0c0c09ca1f737f9955
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
The purpose of this commit is to return meaningful responses when
validating steps and leave the caller to decide what to do with them.
We also introduce a public action enabling the validation of a step
from its xmlid and handle the different cases including the missing
step.
Note: these features are currently used in appointment (See Ent PR).
Additionally, returning the newly validated `onboarding_steps` from
`onboarding_step.action_set_just_done` makes more sense than returning
the `onboarding_progress_steps` records.
Tests are updated to make sure of this.
Task-3074112
closesodoo/odoo#114572
Related: odoo/enterprise#37870
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Remove an option used by the phone widget in the res_user view.
task - 3246848
closesodoo/odoo#117805
X-original-commit: a998437ed465f1a2a0aaee3651472ff8c58ba067
Related: odoo/enterprise#39387
Signed-off-by: Kevin Baptiste <kba@odoo.com>
English term changed in source. Dutch and French via Transifex.
task-3193776
closesodoo/odoo#117789
X-original-commit: 8225fcfe0de231788952ec4c9f6d0eabdc387aa5
Related: odoo/enterprise#39372
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Before this commit, in large database, openning a sale.order can take 3s.
Because in module sale_purchase_stock, _get_purchase_order use a On2many field : stock_move_ids, with inverse field group_id.
Now it takes 200 ms.
closesodoo/odoo#117738
X-original-commit: 5fc448e7f6dcce94fb89b23be29c4d38a525dd97
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When we use a 12 hour time format (without the `%p`), the time set is
always in the morning regardless of the period used (AM or PM).
Using `preparse` and `postformat` in the locale to change the symbols
used for numbers prevents the user from changing the date in the
datepicker because the date will be unparsable
Steps to reproduce:
1. Install Calendar
2. Go to Settings > Translations > Languages and open 'English (US)'
3. Set the time format to `%I:%M:%S`
4. Open Calendar and create a new meeting in the morning
5. Edit the meeting, set the time period to 'PM' and save
6. The time of the meeting doesn't change
Solution:
Get the time from the event passed when we close the bootstrap
DateTimePicker and convert it to luxon.
The period displayed when we open the datepicker is always 'AM'. This is
a limitation with the bootstrap DateTimePicker that uses the value from
the element[^1] (which is already formatted with the 12 hour format,
without the period info). Hence, the time is always in the morning
Problem:
The value of the element is used to set the date but this value is
already formatted with the 12 hour format (without the period info) so
it's always in the morning
opw-3150033
opw-3233229
[^1]:https://github.com/odoo/odoo/blob/16.0/addons/web/static/lib/tempusdominus/tempusdominus.js#L395closesodoo/odoo#117781
X-original-commit: dc195613ecff17d6aadc6e6ad8ab6da3670eb85a
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
When opening the Time Off App, the JS performs an rpc to call
hr_leave_type.get_days_all_request. Inside this method there are
some __get__ on non-stored computed fields. This triggers
a recomputation of said fields in _compute_leaves. _compute_leaves
uses _get_employees_days_per_allocation.
When there is an hr.leave.type with request_unit = 'hour', you may
get lots of validated allocations by employee. When this is the case,
_get_employees_days_per_allocation gets quite slow, especially the last
part about 'Future available leaves'.
This commit optimizes this part of _get_employees_days_per_allocation.
In this part the allocations are grouped by employees
and Intervals instances are of the form (start, stop, records). This means
that for a given employee_id, all the records of one Intervals will have
the same start and stop values. This allows us to move the call to
_get_work_days_data_batch outside of the
for future_allocation_interval in future_allocation_intervals._items loop.
Because _get_work_days_data_batch is quite expansive, moving it out
grealty speeds up the _get_employees_days_per_allocation method.
Example speedup: in a database with 50 validated allocations for
the same hr.leave.type and employee_id, the timing of
_get_employees_days_per_allocation 7.39s -> 158ms
opw-3123457
closesodoo/odoo#117778
X-original-commit: 5a2efd2e5c3e65502c031f79f85319f3351f66e3
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Activate Analytic Account
- Create a Service Product - create project on order
- Create a quotation with the product
- Confirm the quotation
- Go on the project -> analytic account is "order # - partner_name"
- On the quotation - Create Invoice
Issue 1:
- The invoice has "order #" has the analytic account and not the "order # - partner_name"
Issue 2:
- if you create an invoice and wants to select the analytic account
you cannot search it by the partner name, only by the "order #"
Cause:
When confirming the quotation, we create an analytic account. The
default name of the analytic account is the order name:
https://github.com/odoo/odoo/blob/bba5b6a440544151cc610bbc6848adfbadb38bfb/addons/sale/models/sale_order.py#L1416
Why is the analytic account displayed correctly on the project?
Because we use the `get_name` is triggered:
https://github.com/odoo/odoo/blob/bff34e0e8a8b2d211ef90ffea4f43c514e8cad28/addons/analytic/models/analytic_account.py#L115-L123
In the analytic distribution view, we only render the name of the
analytic account as it is defined primarly.
opw-3165655
closesodoo/odoo#117770
X-original-commit: b709a4491074169f6203ba98dec8847036262d6d
Signed-off-by: William André (wan) <wan@odoo.com>
While we run cron `Data Merge: Find Duplicate Records` then it raises a traceback
because `data_merge. model` has no method `_message_compute_subject`
This thread method is called in various steps when trying to post or notify a
message. With this PR we ensure notifying non-thread models is still working
as intended by being defensive when calling this method.
sentry-3947126655
Task-3254379
closesodoo/odoo#117763
Forward-port-of: odoo/odoo#117636
Forward-port-of: odoo/odoo#113460
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When using the composer on a non-thread model a notification is sent instead
of posting a message, as the model does not support the posting process.
However there is currently a crash due to the default subject computation
which is solved in this commit.
Task-3254379
Part-of: odoo/odoo#117763
While we run cron `Data Merge: Find Duplicate Records` an issue raises because
`data_merge.model` has no method `_message_compute_subject`. Indeed it is
possible to notify on non-thread models but that method is a thread-only
method.
In this commit, we only call `_message_compute_subject` when it's available
in model.
sentry-3947126655
Task-3254379
Part-of: odoo/odoo#117763
Current behavior:
In the pos order report the margin is not shown for products with no
cost.
Steps to reproduce:
- Create a product with no cost
- Open a pos session, add the product to the order and validate it
- Go to the pos order report and check the margin for the product
- The margin is not shown
opw-3232131
closesodoo/odoo#117723
X-original-commit: 223400d371615907a7ba7d5616ffeec307892f16
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce the bug:
- Go to the website edit mode.
- Choose the 'vertical' template header.
- Select 'off-canvas' in the 'mobile menu' option of the navbar.
- Bug: On mobile view, the menu links are not clickable.
This is caused by the addition of the "order-first" class to the navbar
by commit [1], which causes the menu to be placed behind the backdrop in
mobile view when off-canvas is activated. This only happens with
Firefox, and there is likely a difference in how Chrome and Firefox
handle the "order" property based on the positioning of elements.
[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2
opw-3009202
closesodoo/odoo#117683
X-original-commit: 7baa2d3e4949cf3c6e1b1130f03cc2b051dbff0f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this PR, the field tax_ids had no tooltip.
Since v16 we now allow the use of all taxes in the expenses module now. But, there is not much mention that price-excluded taxes will be used as price-included taxes.
In the release notes it just mentions that all taxes are usable, but there is no mention of anything else. This seems a bit confusing. Adding the tooltip will help users.
Also adding fresh exported .pot
closesodoo/odoo#117351
Task-id: 3252757
X-original-commit: df28d24699a6bfb4ea142fc07b10c1835d9d4323
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
*: account, crm, hr_recruitement, im_livechat, point_of_sale,
project, sale_management, website_sale
Purpose
=======
Now, the KPI are computed based on their `company_id` and not based
on the current company. If no company is set on the digest, we compute
it based on the current company.
The KPIs are computed based on their company. Most of the time, they
will all belong to the same company so we can improve the performance
by computing them in batch.
Task-2827996
See odoo/enterprise/pull/27658
Part-of: odoo/odoo#91945
An error appears when we try to change the product in transfer line via
product/search
steps to reproduce the error :
1- create 2 products : Test 1 (UoM is Cm) and Test 2 (Uom is g)
2- create a delivery order and add Test 1
3- UoM error due to the UoM not being updated at the time of change
The error was happening because when updating the product directly in
the line section , the stock_move item already has a UoM and the if
statement makes it impossible to change it , so the error appears.
opw-3231298
closesodoo/odoo#117504
X-original-commit: ece3dea8c1ab43a854a57513cc317e8618010542
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
before this commit, in the list view of
fleet (fleet.vehicle),
services (fleet.vehicle.log.services) and
odometer(fleet.vehicle.odometer) the vehicle_id
and model_id field with many2one_avatar is
not showing the image of vehicle and model.
* open fleet -> fleet -> fleet
* switch to list view
* model field will be with empty image
* similarly in services and odometer menus
after this commit, the widget will be removed
from the field as the avatar field doesn't
exists in the model level.
closesodoo/odoo#117752
X-original-commit: e57b6f898775a0e432ae1a21266a0f4bf82c0242
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Incorporate Andy Quijada (ajqn9094) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#117729
X-original-commit: 53fc292afe73eb67cdbf9dcb0fbb8dcff5caadd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Create a Storable product “C1” tracked by Lot:
- Update the Qty to 10
- Create a Storable product “P1”:
- Add a BoM:
- add 1 unit of “C1” as component
- Enable 3 steps for the manufacturing operation in warehouse settings
- Create a Mo to produce 1 unit of “P1”:
- Confirm the MO
- Click on related transfer:
- Select the “Pick component”
- check that the qty is reserved correctly
- Try to validate it without setting Qty done
- The immediate transfer is triggered, validate it
Problem:
The backorder's wizard triggers when it shouldn't
To know if we should create a backorder, we check if the qty reserved
is equal to the qty done, and as the qty done was not set correctly
during the validation of the immediate transfer, the two quantities
are not identical, therefore the widget is trigger:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_picking.py#L1128-L1132
opw-3240264
closesodoo/odoo#117706
X-original-commit: dd44e1f69dfd217fafa9c2ec5da8b211b2ff3513
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Adding the if condition to handle starred argument passed to
cr.execute
Adding two test to test that case
closesodoo/odoo#117688
X-original-commit: 4ab64dcd21ecd99c081975beee5ac13d2aa70a6b
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
The loading of products and partners in background is too slow for the moment.
For configurations with a lot of products or partners, the loading is slowing
the whole behaviour of the PoS while it is not really necessary to load
20K products. This commit sets the default behaviour of the PoS to "not load
products and partners in the background", it also adds a button
on the ProductScreen for user to load more products when
a search term is put in the search bar and the same on the PartnerListScreen
for loading partners. This load will load 30 items at a time.
closesodoo/odoo#117667
X-original-commit: 389c85af5983f2f25c7c24f21d3c3716077d7119
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
duration_percent field is a stored integer.
In postgresql, integer are 4 Bytes long, which create a range of -2147483648 to +2147483647.
With a small duration_expected, and a big duration, we can easily break these limits.
OPW-3253333
closesodoo/odoo#117744
X-original-commit: 97892d04341a2cbbe07e4db6442a451b0cf0b164
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Steps to reproduce the bug:
- Go to the warehouse settings:
- enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
- Preferred route: Manufacturing
- Product: “P1”
- BoM: select the second BoM
- To order: 1
- Click on the “Order once” button
Problem:
The manufacturing order is created with the first BoM instead of the
second.
As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523
Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340
opw-3217945
closesodoo/odoo#117732
X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, having an accrual plan with no
level before a certain amount of time would result
in a crash because no relevant level is found.
This commit avoid that error.
closesodoo/odoo#117722
X-original-commit: 7cc075604c2fffe3710e3b76a004e730650d62b1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current behaviour:
Cannot add a Work Order to a Manufacturing Order
if the analytic account linked to the MO doesn't
have an associated company.
Expected behaviour:
Should be able to add a WO to a MO even
if the linked analytic account doesn't have
an associated company.
Steps to reproduce:
1. Activate analytic accounts
2. Activate work orders
3. Create an analytic account without company associated
4. Create a Manufacturing Order
5. In miscellaneous, link the analytic account
6. Try to add a WO line
7. Error log
Reason for the problem:
When trying to add a WO line, if the MO has been linked
to an analytic account, it checks for the currency in
the company in the analytic account, which was not
existent, since the company didn't exist.
Fix:
When trying to access currency, if the company in the analytic
account doesn't exist, it defaults to the company in the WO.
opw-3210708
closesodoo/odoo#117708
X-original-commit: f0d8f5e82e62e0bcfc05e25dac2504f8f07537f4
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Removing the "Oks" from the "Archive" modals to
clarify what confirming the action will do.
Also fixing a wording error in the form controller
archive modal.
Task-3241064
closesodoo/odoo#117588
X-original-commit: 61c8b51a3d77e913acacead6379cd686693f86ce
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, website users/visitors are not able to search the events based on
where they happen.
This PR improves the behavior by allowing the users/visitors to type the
city/country name in the search box and returns the events that are happening
in the country or city that matches the search term. To allow this, we have
utilized the `search_extra` search option and searching the matching events with
`sudo` because public users can not access the `address_search` m2o of the event.
This PR also shows the event location name when users search for the event.
Also add the "_getFieldsNames" method to easily override this method to
add a field name from another model.
Note that searching with sudo is just to add event ids in the domain. The final
result will be returned with not sudoed environment and so the record rules are
always respected.
TaskId-2791031
closesodoo/odoo#89796
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Currently, if a user searches for an event based on a location name, the
location name is not displayed.
This commit shows the event location name when users search for the event.
Also add the "_getFieldsNames" method to easily override this method to
add a field name from another model.
task-2791031
Part-of: odoo/odoo#89796
Currently, website users/visitors are not able to search the events based on
where they happen.
This commit improves the behavior by allowing the users/visitors to type the
city/country name in the search box and returns the events that are happening
in the country or city that matches the search term. To allow this, we have
utilized the search_extra search option and searching the matching events
with sudo because public users can not access the address_search m2o of the
event. Apart from that, this commit also adds the ability to address_search
the event based on location (name) of the address on address_search.
Note that searching with sudo is just to add event ids in the domain. The final
result will be returned with non sudoed environment and so the record rules are
always respected.
TaskId-2791031
Part-of: odoo/odoo#89796
This commit is a security reinforcement.
Before this commit:
ir.action.act_url was able to handle and redirect to protocols like
file:, javascript:, date: ... This is unnecessary in the context of
this action. It could potentially be abused by a poorly written custom
module
It also would not isolate the landing page in case of a new tabs.
It means that chrome would still consider the tab to be from the
previous domain in case no url was passed and js was executed.
This would allow the newly open tab to still make query's to the
referrer using the referrer's cookie. While not stricly necessary
if we already prevent url that start with "javascript:", it is a
nice to have.
After this commit:
New tabs are not able to access referrer informations or execute
javascript interacting with the referrer. Also, it is now impossible
to redirect to protocols other than http and https directly from
the ir.action.act_url
Test update:
All new tabs are required to have the "noreferrer" argument
Tested an example of an unsupported protocol.
closesodoo/odoo#117687
X-original-commit: a020072da17e32fca0bbe6ed02b1afaeec8e8a02
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
luvi