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
Condition |
Result |
||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="e4347c7c-9bfa-48e1-a9b4-facc713a4479"><ac:plain-text-body><![CDATA[ |
Condition function + qualifier sub type +[qualifier code] |
Function + qualifier sub type +[qualifier code] |
]]></ac:plain-text-body></ac:structured-macro> |
1a: |
This implies that you can read room set information. |
||
F= EHS-Rep, Qs = RoomSet, Q= NULL |
F=view hazard + Qs=RoomSet + Q=null (qualifier sub type is constant/copied from the condition side) |
||
|
|
||
1b: |
f=view training data + Qs= PI (note the qualifier sub type transformation |
||
2a. f=grad-student Q=Bio(academic course numbers) |
Func=view-library-materials Qual=Acme Bio Journal (note that transitioned from one hierarchy to another hierarchy) (place in hierarchy) |
||
2b. f=grad-student q=school-of-science (note that this is not an academic unit, it implies a number of children in the academic unit hierarchy) |
F=view library material Quallifier = licensed science journal (transformed hierarchy) (inheritance of hierarchy) |
[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.