Monday:

perMIT use cases:
Additional cases from Jim

Need More implied auth
Need more around master dept hirerarchy

What is a primary authorizer?
A person who has the ability to grant authorizations (A-specs).
The SUBJects which they can put into an a-spec is not limited in any way.

Use case:
Create a new Primary Authorization Function

Statements about Primary Authorizations:

• A person that can grant A-SPECs.
• The SUBJECT that can be put into the A-SPEC is not limited in any way.
• Primary Authorizer is a FUNCTION within the META category.
• The PA-FUNCTION detetrmines which functions the PA may choose when creating A-SPECs
• The Qualifier, in this case, is always a Deparment*
• The qualifier within the PA-ASPEC determines the qualifiers the PA may choose when creating APECS.

The Primary Authorization function is a key to scalability when first ramping up with perMIT. Sites that aren't aware of this, or ignore it, will have to perform a lot of unnecessary data entry.

Tuesday:

perMIT weekly:

Agenda:

Summary of last week

Implied authorizations

Next week's meeting: review timeline again

Vijay - oraperl - missing libraries: Oracle instant client library?

Maybe Mark Manley?

4 types of rules for implied ASPECS (the subject i

[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.

In rules 1a and 1b, we don't specify the qualifier. We specify a qualifier subtype.

In rules 2a and 2b, we do specify the qualifier.

2b - we're ascending the tree, not descending

Not all qualifier hierarchies have multiple sub types. You could consider some hierarchies all have a single qual subtype. So you can still form rules of type 1a and 1b on any function-qualifier hierarchy.

We haven't defined additional rule types. We could handle very complex business cases by compositing the existing rule types.

Rule type is stored as a field and this controls how the rule is evaluated.

There is a table (missing from data model) that describes parent/child relationships between the qualifier subtypes.

Use cases:

• Create rules
• Create objects to support rules
  • Creating qualifier subtypes

• 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.
• [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)

• 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

See: http://rolesweb.mit.edu/cgi-bin/rolefunc2.pl?category=META+Roles+Meta-auths 

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.