Issue

Currently only full imports are created.

• Required 1 full import
• Additional (configurable) incrementals

The log of changes will need to be provided for verification

Fixes

Adds ability to test systems beyond initial creation

Acceptance

OneRoster.zip created
OneRoster{X}.zip incrementals where X is the number of incrementals

Module

• Core

Issue

There is a currently a gap between 6/30/2022 and 8/30/2022 where there is no school year.

Fixes

• Have the school year run 8/16/xxxx to 8/15/xxxx
• Add a Summer Term after 6/30/xxxx to 8/15/xxxx

Acceptance

The full year is not accounted for in the script --- no matter when it is run the full year will be accessible

Issue

The outputted file is generating ??? for single quote '

Fixes

Creates a valid file with valid information

Acceptance

There are no ??? fields in the users file

Steps

• Create integration test

Go through the objects and ensure Id is mapped to SourcedId

Issue

Refactor file generation to be abstracted for better organization and extensibility.

• Create an IGenerate interface for all the classes that handle both the List and GenerateAsync
• Organize into smaller classes that are abstractable and consumable

Fixes

• Maintainability
• Extensibility

Acceptance

• All unit tests run

Module

• Core

Issue

All teachers and administrators are currently 1 to 1

Fixes

The data would be more realistic with some teachers and administrators at multiple buildings

Acceptance

Unit Test to ensure there are teachers with multiple building access
Unit Test to ensure there are administrators with multiple building access

Module

Teacher Generation
Administration Generation

Steps

N/A

Issue

The OneRoster.zip export is missing the Enrollments file

Fixes

The lack of an Enrollments file in the exported file

Acceptance

The OneRoster.zip file contains the enrollments file.

Steps

Run Export Test
Verify that it contains the Enrollments file

Issue

The OutputCsv generates all the .csv file for the export, but does not generate them in a .zip that OneRoster needs

Fixes

No Csv is generated

Acceptance

Unit test that verifies the csv file has been generated

Module

Main

Steps

Issue

The current code based does not enforce non-nullable for non-nulls.

Fixes

objects that should not be null should be initialized with a non-null value
! (null-forgiving) operation null!

null bang!

Acceptance

• Compiler will issue warning for non-nulls that are not initlized
• Remove compiler warning

Steps

Add CS8600;CS8602;CS8603 to projects

• One for each Elementary
• Two for each Middle
• Three for each High School

Issue

The readme.md is not very informative

Fixes

Give the users more information like how to use it

Acceptance

There is more information for the user

Module

Steps

Issue

The default values for creating a OneRoster are fixed.

Fixes

The ability to create a roster of a given school / class / class size

Adding OneRosterInfo List to a C# Application

1. Introduction

1.1 Purpose

This document outlines the software requirements to add a list of OneRosterInfo objects to an OneRosterSampleDataGenerator application. The OneRosterInfo list will store counts of academic sessions, classes, courses, demographics, enrollments, organizations, and users. Additionally, it will maintain counts for both active and inactive records for each property. The list should be updated and populated with the counts on each generation of a OneRoster file.

1.2 Scope

This document defines the specific requirements for implementing the OneRosterInfo functionality within a C# application. It focuses on data storage, retrieval, and update mechanisms and does not encompass the generation of OneRoster files.

2. System Requirements

2.1 Environment

The application is expected to run on the Microsoft .NET framework, targeting C# as the primary programming language. It should be compatible with the following:

Operating System: Platform-independent, with primary testing on Windows.
.NET 7

##2.2 Dependencies
The application may rely on external libraries, frameworks, or a database system for data storage. These dependencies should be identified and documented.

3. OneRosterInfo Object

3.1 Object Definition

The OneRosterInfo object should be defined in C# as follows:

public record OneRosterInfo
{
    public int AcademicSessionsActiveCount { get; init; }
    public int AcademicSessionsInactiveCount { get; init; }
    public int ClassesActiveCount { get; init; }
    public int ClassesInactiveCount { get; init; }
    public int CoursesActiveCount { get; init; }
    public int CoursesInactiveCount { get; init; }
    public int DemographicsActiveCount { get; init; }
    public int DemographicsInactiveCount { get; init; }
    public int EnrollmentsActiveCount { get; init; }
    public int EnrollmentsInactiveCount { get; init; }
    public int OrganizationsActiveCount { get; init; }
    public int OrganizationsInactiveCount { get; init; }
    public int UsersActiveCount { get; init; }
    public int UsersInactiveCount { get; init; }
}

3.2 Data Storage

The OneRosterInfo objects should be stored in a database or appropriate data storage mechanism. Each instance represents the counts of educational data entities, both active and inactive.

4. Functional Requirements

4.1 Addition of OneRosterInfo List

4.1.1 User Interface

The application should provide a user interface or an API endpoint to add a new OneRosterInfo list. Users, or automated processes, should be able to input counts for each educational data entity, both active and inactive.

4.1.2 Validation

Input data should be validated to ensure that the counts are non-negative integers and within the valid range.

4.2 Updating OneRosterInfo List

4.2.1 Recurring Update

The OneRosterInfo list should be updated and populated every time a new OneRoster file is generated.

4.2.2 Calculation

Developers must implement a mechanism to calculate the counts for each educational data entity, both active and inactive, from the generated OneRoster file.

4.3 Retrieving OneRosterInfo List

4.3.1 Read Access

Developers should provide methods or API endpoints for reading and retrieving the OneRosterInfo list, both active and inactive counts, for reporting, display, or other relevant purposes within the application.

5. Non-Functional Requirements

5.1 Performance

The application should efficiently handle the storage and retrieval of OneRosterInfo data, including active and inactive counts.

5.2 Security

Appropriate security measures should be implemented to protect the integrity and confidentiality of the OneRosterInfo data, including access control and data encryption.

5.3 Scalability

The application should be designed to handle an increased volume of data and an increase in user activity, both for active and inactive data.

5.4 Documentation

Comprehensive documentation, including code comments, user guides, and technical documentation, should be provided to facilitate maintenance and usage of the OneRosterInfo functionality.

6. Testing
   Comprehensive testing, including unit tests and integration tests, should be conducted to ensure the correctness and robustness of the OneRosterInfo functionality.

7. Deployment

The implementation of the OneRosterInfo functionality should be deployed to the production environment as part of the application's regular release process.

8. Maintenance and Support

Ongoing maintenance and support for the OneRosterInfo functionality, including bug fixes and updates, should be provided as part of the application's lifecycle.

9. Conclusion

This document outlines the software requirements for adding a list of OneRosterInfo objects to a C# application. These requirements cover the storage, retrieval, and update mechanisms for both active and inactive counts related to educational data entities. The developer should adhere to these requirements for successful implementation.

Issue

The demographics are not generated in memory -- only on file exports

Fixes

Adds ability to test easier with inmemory options

Acceptance

in memory construct has demographic data

Issue

Currently the number of schools is default to 22.

There is no way to change the number of schools.

Less than 3 should not be selected

3 should return one of each High, Middle, Elementary

Fixes

Gives the user ability to customize data

Acceptance

2 schools or less throws are excpetion
3 schools creates 1 high, 1 middle, and 1 elementary
more than 3 schools works randomly

Issue

Make nullable the constructor parameters and expose Default Values to users.

Fixes

Allows for better customization

Issue

There are no birthdates generated in December

Fixes

The data will be more realistic if there are birthdates in December

Acceptance

• Utilize Faker for dates for generating birth dates
• Write a test for each month to have at least one birthdate

Issue

The column headers in the Courses Export is incorrect

Fixes

Ability to upload correct files

Issue

The current test frame is MS Test

Fixes

Modernization with NUnit

Acceptance

All current tests are now executing in NUnit Framework