GitLab

This was removed from products in previous commits

When `Form.proxifyField` is used to make a proxy field from a field which has only a TALES and no value, it creates a proxy field with inconsistent internal data structures where `has_value` method does not work as expected. As a consequence, proxy fields to list fields are often broken in the ods/odt rendering.

Here is a scenario to reproduce the problem:

* add `Base_viewDummyFieldLibrary` ERP5 Form
* add a `LinesField`, with id `your_test_base_field`. Change `size` to 1 (not really required but I did this in screenshots here)
* add another `LinesField`, with id `your_test_field` and in this field:
   * set a `default` (`2`) in values, it's only needed to visualise the problem in ods style:
![set default and no items](/uploads/0cb9e229b0ca6761bb15f3d8845ea3f8/image.png)
   * set `items` in TALES (`python: [('one', '1'), ('two', '2')]`) , this will be the problem
![set items in TALES](/uploads/93d90f57e15afdcca60324675b59086a/image.png)
 * So far,...

Try to support displaying web js site from google cache,
which can not access original gadget, due to cross origin ajax query forbidden.

Display original content instead and load the default CSS in such case.

Most ERP5 web sites use a global form wrapping the content.
Modify the html viewer to not drop this content.

Stop using ck_editor in read_only to display HTML.

This allows to get rid of the ck_editor iframe, allowing a faster load and removing the iframe scroll.
The maximise button is no more needed in such case.

It also removes all ck_editor links handling: links can be open in another browser tab now.

This changes impacts both xhtml style and erp5js.

This gadget take an HTML string as parameter.

It first cleans it up (with hardcoded behaviour currently) by dropping unknown tag elements, unknown/unsafe tag attributes.
It is another protection layer on top of asStrippedHTML inside ERP5.

Then, it displays the output HTML and style it with an hardcoded set of rules.

erp5_ui_test: check empty percent

fixup! erp5_web_renderjs_ui_test: cover case of orange highlight not displayed in rjs_gadget_erp5_emailfield_js with test

erp5_web_renderjs_ui_test: cover case of orange highlight not displayed in rjs_gadget_erp5_emailfield_js with test

store error_text to be propagate to render()

This allows crawlers like wget to also fetch the rendering gadget without executing any JS

See merge request nexedi/erp5!1344

For now this only checks that every entries in .tales are also in .values
so that .has_value works as expected. This also supports repairing the
structures with fixit argument.

We could check more, because there are other problems with proxy fields
internal structures:
 - sometimes some keys are in .values / .tales but not in .delegated_list
   this seem to happen after changing the target to a field of a different
   type, with different keys.
 - .delegated_list are not always sorted

The internal data structures are made of two dicts: .values for values and
.tales for TALES. Formulator expect that these two dicts have keys for all
properties, because of the implementation of Field.has_value which checks
for the presence of the key in .values

When making a field with only TALES, this method was setting the value only
in .tales but the same key needs to be present also in .values, otherwise
get_value would return False for this key.

For same reasons as 5b1c03c8 (sort delegated lists to make proxy field
representations more stable., 2009-05-18)

This was not much tested

This will be needed for DCWorkflow to ERP5Workflow migration so this will be
a core Document and make bootstrap easier.

Nowadays Line Report works fine in ERP5JS. It is also useful in context of MRP.

See merge request nexedi/erp5!1347

This shows the asset price from `stock.total_price` which can be just the
movement prices or the evaluated prices if getDestinationAssetPrice and/or
getSourceAssetPrice type based methods are defined.

erp5_trade contains Base_viewTradeFieldLibrary which contain
my_dialog_mode_portal_type, which is a multi list field where user can
select multiple lines portal types. It is used in
DeliveryModule_viewDeliveryLineReportDialog/your_portal_type

erp5_item also contains Base_viewTradeFieldLibrary , for cases where
erp5_item extend trade module to select items. It also contains a
my_dialog_mode_portal_type field, where user can select item portal type.
That field is not a multi-list field, but a list-field. It is used in
DeliveryLine_viewSelectItemListDialog

So when erp5_item is installed, it overrides
Base_viewTradeFieldLibrary/my_dialog_mode_portal_type with a list field
instead of a multi-list field and breaks
DeliveryModule_viewDeliveryLineReportDialog, because user can no longer
select more than one portal type.

This renames the field in erp5_item, now we have:
 * Base_viewTradeFieldLibrary/my_dialog_mode_portal_type for movement
portal types
 * Base_viewTradeFieldLibrary/my_dialog_mode_item_portal_type for item
portal type

Until now it was only used in ERP5Catalog where the expression property is
`expression` for both Python Script and SQL Method but this is a common pattern
and will also needed for ERP5Workflow.

Instead of generating the report in one big activity, split the calculation
in several batches, so that the processing can be distributed on zope nodes.

The limit for the number of lines was also increased from 10000 to 100000

Using an absolute URL for gadgets cause the gadget to have a different URL
per language when the web site uses "Language in URL" feature.

Using absolute URL is not good for cache and also it seems to cause
incompatibilities with recent versions of ERP5JS. Using relative URL is
what we usually do, it does not have cache problem and works fine.

These modules contain movements and this export is a generic export usable
on any movement type, that can also be useful in MRP modules.

This was enabled in all order/packing lists modules from trade except this one.