This way when "full consumption detail" is used, consumptions that are on a possible variation that was not selected in definition are part of the consumption cell range and are still reported under this variation.

From Chromium 31, pressing enter key to select ListBox page submit the form
through JS (submitFormOnEnter) *and* wrongly on the default button, at the end
following HTML5 behavior (4.10.22.2 Implicit submission).

7d31f4fb allowed to prevent duplication of Component, as the ID was not enough,
for example when renaming a Component. As getUid() may trigger generation of a
new UID (and thus relying on portal_ids) and is protected by a non-reentrant
lock, it may deadlock when generating Component registry_dict while loading
Portal Types.

Expired categories should not be displayed

instead of a multilistfield because one is not supposed to choose more than one

The listbox could give more extra paramters like column id

otherwise login like 'ASTAIRE AND ROGERS' does not work.

otherwise login like 'ASTAIRE AND ROGERS' does not work.

Fix field name and description

Contributed by Jingjing Xu and Ni Yan.

This was a problem when using a brain as a ZODB component because an old
version of the class and module was kept as the _v_ attribute. The problem was
when the components where reseted

Before this change, an unconfigured Web Section would match all
available documents, which can be surprising (security would still apply,
of course).

Remove depth limitations on domain generator.
Make ListField item list generator present resource hierarchically (either
through indentation or through relative title-based paths, depending on
preference).
Also, share a bit of code between both.

We generating url to see list of task reports in task report module, we have to use
left joins to find out task reports with no items

Former behaviour for entry ('foo', None) was:
  <option value="value">foo</option>
With this change, it becomes:
  <option disabled="disabled">foo</option>
which was not possible to render before.

effective_date, when defined, prevents a document from being visible even
if it is in the correct workflow state.
Note that this is orthogonal with workflow states: a document which must
not be visible should not be in a workflow state which makes it visible to
begin with. effective_date only affects website-style document listing and
lookup.

As this means sorting had no effect, drop sorting on versions: versions
are arbitrary strings which can have any evolution scheme, so do not try
to guess what is more recent than something else.