Hide all unnecessary fields for adding a simple blog message as adding is done usually by a site member not site manager and it was quite complex (by default blog message is submitted for approval side manager can correct errors if any).
Try to guess all possible values from parent Web Section and generate nice reference from title.
Do not manually set contributor list as this is done in a generic way by a workflow.

update script:

ALTER TABLE `catalog`
DROP INDEX `validation_state`,
DROP INDEX `simulation_state`,
DROP INDEX `causality_state`,
ADD INDEX `validation_state_portal_type` (`validation_state`, `portal_type`),
ADD INDEX `simulation_state_portal_type` (`simulation_state`, `portal_type`),
ADD INDEX `causality_state_portal_type` (`causality_state`, `portal_type`)

To update:
ALTER TABLE `stock` DROP INDEX section_uid, ADD INDEX `section_uid_portal_type` (`section_uid`, `portal_type`)

Update with:
ALTER TABLE `translation` DROP INDEX `portal_type`, ADD INDEX `type_translated_message` (`portal_type`,`translated_message`);

update with:
ALTER TABLE `inventory_stock` DROP INDEX `resource_uid`; -- exists in resource_node_uid
ALTER TABLE `stock` DROP INDEX `resource_uid`; -- exists in resource_node_uid

update with
ALTER TABLE `predicate_category` DROP INDEX `FuzzyMembership`; -- exists in Membership

update with:

ALTER TABLE `versioning` DROP INDEX `expiration_date`;
ALTER TABLE `versioning` ADD INDEX `expiration_date` (`expiration_date`);

also remove now useless related key (should have been part of former commit)

use HTMLParser instead of SGMLParser (cf. 0952bee6).

- wrong default uid was used when migrating a site that never use portal_ids
  to generate security uids
- invalidate transactional cache of security uids

This way validator scripts will be called even for empty listboxs, and this
should also remove ERP5Form/Form.py:validate_all KeyError : 'Field listbox is
not present in request object.' messages from the logs

In the first dialog you still select which action to do on which objects, now
you can only select one action. The second dialog is the actual dialog from the
workflow rendered on the context of one document from documents grouped by
state and portal type. This means that if the workflow uses a custom dialog to
set workflow variables, this dialog will be shown and the variables will be
passed to all documents.
Of course some workflows dialog fields have no meaning in a multi-document
transition, that's why there is a mass_workflow_action=True request parameter
to detect this situation and behave accordingly in such case.