• BlogApp
• BugReporterApp
• Calendars
• Community Dev Project basics
• EmailPageChangePlugin
• File Cabinets
• ForumV2
• MyContactsApp?
• Photo Pages
• Related Tags Plugin with Dynamic Display?
• Spreadsheets
• Tagging Library

Template Configuration EzConfig 3

Document Copy Enhancements 4

Document Configuration Retrieval API Changes 5

Document Security 6

Document/Template UI Labels 7

Data Service Layer Changes 8

New Document UI 9

Template Configuration EzConfig

Following points cover the understandings regarding Template’s configuration:

• Template will share structural/display configuration with its associated Document Type i.e. PO Template and PO will share same structural/display configuration.

• Document Type > Template Document Type mapping needs to be maintained either one can store it in a EzConfig database table or some hard coded mapping properties file can be used as this data will very rarely change and has to be configured for once only.

• As template configuration is not editable by user so on EzConfig UI there will be no interface to view Configuration of Template Document Type. In case User wants to explore the structural configuration of a Template document type then he can view the respective Original Documents configuration. For ex to check structural configuration of Container's Template type one can view Container's document configuration.

• Nothing will be done when a EzConfig document type is published to savaria as the same configuration is shared by both Template and Document Type.

Document Copy Enhancements

Document Copy will have to treat template copy bit differently. To support copy of template data to a document instance following enhancements will be needed:

1. Right now Doc Copy always creates a new Document Instance after copy operation, but for template copy feature Doc Copy has to support coping of document data repeatedly over existing document instance i.e. User can copy multiple templates over same document instance.

2. Doc Copy now need to avoid coping DOC_HDR attributes (*properties) from template to document. This is because coping header attributes of template like template name and template date over primary reference and primary date doesn't make sense and in case coping multiple templates over same document instance may create problem in this header *properties copy case.

3. While coping template data Doc Copy has to avoid coping of NULL/Empty Doc Objects from template to source document instance.

Document Configuration Retrieval API Changes

Document structural/display Configuration is fetched using API exposed by savaria module named documentcfg_1_0. This configuration is needed mostly by document UI rendering code and by some other modules like Doc Copy, Recon etc. Here a Session Bean named DocCfgMgrBean exposes following methods to fetch document's structural and display configuration.

/**

* Returns the structural configuration of a document. First checks cache, if not available retrieves from database, then puts it in cache and returns it.

*/

public com.tradebeam.document.cfg.DocDisplayCfg getDocDisplayCfg( long displayGroupType,long domainId,long documentTypeCd )

/**

* Returns the structural configuration of a document. DocDisplayCfg retrieved in this method is not cache driven. Either don't use it or use the other method which returns DocDisplayCfg by groupType.

*/

public com.tradebeam.document.cfg.DocDisplayCfg getDocDisplayCfg( long domainId,long documentTypeCd )

/**

* Returns the structural configuration of a document. First checks cache, if not available retrieves from database, then puts it in cache and returns it.

*/

public com.tradebeam.document.cfg.DocCfg getDocCfg( long domainId,long documentTypeCd )

Our plan is to change these methods in following manner:

1. When a Document Type's structural/display config is requested by this API it will behave as its doing right now i.e. No changes to be done here

2. When a Template Document Type's structural/display config is requested by this API it will first identify the mapped Original Document Type for this template doc type. Then respective configuration of the Orignal Document is loaded and the Configuration Object will be changed to only replace Orignal Document's Document_Type_Cd with the Document_Type_Cd of Template Document Type for ex. For Shipment [DocTypeCd:209225] the ShipmentTemplate [DocumentTypeCd:209229] is configured. API is called to load configuration for ShipmentTemplate like getDocCfg(1000, 209229). Now API will lookup the mapped document type to ShipmentTemplate in this domain and that is Shipment[209225]. So it will fetch configuration for Shipment and update attributes of loaded configuration objects like DocDisplayCfg or DocCfg to have document type cd's changed to 209229 from 209225.

Document Security

Here we can have two options to implment

1. One mentioned by RaviJ in Design Discussion document as “update the security model’s retrieval api’s so that when a template doctype is passed in, it returns the security of the parent document”.

2. Or If we want to establish a parent child relationship in secured resource we can do that also. Means for Container Secured Resource Name is “document.container.management” and for Container Template we can have a new Secured Resource named “document.container.template.management”. Here parent secured resource for this secured resource “document.container.template.management” will be container's secured resource “document.container.management”. Here the benefit we will get is if we want only Admin to manipulate/create templates then we will give CREATE/DELETE permissions on both parent and child secured resources to Admin. But for normal user only READ/ACCESS permission will be granted so he can only view the templates and apply them and hence he will not be able to change/create new templates. This secured resource relationship is also shown in figure below.

3. F
   ield and Data level security will be applied to the Template document type in the same way as per the configuration of Original Document Type.

Document/Template UI Labels

On Document's UI two DOC_HDR fields will be shared with templates. The Primary Reference and Primary Date will come in normal fashion on the Document UI with the labels configured for them for there respective document type like for Container it might come like Container Number for primary reference and Document Date for Primary Date.

But on a Template Document UI the labels for these two fields will be changed. Now primary reference will be used internally to hold TEMPALTE NAME and primary date will be used as TEMPLATE DATE. So this can be achieved without code change by using the existing way to retrieve these labels from dictionary. Right now for rendering a label for primary reference the document UI rendering code creates a dictionary key as follows

KEY = “struct.id.” + DOCUMENT_TYPE + “.”+ *_PROPERTY_NAME

so for creating Container's primary reference UI label the KEY will be

KEY = “struct.id.” + 2000781 + “.” + “primaryReference”

or

KEY = “struct.id.2000781.primaryReference”

Dictionary Value for this key = “Container number”

similary other labels are configured for container as below

DICTIONARY_ITEM_ID VALUE

struct.id.2000781 Container

struct.id.2000781.docVersionNo Version No.

struct.id.2000781.primaryReference Container number

struct.id.2000781.docSubtypeCd Shipment Type

struct.id.2000781.primaryDate Document Date

struct.id.2000781.docStatusCd Status

struct.id.2000781.hotStatusCd Hot Status

The similary dictionary configuration is done for every document type in savaria right now. So we have to create same dictionary configuration for new Template Document types also. And here to get Template Name and Template Date we can just change the dictionary configuration for the Template Document Type as follows.

DICTIONARY_ITEM_ID VALUE

struct.id.2000783 Container Template

struct.id.2000783.docVersionNo Version No.

struct.id.2000783.primaryReference Template Name

struct.id.2000783.docSubtypeCd Shipment Type

struct.id.2000783.primaryDate Template Date

struct.id.2000783.docStatusCd Status

struct.id.2000783.hotStatusCd Hot Status

NOTE : 2000783 in above table is Container Templates Document Type

Data Service Layer Changes

As new Document Types will be introduced for template types. So we are assuming that Data Service Layer team will handle management of these new document types.

Review Comments :

New Document UI

Kris is working on new document user interface for documents. So we need to know how Template Management Use Cases for Document UI change will be implemented on this new Document UI.

Review Comments :