Page Comparison

...

Document Types

• New document names should be consistent with existing KFS documents (e.g., use hyphen for name like Sub-Account)
• Do not use Kuali in the name.
• Do not use the module in the name. (Unless needed to differentiate from a similar object in another module.)
• Do not abbreviate.
• Business object and document class names must be unique across the system.
• Look for naming conflicts and draw the document type approvers attention to them.
• THIS NEEDS UPDATING When you are adding a document type, a help parameter needs to be created to match. You do not need to specify a value. You need to create a jira in the KFS Documentation Feedback queue to ask the help folks to create the help and update the param with the correct value (Issue Type: Other / Component: Online Help). These parameters require approval like any others. Standard is that the name should match the component with the following changes: replace camel caps with underscores, and capitalize all letters. The same guidelines go for renaming of document types. Make sure the doc type table, the workflow doc type definition, and the help parameter are updated and old data is cleaned up. When you are making significant modifications to a document type, you are responsible for notifying the help team via the KFS Documentation Feedback queue.
• Transactional Document Types
  • Should be child of workflow document type parent for module
  • Java document class name = document data dictionary entry name and ends with "Document", e.g. TransferOfFundsDocument
  • Label in document data dictionary entry = label in workflow document type = link in portal and is the class name minus the "Document" suffix and with spaces between the words, e.g. Transfer Of Funds
    
• Maintenance Document Types
  • Two potential parents
    • Complex Maintenance Documents: Generally are maintainable by most users and route for review. 
    • Simple Maintenance Documents: Generally are maintained by Central Admin and do not route.
  • Java business object class name = business object data dictionary entry name
  • Document data dictionary entry name = workflow document type name and is business object name and ends with "MaintenanceDocument", e.g. ObjectCodeMaintenanceDocument
  • Object label in the business object data dictionary entry = label in document data dictionary entry = label in workflow document type = link in portal and is the business object class name minus the "MaintenanceDocument" suffix and with spaces between the words, e.g. Object Code

Parameters

General Guidelines

• Look at other similar parameters and try to be consistent.
• Do not abbreviate.
• Names must be in all upper case.
• Use underscores to separate words e.g. NUMBER_OF_DAYS_USED_TO_CALCULATE_DEFAULT_PAY_DATE.
• The list of valid values for component/detailed type is built from what's actually in KRNS_PARM_DTL_TYP_T, the simple name of all business object classes, the class names of all documents, and the names of batch steps in spring. Please make sure that you either consult these sources or use the component lookup when deciding what component should be used.
• Refer to entities by the same name under which they are listed in the component/detailed type lookup (substituting underscores for case changes).
• Avoid the use of the words VALID, INVALID, ALLOW, DENY, and RESTRICTED, unless otherwise specified below. The constraint column should account for that information.
  • Caveat: If the code does not use the constraint parameter, then use of one of the above words may be applicable.
• Always provide a good description. Do not leave the description blank and do not copy from another, unrelated parameter. Do not duplicate information in the other fields that may change, e.g. do not describe as valid values when that could be changed by a user changing the constraint. If it makes sense, refer to the part of the application which uses the parameter so it's easier to find the usage of a parameter.

Guidelines for Specific Parameter Types

• Parameters that can have a value of Y or N should have a suffix of _IND.  (e.g. SHOW_CONTINUATION_ACCOUNT_WARNING_FISCAL_OFFICERS_IND.)
• If a parameter can contain a list of items, it's name should be pluralized. (E.g., COST_SHARE_OBJECT_TYPES)
• When defining restrictions on one value (the constrained value) based on another value (the constraining value), i.e. creating a compound rule, you should create two parameters. You will usually want to use the terms VALID and INVALID to distinguish between the allow and deny parameters. But, we also have examples where INCLUDE and EXCLUDE make more sense, and one case of even more custom naming (as you can see from the example). Users should still be able to find all of these compound rules by search for name like *BY*. The format of the parameter values should be "constraining value 1=constrained value 1,constrained value 2;constraining value 2=constrained value 3,constrained value 4,constrained value 5;...".
  
  • <optional grouping prefix>-VALID_<name of entity associated with constrained field>BY<name of entity associated with constraining field>, e.g. CG_ROUTE_OBJECTS_BY_CHART
  • <optional grouping prefix>-INVALID_<name of entity associated with constrained field>BY<name of entity associated with constraining field>, e.g. NO_CG_ROUTE_OBJECTS_BY_CHART.
• When defining what the value of one field (determined field) should be, based on a the value of another field (determining field), you should create one parameter. The format of the parameter value should be "determining value 1=determined value 1;determining value 2=determined value 2;...".
  • <optional grouping prefix>-<name of entity associated with the value that is being derived>BY<name of entity associated with the value that is determining the value that is being derived>, e.g. NRA_TAX_FEDERAL-OBJECT_BY_INCOME_CLASS
• If you are creating a run indicator of user parameter for a batch step, the name should be RUN_IND or USER. By default steps will run and a session will be created for the system user, so you only need to specify these when you do not want a step to run or you want it to run as another user.

Standard Parameter Name Suffixes

Other Data

• New route node names should be consistent with existing.  In some cases, you should actually use an existing name where the same type of routing is being done on another document.
• New role, permission, responsibility, etc. names and descriptions should be consistent with existing.
• Permissions and responsibilities shouldn't be created for new doc types if the hierarchy already covers it.
  • For example: the blanket approval permission isn't necessary for each new doc type.
• KIM Types that are for derived roles need to say "Derived Role: " as part of the Name.
• Permission names should always be "{template name} {attribute values in order defined in KRIM_TYP_ATTR_T}" unless the template is KUALI Default; in that case, the name of the permission is free form to match what it actually does
• Responsibility names should always be "{template name} {document type} {route node name}".