Philosophy & Design Goals

Prepare applications for the next 30 Years
Don't Rewrite. Re-Think, Re-Invent and Re-design
Reproduce the capabilities of Classic.
- The "What", not the "How". What it does is similar. How it's done is different.
- Implement minimum business rules. Leave the rest to customization.
Design to be agnostic regarding:
- Server Location
- Operating System and Platform
- Existence of ITCs

Technical Architecture

Independent Installable Features
Types of Modules:
- Infrastructure (database, email)
- Behavioral (business logic)
- Required
- Optional (authentication)

Object Oriented
Abstraction of underlying Database tables
- Simplifies tables
- Correctly linked to related objects
Dynamic
Primary key (Database Id)
- Automatically assigned by system
- Immutable
- Random UUID
- Used in relationships between objects
Natural Id
- User or Auto assigned identifier
- Human-readable reference number
- May be mutable
- Not used in relationships
https://usas.docs.ssdt.io/current/model/
https://usps.docs.ssdt.io/current/model/

If operation fails (due to crash):
- USxS transaction can be partial posted
- Files left in inconsistent state (out of balance)
Example: Post Purchase Order steps:
- Write PO header record
- Loop for each PO Item:
  - Write item record
  - Update encumbrances on budget
  - Update encumbrances on appropriation
  - Update encumbrances on cash
- If any of the steps fail, files can be out of balance

SQL Databases provide "Transactional Scope"
All operations within scope guaranteed to, either:
- Succeed completely (commit)
- Fail completely (rollback)
Any error causes rollback:
- Duplicate key
- Validation error
- Security violation
- System failure

Each Application has separate User profiles
An "ITC User" must have a profile in each instance
- Can be externally authenticated (Windows Domain)
- No special privileges assigned to ITC user
Permissions:
- Defined by application
- Fine-grained operations the software can perform
- Not analogous to file level protections or ACL's in Classic
Roles
- Set of permissions granted to a role
- Defined per district per application
- May represent:
  - Group of users
  - Job Function
- One or more roles granted to Users
Predefined Roles:
- ADMINISTRATORS (required)
- Classic compatibility: (If imported from Classic)
  - SYSMAN_USER like OECN_SYSMAN
  - USAS_MANAGER like OECN_USAS_GM
  - USAS_REQ like OECN_USAS_REQ
  - USAS_RO like OECN_USAS_RO
  - USAS_STANDARD like OECN_USAS
  - Similar for USPS
Security in Application
- In User Interface:
  - Hides Menu Options
  - Hides or disables buttons and controls
- Application Layer
  - Services verify users access
  - If UI inadvertently allows user access, Model protects authorized access