- Tested on an instance which DOM seems to be different than
  default one.

This reverts commit b8f34d3c.

tl;dr currently function/forum/{administrator,user} are mapped to Author
      only role on forum module without also mapping to Auditor role.

      Auditor role is needed because by definition Author cannot view
      content and without such role Admin & User cannot see
      DiscussionThreadModule at all.

      Similarly besides having Author role, Users also need to have
      Auditor role on DiscussionThread in order to view threads.

Currently for DiscussionThreadModule we map categories

    function/forum/administrator    and
    function/forum/user

to one Author role in A5 speak.

Then, for forum, it is assumed that each user will be assigned only one
functional category to each user (e.g. only one of
function/forum/{administrator,user,visitor}).

So it turns out e.g. function/forum/administrator category is mapped to
only Author role on DiscussionThreadModule.

Now by definition Authors can create documents, but they cannot
access/view them (as per http://www.erp5.org/ERP5SecurityModel).
This is also indirectly justified by default-assigned security settings
for Author role - see section "Adjust Permissions on the Module" -
Author is not allowed to "View".

    So if forum administrator is only mapped to Author role, he can
    _not_ view/access the forum module.

And I discovered this exactly this way - usual visitors (who map to
Auditor role) were being able to see the module, but admin and users
could not.

To solve this logically, lets also map

    function/forum/administrator    and
    function/forum/user

to Auditor role on DiscussionThreadModule (i.e. they now both map to
Author & Auditor). And now both admin & user can access/view the module
& create threads.

Similarly without Auditor role on DiscussionThread, User cannot view it.
( And Administrator has Assignor on DiscussionThread which allows viewing
  by itself )

NOTE for DiscussionPost we don't need to change anything in order for
users to view it because DiscussionPost acquires local roles.
Helped-by: Klaus Wölfel <klaus@nexedi.com>

Factorise code paths between simulation and "real" modes,
fixing occasional non-representativeness of simulation mode.
Factorise code (down from 300 to 200 lines).
Simplify code (ex: use set instead of None-value dict).
Merge consecutive loops:
- delete/expire immediately instead of building a list to process later
- process each Base Category entirely (create, edit, delete/expire/keep)
before going to the next
This merging should overall reduce memory usage significantly.

- Two methods defined twice with the same code in the same script

- original script removes security_uid which are referenced on group_id_security_uid fields

This reverts commit 8e7737c1.
No longer needed since mirror_section_relative_url is now a brain
attribute

They were useless since 'delivery' is indexed in ZODB, and this also fixes
a bug causing local build to fail in the following conditions:
- root document moved to a state that triggers a builder,
  whereas there's no simulation tree yet
- the builder select method has a condition on the root simulation movement

An example is building of task reports, when the ERP is overloaded.

The reason was that in some cases, ERP5 tried to set 2 tags on the same
reindexing activity (built: in updateMovementCollection & expand: in
_updateSimulation), but there's actually no support for multi-valued tags
and for CMFActivity, default activate parameters (here expand:) have lower
precedence (see ActivateObject.activate). So another possible fix is to add
built: to _localBuild after_tag.

This commit also renames expand: into build:

erp5_code_mirror: Refresh Component history revisions (used for merge mode) when saving with CTRL+s.

Translate "I forgot my password!", "Input data has errors. Please look at the error messages below.", "Input is required but no input given.", "No such document was found.", "You did not enter a valid date and time.".

AccountingTransactionLine_checkGroupingReferenceIsValid: We are not supposed to group if the section is a person

- Too slow because it takes same time than the search_method.
- The count is made durring the search thank to LIMIT 1000;
- The search LIMIT 1000 takes same time than LIMIT 30;
- The search LIMIT 1000 stays in cache, so going to next page is almost instant.

The task of moving those to delivered state is only due when closing the period, so this worklist is not needed. Also it is slow to generate as it matches many documents.

External BOSH server is requested to use it.

I guess nobody remember psyco

This is mostly to prevent starting when some products cannot be imported