Most listbox functionnalities are not supported by web_js_style for now, as no form is used by default

Their contents is already provided by the HTML page template.

Generate a hfeed in the HTML rendering.
https://indieweb.org/feed

Provide a RSS feed automatically.

Only generate the feed when rendering the web section in view mode.

Extract all feed informations in Javascript to allow styling it as a blog.

Add bt5 dependency to erp5_dms to retrieve the author title.

This allows called script to call script on them

This stopped working when the signature of Message.__init__ changed in
06aee0c2 (CMFActivity.ActivityTool: Use uid for identity check instead of
oid., 2019-09-17)

"Access Tool" sounds like a tool to access, but this setting is about
giving access to ERP5 tools from the module list.

See merge request nexedi/erp5!1509

See merge request nexedi/erp5!1510

we have such error:
....
if context.getValidationState() in ["draft", "deleted", "cancelled", "archived"]:
  Module Products.ERP5Type.Accessor.WorkflowState, line 60, in __call__
    return wf._getWorkflowStateOf(instance, id_only=1)
  Module Products.ERP5Type.Core.Workflow, line 609, in _getWorkflowStateOf
    state_id = 'state_' + status.get(self.getStateVariable(), None)
TypeError: cannot concatenate 'str' and 'NoneType' objects

This stopped working long time ago, probably with slapos commit aa102f28f
(erp5testnode: use newer shellinabox, with a caddy frontend, 2018-09-21)

Web Site/Section were still indexable when rendering in xhtml style.

See nexedi/erp5@6c5db57b

See merge request !1504

See merge request nexedi/erp5!1508

using parallel list fields cause HTML to be very big and is not good
for usability, because we typically select a lot of values in these fields.

This can sometimes be useful during development

See merge request nexedi/erp5!1502

ERP5ReportTestCase also import ERP5TypeTestCase, so if we reload it it
patches again getRequest to a function calling itself and causing
RecursionError.

See merge request !1505

If ignore_layout=1 is present in url query, static web section show the default view so user can modify properties

But for url like
https://erp5/web_site_module/static_web_site/web_page_module/111?ignore_layout:int=1&portal_skin=Slide...
static web section should do redirection instead of showing the default view

It's difficult to distinguish if it should do redirection or show the
default view for all kinds of url

To make it simple, if portal_skin is present in url query, static web
section will do redirection event if ignore_layout is present

See merge request !1486

See merge request !1498

Double translation happened when:

- For sql_catalog.isValidColumn(name)
- When search_columns is empty
- When selection_sort_order and sort_columns are empty

So delaying translation on column titles until *_column_list are finalised.

Before this fix, double translation on Sale Order title was happened every time
displaying a Sale Order Line, for example.

Category spreadsheet import did not delete categories if some documents
where related to these categories. While this may make sense when using
this import in site with already some data, in many cases, we want to
be able to delete the categories, so that the result is that the category
tree match the imported spreadsheet.

This extend the dialog to support a new "force delete" mode that delete
categories even if they are use, leaving the documents using categories
with broken relations.

Spotted when comparing this code with ZPublisher.Publish.

Once a response has been written to, the status and headers are supposed
to have been sent over the network. So any future change to them is moot.
Likewise, setBody does nothing: only write can continue appending to the
existing body.
As in the case of WSGI the response does not actually get sent just yet:
- lock the body
- store finalize() result
Also, make the order in which body and stdout are returned consistent with
HTTPResponse: body is returned first (as part of HTTPResponse.write's call
to self.outputBody, which calls self.__str__, which emits body), and then
stdout content.
Also, add support for cases whre the existing body is a file or an
IUnboundStreamIterator.

err_hook may re-raise when it is specifically told not to render an error
page. Such exception does not mean err_hook failed, so it should not be
re-raised by WSGIPublisher: re-raising in WSGIPublisher means handing the
exception over to waitress, which will have no other choice than producing a
generic error page that we have no control over.

Transaction must be aborted even if the state is getting so bad that the
exception is being re-raised. Leaving an open-ended transaction is never
acceptable.

MariaDB seems to be using inconsistent lock acquisition order when
executing the activity reservation queries. As a consequence, it produces
internal deadlocks, which it detects. Upon detection, it kills one of the
involved query, which causes message reservation to fail, despite the
presence of executable activities.
To avoid depending on MariaDB internal lock acquisition order, acquire an
explicit table-scoped lock before running the activity reservation queries.

On an otherwise-idle 31 processing node cluster with the following
activities spawned, designed to stress activity reservation queries
(many ultra-short activities being executed one at a time):
  active_getTitle = context.getPortalObject().portal_catalog.activate(
    activity='SQLQueue',
    priority=5,
    tag='foo',
  ).getTitle
  for _ in xrange(40000):
    active_getTitle()
the results are:
- a 26% shorter activity execution time: from 206s with the original code
  to 152s
- a 100% reduction in reported deadlocks from 300 with the original code
  to 0

There is room for further improvements at a later time:
- tweaking the amount of time spent waiting for this new lock to be
  available, set for now at 1s.
- possibly bypassing this lock altogether when there are too few processing
  nodes simultaneously enabled, or even in an adaptive reaction to
  deadlock errors actually happening.
- cover more write accesses to these tables with the same lock

From a production environment, it appears that the getReservedMessageList
method alone is involved in 95% of these deadlocks, so for now this change
only targets this method.