Use setDefaultTelephoneCoordinateText and getDefaultTelephoneText to be consistent.

In the same time, remove sortable columns since ActivityTool does not offer
possibility of sorting.

erp5_web_renderjs_ui: moved some forms and scripts to portal_skins/erp5_web_renderjs to make layout_config and jslint view available in non-web mode.

See merge request !6

erp5_web_renderjs_ui: moved files to portal_skins/erp5_web_renderjs to make layout_config and jslint view available in websites and webpages modules

remove accidentaly put acquire_local_roles
dccb74ee

Live tests was sometimes not working because of data remaining from other tests

For now, enable fast inputs for items on mrp movements, and add aggregate view on mrp deliveries

Use infinite number of lines in listbox to avoid UI limits

There should be no reasons to look at items through aggregate only on delivery line,
this should also be usable on order lines

proxify and set more columns

Make sure that catalog knows portal_type column and reference column. If catalog does not know those columns, then it will fetch all cataloged objects and will cause memory bloat. This can happen when MariaDB server disk is full.

Before, reindex was not called when you changed only a [Multi] relation field. So
it was possible to have SQL data not up to date after a change by user.

Though, most of the time this was not an issue. Usually relation fields
calls Base_edit. And even if there is no change and no reindex done by edit itself, since we
often have edit_workflow associated to documents, we usually have a reindexing.

But since we should keep the usage of edit_workflow optional, we have to call proper
setter to make sure to have updated SQL data.

test was lost in merge / rebase

For some projects, it could be very useful to setup multiple supply line directly at ressource
level. Therefore make the user interface supporting it. Though, for project not using multiple
supply per ressource, the user interface will not change (listbox appears only when there is
multiple supply lines)

If a transaction has the same source section and destination section, there was a risk of showing the wrong side of the transaction. Test that both section and nodes are the same instead. There is still a risk, of showing something wrong if source and destination are also same, but such transaction would be non sense anyway.

A previous operation might have poluted the request