We don't care about creating (and possibly fetching informations to server) Partition object if we don't do anythign with it.

Data can be really complex string, which can be bad for tag.

Data can be really complex string, which can be bad for tag.

getFullComputerInformation is being used, so there will be no empty response.

Instance Setup delivery is immediately delivered.

getSoftwareReleaseList is updated by getFullComputerInformation call, which
returns everything, even destroyed (and theoretically forgotten) software
releases.

This will allow portal_deliveries/vifib_sale_invoice_builder to put movements
on prepared invoice.

There will be such delivery, as side effect of automatic bang.

One for "State changed from draft to start_requested"  and second one for
"Parameter changed".

There is more work to do then confirming invoice.

This follows alarm configuration, which just moves empty (stub) invoices for
next month.

This allow to work in case of Slave Instances.

If partition has related instance, send all required data and "trick" client
side that document is already synchronised.

Basically it reuses bang timestamp, which is controllable property, unlike
getModificationDate

Also update timestamp on each bang.

There are subobjects which do not provide validation state, which can endup in
acquisition of dangerous methods.

It allows to use catalog for searching.