Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Certain changes to KFS require pre-approval. These include configuration changes, database changes and workflow changes. Please see below for more details on these types of changes, including who needs to approve and the format for approval requests.

All requests should include the relevant JIRA and a brief justification of the changes. A given request should only refer to one JIRA and contain information pertinent to / be sent to one set of approvers. If you need to make requests related to multiple JIRAs or requests to multiple sets of approvers related to one JIRA, break things up appropriately into separate emails.

KFS Configuration Changes

Additions of new configuration properties or renaming existing properties require approval from kfs.engineers@kuali.co. Such changes include:

  • creation of new configuration property (adding)
  • changing a default value (modification)
  • removal of a configuration property

KFS Data Structure Changes

Additions of new database structures to KFS and changes to existing structures require approval from kfs.engineers@kuali.co.  Such changes include:

  • Adding tables (Addition)
  • Adding columns to existing tables (Modification)
  • Adding contraints to existing tables (Modification)
  • Adding indices to existing tables (Modification)
  • Removing columns from tables (Modification)
  • Dropping constraints or indices from existing tables (modification)
  • Removing tables entirely (removal)

Data structure change approval requests should include either the full SQL or full Liquibase required to complete these changes.  SQL can be written for Oracle or MySQL

KFS Bootstrap Data 

Adding, deleting, or modifying data in the bootstrap data set requires approval from kfs.product.team@kuali.co.

Bootstrap data approval requests should include the table name(s) and field name - values pairs for each record.

Rice Data Changes

Adding, deleting, or modifying data in Rice tables requires approval from kfs.product.team@kuali.co.  Templates for the most common requests are provided below.  Extraordinary requests (e.g. the addition of a new KFS module namespace) will be guided directly by the KFS project team.

Rice data structure changes must be requested of the Rice team itself.  Please consult the Rice team about their process to determine the steps necessary there.

Parameters

Application Namespace: KFS

Namespace: KFS-FP

Parameter Component: Procurement Card Load Step

Parameter Name: ALLOW_BACKPOST_DAYS

Parameter Type: CONFG

Parameter Value: 0

Parameter Constraint: A

Parameter Description: The number of days after fiscal year-end during which Procurement Card files loaded will post to the previous fiscal year.  If the value set to zero no post back is allowed.

Document Types

Name: ETOC

Label: Expense Type Object Code

Parent Name: TTSM

Description: Used to associate an Object Code with an Expense Type based on Expense Type, Document Type and Traveler Type.

KIM Attribute

Namespace: KFS-SYS

Name: chartOfAccountsCode

Component: org.kuali.kfs.sys.identity.KfsKimAttributes

KIM Type

Namespace: KFS-TEM

Name: Job Classification

Service Name: {http://kfs.kuali.org/kfs/v5_0}temExecutiveManagerRoleTypeService

Attributes:

  • KFS-TEM jobClsCode

KIM Role

Namespace: KFS-SYS

Name: User

Role Type: KFS-SYS Financial System User

Description: The basic role that grants users access to KFS.

KIM Permission Template

Namespace: KFS-SYS

Name: Modify Accounting Lines

KIM Type: KR-SYS Document Type, Routing Node & Field(s)

KIM Permission

Namespace: KFS-PURAP

Name: Initiate Document REQS

Template: KR-SYS Initiate Document

Attributes:

  • KR-WKFLW documentTypeName: REQS

Granted to Roles:

  • KFS-SYS Active Faculty or Staff
  • KFS-SYS User

Description: Authorizes the initiation of the Requisition Document.

KIM Responsibility

Namespace: KFS_FP

Name: Review Cash Receipt Change Request

Template: KR-WKFLW Review

Attributes:

  • Document Type: CR
  • Route Node: ChangeRequest
  • Required: Yes
  • Action Details at Role Member Level: No

Granted to Roles:

  • KFS-FP Cash Receipt Initiator

Role Responsibility Action (unnecessary / inappropriate when Action Details at Role Member Level = Yes)

  • Action Type: Acknowledge
  • Priority: 1
  • Policy Code: First
  • Force Action: Y

Description: Cash Receipt initiators are required to acknowledge the document after Cash Manager approval if there was change cash requested.

Workflow Change Process

  1. Workflow changes are Rice data changes, so you need to send an email to get those changes approved to kfs.product.team@kuali.co
  2. Contributing Developer modifies the appropriate file in kfs/src/main/config/workflow/ under the folder corresponding to the module being changed.  If you're uncertain which is the correct file ask KFS Technical Lead.
  3. Add the workflow change to kfs/src/main/resrouces/org/kuali/kfs/db/upgrades/prior-version_contrib-version/workflow/workflow_document_upgrades.xml.
  4. Contributing Developer alerts other contributors on shared branch that code is ready to be contributed that requires workflow changes.
  5. Contributing Developer creates pull request for the changes.
  6. Contributing Developer ingests the changes into the target environment.
  • No labels