...

\[Tree diagram appears in Paul's notes.\] 
\\ 
\\

2a versus 2b: descend or not to descend. Example you are assigning something to a Director. But not assigning the privilege to all of the people that report to him.

...

• Use cases that describe the four types of rules.
• Cases that cover composition of the rules.

Thursday:

Goals:

• Use cases for implied ASPECs
• Master domain hierarchy
• The META category
  
  

Today the only way to create the rules is from the roles web (cgi).

Is there is portion of Kuali Student that maps to the rules creation. If so, we would say that is the spec for the service interface, and leave it for later for implementation.

Simple use case:

• Create a rule of type 1a
• Create a rule of type 1b
• Create a rule of type 2a
• Create a rule of type 2b
• Activate a rule.
• Deactivate a rule.

• Wiki Markup
  \[Force a rule to be evaluated. (Admin)\] - probably doesn't belong here. If the system evaluates realtime, then this meaningless.

• Linking a function to a function group.
  • A function group allows you to create a rule that operates a number of function with one rule instead of needing separate rules to populate individual functions. Dealing with the condition functions, not the result function.
  • (note the core roles DB has a way of grouping result functions, different table)
    
• Creating a new function group (some sort of an administrator, same type of person that creates rules)
• Create qualifier sub type (what terminology does Kuali use for this?)
  • Profit center hierarchy has three types of subtypes:
    • Cost object
    • Profit center
    • node

• Create Subtype_descendent_subtype
  • One of the column is a pattern matching template. i.e. knows about formatting of the identifiers and triggers on it.

• Link qualifier_subtype and subtype_descendent_subtype
  
  
  

System Activities: (use cases that really internal to the system)

• Wiki Markup
  Evaluation of a rule \[batch or realtime\]\\ \\

• Rule type three for a logical AND of conditions? Not to be implemented or modeled in the foreseeable future.
  

Existing rules:

EHS

Libraries

(future: SDLS, door access control)

Action Items:

Jim - write up of EHS and Libraries

Paul - write up SDLS and door access

All -

• discussion of data feeds
• Master domain hierarchy
• The META category
  

Jim continues working on stored procedure inventory (finished Thursday evening)

Vijay going through data model

Friday:

TAP: MySQL, perl,

Amon's auto docs

Data feeds:

Do we create XML models of the source data ?

Later phase?

Need an inventory of the data feeds. Jim thinks Marina may have done this. He will check and get back to us.

Data feeds bring data into a flat file and then propagate into the perMIT DB. How do we end up with their hierarchy? The base assumption is that qualifier only has one parent (wrt the data fed data.)

Maybe create a new hierarchy that we don't currently have. This will take Vijay through the process of building a bulk feed. Suggestion: Building-floor-room.

What is the fund center table?

If within SAP they created a fund center without a release strategy, this would mean that no approvals are necessary. This table captures the fund centers that are in this state and makes approvals necessary.

META: the self-referential category

Create functions within a category

Create qualifiers within a category

Maintain all parameters data

Maintain all parameters values:

These are the limiters, how many changes via bulk in day.

Maintain qualifiers (by qualifier types)

Maintain roles DB users (admin) who can create new roles DB users. (Not needed in perMIT?)

Maintain selection sets (related to the PowerBuilder application) not needed in perMIT?

Notification of inactive users - tells who gets the notification when someone's account deactivated. This is not an authorization. It is about who gets notified (a role).

Proxy for roles admin func, proxy maintain qual. - used to let application servers act on behalf of the end usrs.

Run admin reports - determines who can run some admin reports.

View auth by category: who gets to see aspecs for other people by category.

View restricted qualifiers (by qual type) - e.g. how we limit who can view certain qualifiers (EHS animal related...) Is this flexible enough going into the future, or for other sites.

Paul - create large format prints of Jim's DB diagrams and Amon's diagrams. Next week we will mark these up looking at where we can add DB constraints, and where we SHOULD NOT.

Next week - also discussion of master department hierarchy

Jim out the week of April 6th.