summaryrefslogtreecommitdiff
path: root/addons/web/models/models.py
AgeCommit message (Collapse)Author
2020-06-30[FIX] *: correct all or improve code translation lookupMartin Trigaux
This commit fixes all issues detected by the new pylint gettext-variable test. It converts some calls to the new syntax _("Foo %s", bar) to progressively migrate the code to the new syntax. A few calls were not technically incorrect but still detected by the linter. _("Foo" + "Bar") has been converted to _("Foo" "Bar") as it has the same effect and make sure the argument is of type asteroid.Const instead of BinOp). closes odoo/odoo#53683 Related: odoo/enterprise#11467 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
2020-06-26[FIX] web: company report style on change layoutNicolas Lempereur
When company layout is changed, we do not update the company styles for report: thus we still have the old style for other layout that will not change anything (besides font). opw-2269849 closes #53706 closes odoo/odoo#53720 X-original-commit: 8897701b1754b40d8a83c5681907c38fb205657f Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
2020-06-12[FIX] web: always use filter_domain for search panel countersMathieu Duckerts-Antoine
The counters for categories were not updated when filter values were selected. This commit fixes that situation. This might impact the global performances of the search panel but there is still room for improvement. Actually, it could be possible to reload categories and filters less often by carefully track the internal changes and the categories/filters attributes (enable counters, expand,...). closes odoo/odoo#49307 Related: odoo/enterprise#9795 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
2020-06-12[IMP] web: expand domain != count domainMathieu Duckerts-Antoine
In the search panel, the domain used to compute the field image values (when the attribute expand is false) was the same as the domain used to compute counters (if enabled). The idea was that a value bringing an empty domain is totally useless and should not displayed. That being true, it turns out that if one does not allow them and several fields are used, selecting a value in the search panel will very often totally transform the search panel. From a UI perspective, this turns out to be bad: the search panel 'moves'. Let us give an example: Let us start from a search panel that looks like to: first_field A 1 B 3 second_field C 1 D 2 <--- mouse above D E 1 with first_field and second_field both with expand="0" and enable_counters="1". Let us also assume that no record in the global domain has both first_field=A and second_field=D. Click on D would make the search panel look like to something like first_field B 1 second_field C 1 D 2 E 1 <--- mouse here (the selection of D does not impact the values for the second_field but does for the other first_field values). This has led us to use basically only the domain comming from outside of the search panel to compute field image values. This means that we might now have value with zero count even if expand is false. In the above situation, a click on D would give us first_field A B 1 second_field C 1 D 2 <--- mouse still above D E 1 Task ID: 2154749 Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: Julien Mougenot <jum@odoo.com>
2020-06-12[IMP] *: limit in search panelMathieu Duckerts-Antoine
This commit introduces a new attribute 'limit' for search panel fields that allows to avoid performance issues. That integer attribute (with default 200) allows to fix a maximal number of values to display for the fields. When the number of field values to display reaches the limit, no values will be displayed. Instead, a warning message will be shown in the corresponding search panel section. Note it is possible to have no limit using limit="0" on a field. This commit reintroduces in a better way the principle brought by the fix 8d57153b34c04952a85f6642951cb2697016da84. Task ID: 2154749
2020-06-12[IMP] *: expand and hierarchize in search panelMathieu Duckerts-Antoine
The commit introduces two new attributes for search panel fields: - hierarchize: boolean attribute (default True) available for many2one fields with select="one". It allows to choose whether to hierarchize the field values using the _parent_name (if set) on the field comodel. Note that a sanitization of the parent hierarchy takes place. Basically, it ensures that parent chains are completely in the domain (on comodel) accessible by the user. See _search_panel_sanitized_parent_hierarchy documentation for more information. - expand: boolean attribute (default False) available for many2one and many2many fields. If set to true, all field values are fetched and displayed in the search panel. If set to false, only the values that have at least one corresponding value in the field model (and in some domain) are fetched. An exception in the case of an hierarchized field (hierarchize=True and _parent_name set): more/less values can be displayed in order to have a good representation of the parent hierarchy. That means we complete and sanitize the set of initial field image values. Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the notion of limit in search panel has been reverted in the present commit. An upcomming commit will reintroduce the limit principle in a better way. Task ID: 2154749 Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: Julien Mougenot <jum@odoo.com>
2020-06-12[IMP] *: enable_counters with false as defaultJulien Mougenot
In the search panel, the attribute disable_counters with default False has been changed to enable_counters with default False.
2020-05-14[IMP] *: convert to private methodsMartin Trigaux
render, render_template, load, activity_schedule_with_view, get_website_pages should all be private: It should not be possible to render an aribtrary template only with its name or id Still need to render some qweb views from js so the method render_template is kept public. This explains why the website editor still need read access on ir.ui.view as we want to allow any snippet to be rendered.
2020-05-05[IMP] web: search panel counter changesMathieu Duckerts-Antoine
This commit introduces several changes in the search panel with respect to record counts: - the record counts are now also available for the fields with select="one" attribute (if not disabled explicitely). - the record counts are better computed using the idea that selected values within a group should not impact the counts for the group values but only the counts for the other group values. On the way we have changed two keys in the values returned by the server: - 'count' becomes '__count'. It has been done to avoid a possible clash in case a model would have a field named 'count' and that the field values would be wanted for some reason. - 'name' (multi case) becomes 'display_name'. It has been done in order to make the select one and multi cases more similar and factorize some code. TASK-ID: 2166814 Co-authored-by: Raphaël Collet <rco@openerp.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: Alexis Lacroix <laa@odoo.com> Co-authored-by: Julien Mougenot <jum@odoo.com>
2020-04-28[FIX] web: limit on search panel valuesMathieu Duckerts-Antoine
Before this commit, if a many2X field with a big comodel was added in a search panel, the view using it would crash. For instance that problem occured in the kanban view for hr.job, where res.users appears as the comodel for the field user_id. Now, we fix an arbitrary limit of 200 to the numbers of values to fetch for each many2X fields in the search panel. This avoid the problem mentionned above. Furthermore, in case the limit is attained for a field used as select="one", the values are displayed without being hierarchized. Indeed the limit can leads to gaps in the knowledge of the hierarchy and consequently to a bad representation of it. Task ID: 2154668 closes odoo/odoo#50334 X-original-commit: 8d57153b34c04952a85f6642951cb2697016da84 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
2020-04-14[FIX] web: style attachment company specific always in bytesLucas Perais (lpe)
Following https://github.com/odoo/odoo/pull/44393 Delete the qweb template `web.styles_company_report` Recompute company specific style by going into Settings > Configure Document Layout > change stuff and save Print a report, in HTML to get an human readable error (PDF rendering would just ignore the error) Before this commit, there was an error "could not get asset content" This was because the css asset created in db had a value of type string whereas it should have been the same type as b64encode (which is byte-like) After this commit, there is no error at rendering time closes #49456 closes odoo/odoo#49529 X-original-commit: 2a7e06663c1281f0cf75f72fc491bc2cc39ef81c Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
2020-03-30[FIX] *: set ondelete policy of required Selection fieldsAdrian Torres
With this commit, Selection fields with `required=True` which are extended via `selection_add` are given proper ondelete policies to ensure the cleanup of records containing these extended options during uninstall of the extending module. This commit also cleans up leftover uninstall hooks that were being used to handle the same set of problems prior to the ondelete mechanism being implemented for Selection fields. closes odoo/odoo#46325 Related: odoo/enterprise#9117 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
2020-03-02[FIX] web, base: make company-specific report assets staticLucas Perais (lpe)
Before this commit, the company specific colors and font were implemented by systematically overwriting a "virtual" report SCSS asset file before rendering each report. This caused many issues, forced frequent asset bundles recomputations (performance problem + cache invalidation causing random bugs). And it could simply not work in a multi-company setup where multiple styles are involved, as the asset management could be made not thread-safe. PR #44225 was a first attempt to mitigate the numerous problems by making the asset bundle invalidation less frequent. But the problems were still present and a more complete solution was necessary for multi-company setups. Besides, the design of the bundle forbade making company specific assets. This commit uses a different approach: instead of having a company-specific asset that needs to be constantly updated, a global "multi-company" asset is maintained and included in the report assets. It only needs to be generated when a company style changes, not for every rendering operation. Unfortunately this change cannot be fully performed without updating the template declarations, so it will require an update of the `web` (or `base`) module to be operational. As this represents a rather invasive change in a stable branch, extensive testing was conducted to minimize the effects and ensure proper degradation of features for production deployments where the new code would be deployed without forcing an update of the `web` module: - The report SCSS files were left untouched, to prevent any bundle invalidation, ensuring that old cached assets would remain valid. This means that single-company setups should not see any visible difference after pulling the code (with or without updating `web`). SCSS cleanup will be done later. - Existing Python methods were kept but emptied, to make sure that old templates and code would not crash. - For multi-companies, the last used colors will be applied for all reports until the `web` module is updated. The old behavior was not working correctly anyways, so the degradation is actually limited. - For all setups, changing the colors after deploying this patch will have no effect unless the `web` module is updated. /UPDATED FOR master on top of #44393/: - removed the `res_company.update_scss()` method entirely - fixed the report SCSS styles, as the variable names referred to the old behavior, e.g. "$o-company-primary-color" is nonsense. Renamed to "$o-default-report-primary-color" etc. -- Improves #44225 Forward of #44393 opw-2168623 opw-2171040 closes odoo/odoo#46647 X-original-commit: a5b1421aecf27b1de408434d3bb6d7ac81f57dc3 Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
2020-01-21[IMP] web: Add support of js_class attribute for qweb viewsLucas Lefèvre
Task 2119567
2020-01-10[FIX] mail, web: fix activities count when they are uniquifiedJason Van Malder
Issue - Install CRM for example - Add 41 leads - Create an activity on each of them Everything ok, load more shows up - Add another activity on one of them Load more doesn't shows up Cause The uniquify method: https://github.com/odoo/odoo/blob/saas-12.3/odoo/models.py#L4187:#L4191 Consider the second activity as a duplicate and removes it. So, in `web_search_read`: `len(records) <= limit` is `True` and we ignore all the others records Solution Add `force_search_count` in the context when using this action to avoid uniquify to falsify the records length. I added the tree view for this action too. It improves UX. OPW-2165455 closes odoo/odoo#43149 X-original-commit: 13ec3503fbfb5d3d2b1e824059737bd866a3a9f4 Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
2019-10-01[FIX] *: remove en_US as fallback for lang codewan
en_US may not be activated as it is possible to create a database in another language using the database manager. When trying to install a chart of account, the tax return entry tried to format a date at the installation of the module, with no lang in the context. The fallback was made on en_US but an error is raised if that language is not activated. As it is a very common scenario to retrieve a language from the context, add a generic tool method to do it. Replace and closes odoo/odoo#37629 closes odoo/odoo#37568 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-04-02[IMP] web: fetch records alongside read_groupAaron Bohy
This rev. adds params to the 'web_read_group' method, allowing to search_read records inside each groups in a single RPC, instead of doing a 'web_read_group' RPC followed by n 'search_read' RPCs, where n is the number of opened groups. Part of task 1915702
2019-04-02[IMP] web,board: enable pagination in grouped listsAaron Bohy
With this rev., when there are a lot of groups in a grouped list view, groups are displayed under several pages, whereas they were all displayed in the same page before. This is especially interesting with the new 'expand' attribute, to ensure that we don't read records for a large number of groups. By default, the groups limit is set to 80 (like records), and to 10 is the 'expand' attribute is set to true. This limit can be overriden with the 'groups_limit' attribute. Part of task 1915702
2019-03-07[FIX] web,hr: don't display dept complete_name in searchpanelAaron Bohy
The departments being already rendered according to the hierarchy, only the name of the department should be displayed (e.g. 'Direct Sales' instead of 'Sales / Direct Sales'. closes odoo/odoo#31353 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
2019-02-13[IMP] web: add kanban searchPanelAaron Bohy
This rev. defines a searchPanel widget used in Kanban views to refine search according to specific dimensions. This wigdet is displayed as a sidebar to the left of the kanban view. Part of task 1892462 Co-authored-by: Aaron Bohy <aab@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: Raphael Collet <rco@odoo.com>
2019-02-04[MERGE] forward port branch saas-12.1 up to 4524ad06a8aChristophe Simonis
2019-01-31[MERGE] forward port branch 12.0 up to cb8fefa8999Christophe Simonis
2019-01-17[FIX] web: make the progress bar handle False as selection valueNans Lefebvre
Fine-tuning of commit 92b4e2e866363ecb1b62c2448d40a5fcfc481348, itself a performance fine-tuning of commit b7e2d4759688b4735c78 which added progress bar support for selection fields. However it assumed that every record had a value in the selection, whereas False is (nearly) always a possible value. opw 1916472 closes odoo/odoo#30322
2018-11-29[REF] *: replace deprecated pycompat helpers for builtinsAdrian Torres
This commit replaces calls to pycompat helpers that were intended for python 2 <-> python 3 interoperability for python 3 builtins, as python 2 is no longer officially supported by Odoo. This includes: * calls to imap/izip/ifilter replaced by map/zip/filter * uses of text_type replaced by str * uses of unichr replaced by chr * calls to implements_to_string, implements_iterator removed * string_types and integer_types replaced by str, int respectively * calls to to_native replaced by calls to to_text This is done in preparation to the removal of these deprecated helpers in the following commit.
2018-11-15[FIX] web: fix performance issue with read_progress_barGéry Debongnie
The read_progress_bar method is incredibly not efficient. It is also wrong in other ways (for example, if 2 groups have same labels, there is a collision). But let us talk about efficiency: it iterates on each records on the domain, then, it computes some information. It is really worse for selection fields: it performs a fields_get for each iteration. This commit improves the situation by doing the fields_get only once. Note that this is not the end of the story: this only has a small effect on the performance of this method. It looks like there is a deeper issue in some cases (kanban view for subscription, field 'activity_state')
2019-01-29[ADD] web: server-side-rendered qweb templates as viewsXavier Morel
2018-09-05[FIX] web: read_progress_bar: convert dates to stringsAaron Bohy
Since rev. 960360af, Date (resp. Datetime) fields return datetime.date (resp. datetime.datetime) objects. This caused an issue in the read_progress_bar method which returns a dict, whose keys are values of the group_by. Indeed, when grouped on a Date or Datetime field, the key was no longer a string but a datetime.date or datetime.datetime object, and it crashed when that dict was turned into a JSON string. This method isn't tested at all for now, but tests will come shortly. Task 1878254.
2018-07-26[FIX] web: Make progress bar work with selection fieldsHiral Bhavsar
Purpose ======= The progress bar on a kanban column doesn't work with selection fields Specification ============= In kanban view, subgroupCounts of progressbar should work if columns are grouped with a selection field Currently, progressbar's subgroupCounts only worked if column is grouped by a 'Many2one' field. If column is grouped by a 'selection' field then its not working. For example, If column is grouped by a 'Many2one' field then we've tuple, {'state': (2, 'Signatures in Progress')} So, here for preparing progressBar values for subgroupCounts we'll get {Signatures in Progress: {overdue: 0, planned: 0, today: 1}} But for a selection field, we'll have a string 'sent' i.e a technical value, {'state': 'sent'} So here 'group_by_value' as a 'key' will never be matched as we have 'sent' instead of 'Signatures in Progress'. We've a technical value instead of its UI value and dict of subgroupCounts would be based on UI values that's why it'll never find values. To fix this issue we need to set proper 'group_by_value'. That's why added one condition for 'selection' field to gets its value of specific state inside 'read_progress_bar' method. Related to Task: 1862371
2017-12-18[FIX] web: fix progress_bar if grouped by date:intervalLucas Perais (lpe)
Before this commit, when grouping a kanban by date with a modifier e.g. crm.lead grouped by create_date:month A traceback was thrown on the python side bacause create_date:month was literally not a field After this commit, the progress bar in that situation displays well, at the price of copying bits of the read_group infrastructure OPW 785021
2017-09-14[IMP] web, *: add kanban column progress barsqsm-odoo
* crm, project Add a new feature which allows to put a progressbar in the kanban columns. The progressbar shows with the same color the amount of records whose value of a given field are the same in the column. It also indicate the sum of another given field or simply the total number of records. It also allows to subgroup the column content. To define a progressbar, add this as a direct child of the kanban arch: <progressbar field="<name of the field to use for subgroups>" colors="{<one possible value for the above field>: <success, warning or danger>, ...}" sum="<name of the field to sum or nothing to use total number of records>"/> Also: - Properly update record model data's parentID when moving a record - ...