Create a record management system like the document management

[GoogleCodeExporter]

This is a new capability that we have to create a record based on the contents 
of certain documents, and then allow other documents to update that record.

The idea is that a record, for example, may represent a client or employee, 
that is independent of documents that are processed around those entities.

To keep these records flexible, we'll likely base it on a special kind of 
Document that can be used to update the record data.  But this document will 
only update the record and not have additional processing logic -- no multiple 
documents, multi-parties, etc.  The idea is to just update the record that was 
either created directly or most likely, from a given transaction when a 
traditional document has been processed.

For example, and employee record might be created based on completing a new 
hire package.  A customer record might be created based on them signing an 
invoice or engagement letter.  Other transactions may then update that record.

Original issue reported on code.google.com by yoz...@gmail.com on 2 Jul 2014 at 6:49

[GoogleCodeExporter]

The current plan is to not do this as a separate type of "records" system.

Instead, we are creating a "data maintainer" pseudo-party that can update the 
data via the documents accessed via reports when the user has appropriate 
permissions.  With data updating allowed, users can fix bad data when 
necessary, but also can use a transaction much like a record, updating the 
values and saving them as needed.  This will reduce the need for multiple 
reports (one for transactions and one for records) as well as the additional 
special setup for record types, records, special documents for managing 
records, etc.

This will also allow for "live" document viewing so that a user can see the 
documents "live" (rather than just snapshots of previously completed parties), 
as well as the ability to update those documents when necessary.

Original comment by yoz...@gmail.com on 12 Aug 2014 at 9:46

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Added VIEW and UPDATE permissions to report templates that specify who is given 
access to "live transactions" without using a traditional party pickup.  By 
default, all such access will provide "view only optional" party access using 
the pre-defined esf_reports_access party.  Documents and packages may define 
this party specifically to allow for update access or to change what appears in 
a document when coming in via the reports.  The esf_reports_access party is not 
a traditional party in that it will never take part in the workflow, and can 
update transactions that are canceled or completed.  When the 
esf_reports_access party has been defined in a package, its definition will 
limit the documents allowed to be accessed (as well as further restricted if 
the report template itself limits which documents can be accessed), but the 
party will remain in a "completed" status, with the snapshots showing only the 
latest version of changes should they be done.

Original comment by yoz...@gmail.com on 11 Sep 2014 at 11:46

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Added to the 14.9.27 release.

Original comment by yoz...@gmail.com on 26 Sep 2014 at 12:03

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****