PURPOSE
It has been reported that the page showing the exhibitors is slow because of the
partner table used behind the scene. It turns out that the page can generate many
links for the filters which can trick the crawlers to explore them all. As the
page is slow, the crawlers can put a high pressure on the server by exploring
those links.
SPECS
- Use a POST method to set the tag filters.
By using a POST method, the page will not longer generate links and the crawlers
will no longer explore them. This technique is actually more reliable than simply
defining a `rel="nofollow"` rule on the links.
LINKS
Task id: 2466072
closesodoo/odoo#68192
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Follow-up of [1]
Before this commit the map snippet had life-cycle and naming issues.
Also avoid partially reusing the color picker intended for background
images for the color filter overlay.
The height adjustment has also been removed, the standard top and
bottom padding can be adjusted to achieve a similar result.
[1]: https://github.com/odoo/odoo/pull/66766#pullrequestreview-685976812
Related to task-2464422
closesodoo/odoo#73180
X-original-commit: 8b9225ffd133332630097f29db9522abace7ba09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit updates the res.currency data files to be compliant with
the ISO 4217 standard:
Add existing currencies missing from Odoo.
Remove currencies deprecated since at least 10 years.
Update incorrect currency names and rounding values.
task-2501384
closesodoo/odoo#69356
Related: odoo/upgrade#2400
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
According to Argentinean law 27440, Art. 5º it is mandatory to show the
CBU on the report for electronic invoices and electronic debit notes.
Before this commit, we were showing only in FCE (MiPyMEs), and here we
add it for NDE (MiPyMEs) on invoices reports.
closesodoo/odoo#73108
X-original-commit: d5f3e1ddff72ba05af3b8d20888b92799c7d532c
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Move the odoo server parameters into the odoo.conf file
instead of being placed as the service command line argument
closesodoo/odoo#73143
X-original-commit: 8943ed4fdd01817a86e6a8abf6463e078182f584
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
https://github.com/odoo/odoo/pull/71872 made country_id readonly in every circumstance. This made it impossible to create an account.account.tag targetting taxes from scratch in the UI. We only want to prevent edition of this field when the tag has been generated by a tax.report.line.
closesodoo/odoo#73142
X-original-commit: 8f0ae54cd24e9a6299d86c47ed37aea2a7fa4ad8
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
To reproduce:
1) Install an European CoA and make sure the OSS mapping for its taxes has been generated (either installing l10n_eu_service before, or clikcing the "refresh tax mapping" button, in the settings)
2) Create a new tax with the same rate as one of your original taxes
3) Click on "refresh tax mapping"
===> Instead of reusing the OSS tax mapped with the other tax having the same rate, a new tax with the same name has been created.
X-original-commit: 6f6386ed0374cea143541add69c269f44b098050
When selecting a "basic" color from the color picker, it was displayed
as a custom color.
It was due to the fact that the basic colors were not correctly computed
to build the existing colors: the array of the rows was used instead of
the array of the colors.
Part of https://github.com/odoo/odoo/pull/72978
task-2476601
closesodoo/odoo#73139
X-original-commit: 23b182ab1bce9a00cb75d12b0d0c504d1fe19e2f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The commit fixes the display of custom colors in the color picker.
It improves previous fix from #72294, which was not returning all
editables from the editor, thus only the custom colors of the target
were displayed.
For that the request_editable event is reintroduced at the SnippetsMenu
level.
Part of https://github.com/odoo/odoo/pull/72978
task-2476601
X-original-commit: 68d7d42cce012269342e18373a30970e2c582ba3
add resetLocalState method to rendererWrapper and test activity view is not
crashed on on_destroy_callback
task-2466057
closesodoo/odoo#73022
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
before this commit: when switching to form view from listview using Create
button and then activate some other tab and Discard that record which will
move back user to list view now again clicking Create button opens form view
but active tab is last activated form tab instead of first one, this is because
of local state is not cleared.
after this commit: when form view is switched back to list view using Discard
button, local state will be cleared, here we are explicitly removing 'active'
class from all tab and pages of all notebooks.
task-2466057
X-original-commit: ff0e5694e28a46287dc54ab440364e11e8e9c832
Steps to reproduce:
- Install 'Accounting' module
- Switch to "My Company (Chicago)"
- Create an invoice
- Set Invoice date to 1/1/21 and
- Set Due date to 1/3/21
- Add any product and 'Confirm' invoice
- Go to customer profile
- Click on 'Due' stat button
- Click on 'Send by mail'
Issue
In received email, logo displayed is of "My Company (San Francisco)".
Cause
Env company not used.
Instead, logo of customer.company_id is used if mail type have
company_id field,
else will fallback on user.company_id
Also, if customer.company_id is null, it will fallback on '0':
/logo.png?company=%s' % (company.id or 0)
Solution
If mail record have NOT a company_id field or is not set,
set company to self.env.company.
Else, set company to record.company_id.
opw-2474114
closesodoo/odoo#73099
X-original-commit: 316b5956844d6f77f6fef1efeb5a8a8505e36e8e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue:
For purchase user, which doesn't have the "Contact Creation" can't
create a purchase, get a AccessError.
The fields `receipt_reminder_email` and `reminder_date_before_receipt`
should be writable also for purchase user which doesn't have access
to write and create `res.partner`.
closeodoo/odoo#64135closesodoo/odoo#73131
X-original-commit: f29b1e81e6adf8532ecf90f9ecb675ec56eb4c61
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Currently if public user has country_id, following traceback is raise
when /shop URL is opened:
Traceback (most recent call last):
File "/.repo_requirements/odoo/odoo/addons/base/models/qweb.py", line 331, in _compiled_fn
return compiled(self, append, new, options, log)
File "<template>", line 1, in template_website_sale_products_item_306
File "/.repo_requirements/odoo/addons/website_sale/models/product.py", line 294, in _get_combination_info
fpos = self.env['account.fiscal.position'].get_fiscal_position(partner.id).sudo()
File "/.repo_requirements/odoo/addons/account/models/partner.py", line 184, in get_fiscal_position
fp = self._get_fpos_by_region(delivery.country_id.id, delivery.state_id.id, delivery.zip, vat_required)
File "/.repo_requirements/odoo/addons/account/models/partner.py", line 141, in _get_fpos_by_region
fpos = self.search(domain_country + state_domain + zip_domain, limit=1)
File "/.repo_requirements/odoo/odoo/models.py", line 1708, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/.repo_requirements/odoo/odoo/models.py", line 4485, in _search
model.check_access_rights('read')
File "/.repo_requirements/odoo/odoo/models.py", line 3331, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "<decorator-gen-33>", line 2, in check
File "/.repo_requirements/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/.repo_requirements/odoo/odoo/addons/base/models/ir_model.py", line 1792, in check
raise AccessError(msg)
odoo.exceptions.AccessError: You are not allowed to access 'Fiscal Position' (account.fiscal.position) records.
This operation is allowed for the following groups:
- Accounting/Advisor
- User types/Internal User
- User types/Portal
Contact your administrator to request access if necessary.
Error to render compiling AST
AccessError: You are not allowed to access 'Fiscal Position' (account.fiscal.position) records.
This operation is allowed for the following groups:
- Accounting/Advisor
- User types/Internal User
- User types/Portal
Contact your administrator to request access if necessary.
Template: website_sale.products_item
Path: /t/t[2]
Node: <t t-set="combination_info" t-value="product._get_combination_info(only_template=True, add_qty=add_qty or 1, pricelist=pricelist)"/>
Above was tested and reproduced in an instance of odoo runbot v14.0:
https://youtu.be/GgUnyna_EX8
That is due to public user has not permission to read model
account.fiscal.position and in fact in ACL, permission contains
'public' but is setting group_portal.
closesodoo/odoo#73117
X-original-commit: 53dc9f62b6d4c362292bf48df54b11c4852f6006
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The commit fixes an issue with the editor toolbars dropdowns, that would
not close already opened widgets. For example, when the widget color
picker for snippets background was open, opening the one from the editor
toolbar for the font would only close it for the first click, but not
for the ones after.
The issue was coming from Bootstrap, which stops the propagation of
click events for dropdowns. As a result, the click event on these
'.dropdown-toggle' elements was not processed by the listener at the
SnippetsMenu level, in charge of closing the widgets that were already
open in this context. It was the case only for the first click that was
instancing a Dropdown, but not for the ones after.
https://github.com/odoo/odoo/blame/cd9c071c9357cef14635ef094a9f14fc5431956c/addons/web/static/lib/bootstrap/js/dropdown.js#L308-L314
A solution would be to update bootstrap:
https://github.com/twbs/bootstrap/blame/688bce4fa695cc360a0d084e34f029b0c192b223/js/src/dropdown.js#L232-L237
The fix can be to listen to mouseup events on such '.dropdown-toggle'
elements while waiting for a bootstrap update.
Part of https://github.com/odoo/odoo/pull/72539
task-2476601
closesodoo/odoo#73032
X-original-commit: 048a329fc514b2c98cf7e6af7279f90fce53eb09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the color palette for the text was open, opening the background
color options was not closing it.
The click event was stopped at the snippet option level for all events,
where it should only be the case if the click was done inside the
colorpicker.
Part of https://github.com/odoo/odoo/pull/72539
task-2476601
X-original-commit: 888f1bd44d0aa431d3d89ee3c913c6eb64c3d54d
After the new editor was merged, custom event 'request_editable'
triggered by the ColorPaletteWidget to retrieve custom colors from the
editable was not processed.
Now, we pass the editable in the options when we init the
ColorPaletteWidget.
task-2476601
closesodoo/odoo#72959
X-original-commit: 3d98268cf93087516743e3f0a2f3af950d4feb6a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, failure_reason was also copied when user duplicate email.
Which is not correct since the Mail is never sent not failed.
With this commit, failure_reason will not be copied when user duplicate email.
closesodoo/odoo#71690
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If user selects 'schedule appointments' as main objective in the configurator
and if the website_calendar module is installed then the Call To Action of
snippets s_banner, s_cover and s_call_to_action is changed to 'Schedule an
appointment' and redirect user to '/calendar' on click.
task-2518565
closesodoo/odoo#71162
Related: odoo/enterprise#18690
Related: odoo/design-themes#5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Enable Margin analysis
- Have a product [TEST] in a category with
- FIFO and Automated Valuation.
- Kit BOM with 3 items (A,B,C)
- Create a SO with [TEST] and confirm.
- Modify the BOM and remove C from the kit.
- Back to the SO, cancel it.
Traceback will show, because there no more a bom_line associated with
the move
opw-2541674
closesodoo/odoo#72696
X-original-commit: 27821b728f409d7e1a69e84d0beb5ac708e6420e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Currently, a traceback is generated on removing a groupby when line is in edit
mode in groupable list view. It happens because the facet removal and window
click both are called at the same time.
This commit fixes the issue by ignoring the window click on removing the search
facet.
TaskID-2518527
closes#70236closesodoo/odoo#73102
X-original-commit: da51bd7ef270fe5a481b937f0a3c296d0eea196c
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Steps to reproduce the bug:
1. Activate the 2 language “’English’ , ‘Spanish (AR) / Español (AR)’ ”
2. User -> select the language ‘Spanish (AR) / Español (AR)’
3. Create a new product (Test Product).
4. Create a another product using “Duplicate” function.
5. Rename new product name(Test Product -1)
6. Translate the name ( “Spanish (AR) / Español (AR) : 111 Spanish product “ , “English: English Product” )
7. create a purchase agreement -> select product “111 Spanish product ” -> Save -> confirm -> new quotation.
8. Purchase Quotation -> Order line
Bug:
Description shows “Test Item (copia)”
opw:2582778
closesodoo/odoo#72997
X-original-commit: 947484cd9a082003bfd5b3c2e64d6033b863aa84
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Due to EU e-commerce 'One-Stop Shop' which becomes available on 1 July 2021, EU companies involved in distance sales are able to file their taxes using the new OSS process. Adopting OSS is now simplified in Odoo.
On installation of the module, all companies having a fiscal country in the EU will be processed.
For all existing domestic taxes in the company, an associated foreign tax (standard rate, reduced rate, etc) is found in the `EU_TAX_MAP`. This mapping will be created in a fiscal position that is automatically detected based on the customers' country.
All that is required from the user, is to review the tax mappings according to the products and services sold by the company.
A refresh button is also available in the odoo settings to redo/update the fiscal positions. This might be useful after adding a new tax.
Note: The tax mapping herein is not intended to cover all possible tax mappings between EU countries, but rather, the most commonly used ones. It is advised that users with special tax cases update the created Fiscal Positions according to their requirements.
Closes [Task 2579615]
closesodoo/odoo#73042
X-original-commit: 9c548c423614d1305542ebdffdbcd0da3cf09899
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Habib Ayob <h4818@users.noreply.github.com>
- Have a Promotion program [TEST] applied automatically, which apply a
fixed amount discount on order
- Have a Sale Order, apply test via 'promotion' button
- Edit [TEST], add a mandatory code to be used
- Back to SO, add the promotion again via 'coupon' button and insert the
code
Promotion will be applied again in the order
opw-2526950
closesodoo/odoo#72860
X-original-commit: 8ff2a16401d462850b111a551a5058eef441a9b5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Currently, activity view does not support many2one_avatar_user widget due to
which clicking on image do not open chat window, with this commit, we add
support of many2one_avatar_user widget in activity_view so that user can click
on avatar image and open chat window.
task-2554466
closesodoo/odoo#71804
Related: odoo/enterprise#18803
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Go to User list
With studio add column User type
export
Traceback will occur because the special field sel_groups_*
should not be exported
opw-2565911
closesodoo/odoo#72861
X-original-commit: 196fe4c0be19310964b41da3b8a113f6d81aed6e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The #for attribute of the LABEL tag should match the #id of the INPUT
tag, not it's #name.
This regression was introduced in a171694644closesodoo/odoo#73052
X-original-commit: 979c9d71aee4b1bb6c8798bdfdbf69ac8af3fa69
Signed-off-by: Romain Tartière <romain@vittoriaconseil.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
New features to show suggested links as an autocomplete when creating a menu
was introduced with 9b9829416b.
But it was missing a sudo, so non-admin editor could not read module records.
task-2583737
closesodoo/odoo#73035
X-original-commit: d8206db3da541ba3f0c3e9cb63eab802e3ff096b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Before this commit, if a parent menu had child menus and all of those were not
visible (eg linked to an unpublished page), that parent menu would still be
shown.
While it is more a choice than an error, it might makes more sense to not show
it as most of the time, that parent menu has no sense itself, it just served as
a way to group submenus. Its URL can't be clicked (as it opens a dropdown)
despite the fact it is required, and is actually most of the time a random URL
typed by the user as it has no real purpose.
The parent menu is just used as a dropdown entry and shouldn't be displayed if
there is nothing in the dropdown, instead of converting it to a regular menu.
Historically, it was decided to do it that way to fulfill this usecase:
- /dogs
- /german-sheperds
- /beagles
If you were to unpublished your beagles and german sheperds pages, the menu
would auto convert to a regular menu pointing to your dogs page.
This use case now seems less prefered than the behavior to hide that menu.
task-2583737
closesodoo/odoo#73020
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
A kits bom has a component but qty is 0. When sale this kits, the 0 qty
component won't be delivered, and the delivered qty of the kits will
always be 0.
To fix it, we don't find a stock.move and bypass the quantity check
since the stock.move are not generated when bom line quantities are 0.
Task-2580118
PR #72637closesodoo/odoo#72920
X-original-commit: fad7a15560c1d454be294f1a8d1ce5a57d576900
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
We have a test case 'test_my_activity_flow_employee' that checks user's
own activty for current day. However, the creation of the activities is
done with OdooBot, and 'date_deadline' is not being passed. For this
reason, the default deadline (default value = fields.Date.context_today)
is set based on the tz of OdooBot (which is Europe/Brussels) and so it
might happen that the deadline is set on the next day (when test case
is performed just before mid-night).
In such cases, when we search for today's activites for the employee
(with absolute current date in domain, which is still before midnight),
result can be misleading as we expect one activty for the employee but
none could be found (as deadlines are set for the next day).
This commit fixes the issue by using absolute current for the test case
(whlie setting 'date_dateline' and while searching records) and thus making
it more reliable.
Note: The test case was introduced with commit https://github.com/odoo/odoo/commit/6aa3dc609cb13a469492b1a39a8fd9810040f079
TaskID-2570963
closesodoo/odoo#73034
X-original-commit: 962153a062af3f611e38c0d588febfecd9755810
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit: when user is in readonly form, hovering on color picker
widget show cursor pointer due to which user has impression that it can be
edited while color picker should display default cursor in readonly form.
after this commit: in readonly form color picker widget will display default
cursor while hovering over color.
task-2326198
closesodoo/odoo#73011
X-original-commit: a7663fd5c0bf9f09dbb7fa472b1cb0ef3aa47930
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
This commit adds a sum field description when hovering the quantity at the end
of a progressbar. The description is the label (translated string
representation) of the field used for the sum.
Task-ID: 2243913
PR odoo/odoo#69380
Taking advantage of the new action_opportunity_forecast for crm leads to
create a dedicated ir_actions.xml file to store all server/client actions.
Task-ID: 2243913
PR odoo/odoo#69380
Add a new submenu "Forecast" in "Reporting" for CRM
The Forecast shows 4 views:
1. Kanban
2. Graph
3. Pivot
4. List
Objective
Shows the short term forecast for opportunities (crm_lead) based on their
expected closing (date_deadline) and have an overview of the prorated
revenues for each period (defaults to month).
Implementation
1. Kanban
- the progressbar is using the prorated_revenue
- the forecast_field is date_deadline
- the default groupby is date_deadline
2.3. Graph, Pivot
- the measure defaults to the prorated_revenue
- the row defaults to date_deadline
4. List
- shows the prorated_revenue
The special filter "Forecast" is defined to be used by the
forecastModelExtension (JS). (define the forecast_filter context key)
The forecast_field context key is defined in the action to be used by the
forecastModelExtension and the forecastService (JS).
The demo data for opportunities is updated to spread date_deadline over 4 months
Enable drag&drop and quickCreate features for the kanban view with the use of
the allow_group_range_value <field> xml attribute
Add a "Won" flag for the forecast view to better distinguish opportunities that
need to be worked on
Test tour
Task-ID: 2243913
PR odoo/odoo#69380
ENT PR odoo/enterprise#18547
* Currently located in CRM as it is its only use. After Owl-ification of Web
Client it will probably be added as a core feature.
* Objectives:
- Kanban view:
- Kanban groups on a specific date/time field should be contiguous and show
a short term vision. Empty groups should be shown
-> FillTemporalService
-> ForecastKanbanModel
-> context.forecast_field
- Add the next period (i.e. month) with one click in the kanban view
-> ForecastKanbanRenderer
-> ForecastKanbanController
-> ForecastColumnQuickCreate
- Store specific time ranges for each granularity (year, month, ...), so
that when the user switches back to one his progress will be recovered.
(reset on page refresh)
-> FillTemporalService
- Graph, Kanban, List, Pivot views:
- Filter out data from the past (previous periods), while keeping every
records from the current period even if we are in the middle of it
-> ForecastModelExtension
-> context.forecast_filter
-> context.forecast_field
* context key `forecast_field`:
- Used to set the date/time field name, on which the forecast logic should be
applied
- This key will be used by :
a js model (for a view) / ForecastModelExtension / FillTemporalService
* ForecastModelExtension and context key `forecast_filter`:
This extension will use a filter, the groupBy value, and the
context.forecast_field to apply a custom domain constraint.
This domain constraint can also be applied by default with the
FillTemporalService, but it was decided to extract it to a filter for the user
to be able to disable it, to see "old forgotten records" and update them if
necessary. In other words, this filter enables or disables the first bound of
the domain for the read group.
- Filter "Forecast":
This filter should set the context key `forecast_filter:1`, in order
to only get future records starting from the start of the period
containing "now".
example:
now: 2021-04-26
groupBy: month
=> all records starting from 2021-04-01 match the filter
- If none of the groupBy values are the forecast_field, filters the records
on the forecast_field starting from "now"
* FillTemporalService:
This service will be used to generate or recover `FillTemporalPeriod`.
Depending on the configuration, it will return an instance handling a
certain `forecast_field`, with a certain `granularity` (hour, day, week,
month, quarter, year), for a certain `modelName`. This can be used in
multiple views to always get the same object, if it concerns the same model,
the same field and the same granularity.
The generated `FillTemporalPeriod` object is used to compute the final domain
and context to be provided to the backend `read_group`.
The objective was to limit the amount of desired groups regarding a specific
time period (cycle). Here are the cycles depending on the granularity:
granularity - cycle
-------------------------------
hour - one day
day - one week
week - one week
month - one year
quarter - one year
year - one year
In order to get a minimal amount of groups after a read_group, we can provide
an integer in the configuration : `min_groups`, which will guarantee this
amount of groups, regardless of the rest of the configuration
The default maximum amount of groups returned depends on the end of the
specific cycle reached after guaranteeing `min_groups`
We can always alter the result by directly modifying the `start` and `end`
properties of the `FillTemporalPeriod`, using the dedicated methods to do so.
Configuration of the domain with the keys `force[Start|End]Bound`
- true: applies a lower|upper bound for the domain, which means that
the subsequent read_group will search for groups [from the
start|until the end] of the FillTemporalPeriod
- false: no domain constraint applied, which means that at least every
groups with records in the database will be returned
Configuration of the context with the keys `forceFilling[From|To]`
- true: set fill_temporal.fill_[from|to], which means that at least
every groups [from the start|until the end] of the
`FillTemporalPeriod` will be returned as contiguous groups
by a read_group
- false: does not set fill_temporal.fill_[from|to], which means that
read_group will only return groups from|until the first|last
one with at least one record
The `expand` method can be used to add one interval to the end of the
`FillTemporalPeriod` depending on the granularity (add one group)
* any "forecast" view :
- should define a `forecast_field` in the context
- should use the `forecast_model_extension` with the searchModel to be able to
filter "future" records correctly
- could make use of the `FillTemporalService` to maintain a consistent domain
and context when grouping by the desired date field. The domain and
context are to be applied on __load and __reload calls in the MODEL, on the
provided domain and context, to further filter the groups returned by a
read_group.
* forecast views: graph, kanban, list, pivot
* kanban
uses: forecast_model_extension, fill_temporal_service
has a custom `column_quick_create` limited to the forecast_field which
allows to add the next group (period depends on granularity)
works with the sample_server even thought the domain and the context are
modified during the __load/__reload processes.
* graph, pivot, list
use: forecast_model_extension
Task-ID: 2243913
PR odoo/odoo#69380
1. Objective
- We are in a Kanban view, and we group by a "date/datetime" field.
- In order to "quick create" a record in a group, or to "drag & drop" a
record between 2 groups, we need a default value for this date field.
- In this case, a group represents a "range" of dates. A default value could
be the last date of this range.
- Prior to this commit, the view had only access to a display string for this
date range. We want to have access to the concrete bounds (start/end dates)
- Since some date/datetime fields have backend constraints, it would be
difficult to generate a compliant global default value. As such, the use of
the default value should be disabled by default and activated on a field by
field basis.
2. Usage
- Use the last day (for dates), or second (for datetimes) of the range to set
a default value in kanban "quick create" and "drag & drop"
- Use the end of the range of the last group from a read_group to be able to
request the next group (chronological order) in subsequent read_group calls
3. What are the changes in this commit
- read_group from the "core" "models.py", with the added __range for
date(time) fields, a dictionary for each group. The keys are the field
names and the values are a dictionary with the following keys: value:
- from: starting date(time) of the range (inclusive)
- to: ending date(time) of the range (exclusive)
- XML changes:
- with a new xml attribute on <field> tag allow_group_range_value (for the
kanban view):
- we allow (or disallow) supported non-readonly fields to be:
- draggable
- quick created
- this attribute can be used only on date(time) fields, and if not set,
the default behavior is false
- the naming is subject to contention because it relates to
different features. The relation comes from the constraint:
To perform a drag&drop or a quickCreate, we must be able to get the
value from the group containing the record.
- JS changes:
- we add "group.range" after a read_group for date fields, which is a
dictionary: {field_name: {from, to}}, for each date(time) groupby field
- since date(time) fields can use the format "date_field:granularity" when
used in a groupby, we have to properly split out the granularity to ensure
compatibility with the code previously in place (drag&drop procedures)
- update mock_server and sample_server to make use of the date range.
Adding support for datetime grouping to both mock and sample servers, for
tests and previews.
- the default value for kanban drag&drop and quickCreate features is the
last day/second of the range for date/datetime fields
4. Why can't this range be computed from the original display value with
moment.js
The Babel python library that we use for date(time) formatting (2.6.0) is kept
at the same version as the package in stable Debian Linux. This version has
some issues with displaying weeks consistently around the new year in certain
locales.
We cannot reverse compute a date(time) label with moment.js to get a range since
nothing guarantees that the range will be the same one that Babel used to
output it.
5. read_group return format discussion
Prior to this commit, the format of the value for the groupBy field was
either :
- String : used as a display value for the group.
Most notably, for date and datetime, this value cannot be used as a field
value in most cases. It would be more practical to also return the date
range along with the display value, so that Drag&Drop and QuickCreate
functionalities can be properly enabled in views
example :
"March 2021" has the range ['&', (field, '>=', 2021-03-01),
(field, '<', 2021-04-01)]
This information is lost at the end of the read_group.
- Array : used to indicate a res_id in case of a many2one field
res_id = array[0]
field_diplay_value = array[1]
Since we cannot use the array format to send the date(time)s of the period range
because it could be confused with the many2one format, this commit introduces
the use of a new `__range` key which is a dictionary with specific related
keys to be used to defer usable data to the web client.
Task-ID: 2243913
PR odoo/odoo#69380
When sending a notification, the company used is:
- company_id of current record or if not available,
- company_id of author or if no author,
- company_id of user
This can seem unexpected if the author is the current user and the
company_id of our user is different than the current company switcher
company.
With this changeset: the company used is:
- company_id of current record or if not available,
- company_id of author if author is different than user or,
- current company in company switcher or if not,
- company_id of user
opw-2472622
closesodoo/odoo#73031
X-original-commit: 3f61d9e2dadf47d211ed078b36e9f3a416bbbff0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps:
- Active Pricelist
- Create SO --> add some lines
- Change Pricelist and remove lines
Issue:
- Button to Update prices is still visible
Fix:
- Button should not be visible as there are no lines
closesodoo/odoo#73038
X-original-commit: aab38f9d52f8629eaea1a3725e4909ac5df1b067
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a vendor is (un)archived, we should (un)archive all related products
as well to avoid displaying archived vendors and products in the search
panel of the Order lunch and Products list views.
closesodoo/odoo#73007
X-original-commit: 259d2f36cc73892ef295a6cfdc7e72340bfd9afd
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Before this commit, clicking on "Edit ControlPanelView" in the
debug manager actually edited the "main" view (e.g. kanban), because
we used the wrong view id.
This commit also renames "Edit ControlPanelView" into "Edit
SearchView", which is more accurate w.r.t. to the view type.
closesodoo/odoo#72995
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
nounoubensebia