Allow to change some values when a document is completed
Description
Hi,
Actually, if you discover that a value is wrong on a completed document (date, charge, ...), you have to void/reverse it and create a new one with the correct values. This generate lots of useless things (document and facts).
An option could be to allow reactivation on document but it could be tricky to code something which will be cover all tasks done in model validator or events.
@Carlos Ruiz has started to develop something that could fit the need, the 'Special Editor'.
It allows developers to specify :
which fields can be updated once the document is completed
what must be checked before modifying it
what must be done after the update is done
I've started to play with it and i guess everybody will like it.
The idea is not too complex, and the attached proof of concept is 100% OSGi based:
no dictionary changes would be required to support new fields
new fields with specific business logic can be supported adding extensions
the new toolbar button can be hidden per role or system wide
To implement support for special edition on a new field we would need to add an extension for that field, and implement the interface ISpecialEditCallout
This interface would have the following methods:
canEdit: to check conditions to allow the edition of the field - it can be several callouts per field, to be editable all of them must return true on this validation
validateEdit: can be used to add some validations for the field being changed
preEdit: this would be called when the user change the field and push the OK button - intended for example to set the required prerequisites - like unposting a document
updateEdit: intended to be called after preEdit, this could hold special code in case the value of a field cannot be modified directly (for example, the beforeSave triggers usually catch and forbid changing values for a completed document)
postEdit: intended to be called after updateEdit, to update the consequences of the change - for example reposting the document
NOTE: The attached code was used to get the screenshots - but is just a template - no code to support the changes have been written.
Carlos is ok to share the code. Thus everyone could try it and share ideas.
Hi,
Actually, if you discover that a value is wrong on a completed document (date, charge, ...), you have to void/reverse it and create a new one with the correct values.
This generate lots of useless things (document and facts).
An option could be to allow reactivation on document but it could be tricky to code something which will be cover all tasks done in model validator or events.
@Carlos Ruiz has started to develop something that could fit the need, the 'Special Editor'.
It allows developers to specify :
which fields can be updated once the document is completed
what must be checked before modifying it
what must be done after the update is done
I've started to play with it and i guess everybody will like it.
The idea is not too complex, and the attached proof of concept is 100%
OSGi based:
no dictionary changes would be required to support new fields
new fields with specific business logic can be supported adding extensions
the new toolbar button can be hidden per role or system wide
To implement support for special edition on a new field we would need to
add an extension for that field, and implement the interface
ISpecialEditCallout
This interface would have the following methods:
canEdit: to check conditions to allow the edition of the field - it
can be several callouts per field, to be editable all of them must
return true on this validation
validateEdit: can be used to add some validations for the field being
changed
preEdit: this would be called when the user change the field and push
the OK button - intended for example to set the required prerequisites -
like unposting a document
updateEdit: intended to be called after preEdit, this could hold
special code in case the value of a field cannot be modified directly
(for example, the beforeSave triggers usually catch and forbid changing
values for a completed document)
postEdit: intended to be called after updateEdit, to update the
consequences of the change - for example reposting the document
NOTE: The attached code was used to get the screenshots - but is just a
template - no code to support the changes have been written.
Carlos is ok to share the code. Thus everyone could try it and share ideas.
Regards,
Nicolas