Since last FormBox behavior fix, the context needs to have View permission.
We allow to View for groups that has some permissions on the related delivery.
This way, users that has permission to solve divergences should be able
to get the form, fill it, update it and submit it.

to have security similar to related delivery,
this way, the user that is able to see the divergent delivery
is now also able to see the related solver process and solver
decision.

Without this rights, the user will not be able to solve any
divergences.

Especially, stop using getToolByName.

Id generator is too expensive to use for such trivial purposes.
Also, this was using an API of id generator which should never have been
added.
Also, this was bogus on several accounts:
- if the tag as provided by caller (as seems to be supported), then
  newActiveProcess would have used an unrelated tag.
- if the alarm activity fails and gets re-run later, the wrong tag will
  also be used.
Instead, generate the tag with a random value.

This allow to customize browser look.

Make the label, listbox, panel more readable.

2.0.3 could not be installed because 'version.txt' was missing.

* form_list: Jump, Actions, Add, Export, Fast Input
* form_view: View, Actions, Export, Previous, Next
* form_view_editable: View, Actions, Add, Previous, Next

This allow to keep the previous/next links in all mode.

Move the delete functionnality to the action page.

Tic'ing mid-hot-reindex is not possible, so immediate reindexation is
not avoidable here. Also, immediate indexation of just-created document
is acceptable, so this is not exactly a bad example.

Fixed commit was part of a larger commit stack, and this fix was
mistakenly squashed in an unrelated commit, and hence did not make it to
master.

Intercepting an indexation activity is not reliable, as multiple indexation
activities may have been spawned, and the wrong may be intercepted here.
So instead, explicitly unindex the document intended to not exist in
catalog.

This is a very minimal support, as "flush" is kind of deprecated, only
surviving because tests need to be able to tell which activity may
execute, and there is currently no other way to support this.

Avoids logic duplication on how to store the environment.
Avoids relying on ERP5 products (for whatever it's worth anyway).

Also, simplify docstring.

Only PluggableAuthService import may not be importable, and is decisive
in importing from ERP5Security, which must then work.

Just like age is taken into account inside each activity queue.

Increasing priority value (hence making the activity execution priority
lower) means that all previously-spawned activities will have at least
started execution before the next batch of activities begins being
prepared. During that preparation, more activities will end, meaning there
is then unused processing node time, decreasing processing efficiency.

By making re-call activity have the same priority as spawned activities
will reduce this delay by making the re-call activity candidate for
execution at the same time as the latest activity batch, without leading
to activity queue size increase: older activities within a given priority
range still get precedence, so any older group will tend to finish before
more batches get spawned.

Measures on indexing 700k documents with 20 activity nodes:
- priority + 1: 84k documents indexed in the first 5 minutes,
  47k in the last 5 minutes. Average: 64k/5 minutes
- priority: 101k documents indexed in the first 5 minutes,
  97k in the last 5 minutes. Average: 99k/5 minutes
Peak speed (which is the initial speed) is 20% higher.
As the slowdown rate (likely coming from lower-priority activities piling
up in the message_queue table) is also much lower in the second case
(900 fewer documents indexed on each 5 minutes increment instead of 4k),
the overall average speed improves by 54%.

fckeditor is clever enough to render the content, properly isolated from the main web page

/reviewed-on nexedi/erp5!565

It is usable for activity nodes where we need activity processing (i.e.
tic) to happen much faster that normally (default is 5 seconds).

It has been successfully used in a production system for months (and big dev instance)  despite not done in generic line now proposed.

@nexedi , any objections for not having this in a generic ERP5's timerservice?

/reviewed-on nexedi/erp5!562