SDSM:Index: Difference between revisions

From SMUSwiki
Jump to navigation Jump to search
(Add section: SDS Laravel PHP Library Dependencies: Directly Used By Name In PHP Source Files)
(Add new document part Performance Measurements.)
 
(12 intermediate revisions by the same user not shown)
Line 18: Line 18:
[[#top|RETURN]]
[[#top|RETURN]]


== Audience ==
== Introduction ==


The intended audience of this document is individuals who are savvy with
=== System Overview ===
electronic computer hardware and software, its use, installation, and
maintenance.  In particular, it is for individuals that are capable of
writing, maintaining, integrating, testing software code, or installing
and maintaining deployments of software on internet servers.  Or it is
for those individuals who directly communicate with or manage such
people and technical projects, and have some understanding of technology.
 
This document is mainly for individuals who would be involved with the
'''SDS Modernization (SDSM)''' effort, or who would be maintaining
'''SDS''' afterwards, or who would be managing the people who do these
things, or who want to be more informed about how '''SDS''' works.
 
This document is not specifically for those who are just end users of
'''SDS''', or for those who make higher level management decisions and are
less technically savvy, but they might glean useful information from it.
For these kinds of users, other derived or supplementary documentation may
be better suited to their needs, or this document can be re-interpreted for
them in other forms that better suit them.
 
[[#top|RETURN]]
 
== Overview ==


'''School Data System (SDS)''' is an electronic records management system
'''School Data System (SDS)''' is an electronic records management system
Line 59: Line 37:


'''SDS''' has a client-server architecture, hosted on a network as a web
'''SDS''' has a client-server architecture, hosted on a network as a web
server, and used by way of a web client. '''SDS''' should be compatible
server, and used by way of a web client. '''SDS''' should be compatible
with all modern web clients, including Mozilla FireFox, Google Chrome,
with all modern web clients, including Mozilla FireFox, Google Chrome,
Microsoft Edge, and Apple Safari; it should be usable with all modern
Microsoft Edge, and Apple Safari; it should be usable with all modern
Line 82: Line 60:
The newer '''SDS''' version is meant to have essentially the same
The newer '''SDS''' version is meant to have essentially the same
outward-facing or user-visible feature set, behavior, and appearance as
outward-facing or user-visible feature set, behavior, and appearance as
the older version. The newer version also uses essentially the same SQL
the older version. The newer version also uses essentially the same SQL
database schema as the older version, and they actively share a database,
database schema as the older version, and they actively share a database,
which makes for a more seamless migration as the database doesn't have to
which makes for a more seamless migration as the database doesn't have to
be "converted". Within these constraints of looking the same to users and
be "converted". Within these constraints of looking the same to users and
having the same database, the new version is almost completely different
having the same database, the new version is almost completely different
internally, with a new internal code structure that is a lot more modern.
internally, with a new internal code structure that is a lot more modern.


Each '''SDS''' version is written in the '''PHP''' programming language
Each '''SDS''' version is written in the '''PHP''' programming language
and uses a '''MySQL''' database. The newer version uses the
and uses a '''MySQL''' database. The newer version uses the
'''Laravel''' PHP application framework, while the older version uses
'''Laravel''' PHP application framework, while the older version uses
the '''Gavintech''' PHP framework. Both versions' production instances
the '''Gavintech''' PHP framework. Both versions' production instances
are on servers running the '''Ubuntu''' operating system and are behind
are on servers running the '''Ubuntu''' operating system and are behind
an '''Apache''' web server. While '''Gavintech''' is essentially
an '''Apache''' web server. While '''Gavintech''' is essentially
abandoned, very non-modern, and bespoke, all of the other named
abandoned, very non-modern, and bespoke, all of the other named
dependencies are actively maintained, modern, and very popular.
dependencies are actively maintained, modern, and very popular.
Line 100: Line 78:
[[#top|RETURN]]
[[#top|RETURN]]


== Structure and Dependencies ==
=== Audience of the Documentation ===
 
The intended audience of this document is individuals who are savvy with
electronic computer hardware and software, its use, installation, and
maintenance. In particular, it is for individuals that are capable of
writing, maintaining, integrating, testing software code, or installing
and maintaining deployments of software on internet servers. Or it is
for those individuals who directly communicate with or manage such
people and technical projects, and have some understanding of technology.
 
This document is mainly for individuals who would be involved with the
'''SDS Modernization (SDSM)''' effort, or who would be maintaining
'''SDS''' afterwards, or who would be managing the people who do these
things, or who want to be more informed about how '''SDS''' works.
 
This document is not specifically for those who are just end users of
'''SDS''', or for those who make higher level management decisions and are
less technically savvy, but they might glean useful information from it.
For these kinds of users, other derived or supplementary documentation may
be better suited to their needs, or this document can be re-interpreted for
them in other forms that better suit them.
 
[[#top|RETURN]]
 
== System Architecture ==
 
=== Network Diagrams ===
 
See the document part [[SDSM:Network_Diagrams|Network Diagrams]].
 
[[#top|RETURN]]
 
== Environment Setup ==


'''SDS''' itself is a web application written mainly in the PHP
=== Software Requirements ===
programming language (https://www.php.net).  Some portions are also
 
written in the JavaScript programming language, though it is intended
'''SDS''' is a web application written in 3 main programming languages:
that these will be replaced with PHP code, mostly if not entirely.
 
Some portions are also written in the MySQL DBMS (https://www.mysql.com)
* PHP (https://www.php.net)
dialect of the SQL programming language, but these are being replaced with
* JavaScript
PHP code that uses a DBMS abstraction instead of literal SQL.
* MySQL DBMS (https://www.mysql.com) dialect of SQL


'''SDS''' specifically uses PHP major version 8.1, which was first
'''SDS''' specifically uses PHP major version 8.1, which was first
Line 124: Line 134:


'''SDS''' can run on a variety of server environments and operating
'''SDS''' can run on a variety of server environments and operating
systems, same as PHP and MySQL do. However, its canonical (and ''also''
systems, same as PHP and MySQL do. However, its canonical (and ''also''
its '''Canonical''') runtime environment is the Ubuntu operating system
its '''Canonical''') runtime environment is the Ubuntu operating system
(https://ubuntu.com), which '''SMUS''' runs its production and shared
(https://ubuntu.com), which '''SMUS''' runs its production and shared
Line 136: Line 146:
'''SMUS''' uses the specific versions of PHP and MySQL that are provided
'''SMUS''' uses the specific versions of PHP and MySQL that are provided
with the Ubuntu version it uses, so the former are only updated when the
with the Ubuntu version it uses, so the former are only updated when the
latter is updated. Most notable is that '''SDS''' is constrained to using
latter is updated. Most notable is that '''SDS''' is constrained to using
PHP 8.1 for as long as it is run on Ubuntu 22.04. While their principal
PHP 8.1 for as long as it is run on Ubuntu 22.04. While their principal
maintainers may stop supporting those versions sooner, Ubuntu themselves
maintainers may stop supporting those versions sooner, Ubuntu themselves
would continue to provide critical security and bug fixes to MySQL and PHP
would continue to provide critical security and bug fixes to MySQL and PHP
bundled with their LTS releases, but not new major versions.
bundled with their LTS releases, but not new major versions.


=== SDS Laravel PHP Library Dependencies ===
[[#top|RETURN]]


==== Directly Used By Name In PHP Source Files ====
== Codebase Overview ==


The PHP source code files of ''SDS Laravel'' contain direct references
=== Languages and Frameworks ===
to a variety of third-party PHP classes, most instances of which are
parts of the Laravel framework, and some that aren't.  Often their
fully-qualified names only appear on the form of <code>use</code>
statements but other times those names ''don't'' appear in
<code>use</code> statements and in the main body of PHP code instead.


This '''SDSM''' document sub-section enumerates the third-party PHP
See the document part [[SDSM:Languages_and_Frameworks|Languages and Frameworks]].
classes that are directly referenced by name in the ''SDS Laravel'' PHP
source code, which is the strongest indicator that those classes are
actually-used dependencies of it, rather than declared dependencies that
are not actually used.


Directly used by name in about 800 app PHP files:
[[#top|RETURN]]


* Illuminate\*
== User Interface Documentation ==
* Auth aka Illuminate\Support\Facades\Auth
* DB aka Illuminate\Support\Facades\DB
* Mail aka Illuminate\Support\Facades\Mail
* Redirect aka Illuminate\Support\Facades\Redirect
* URL aka Illuminate\Support\Facades\URL


Directly used by name in app/Models/File.php and app/Http/Controllers/Admin/Migration/ImportPhotosController.php only:
=== Users and Privileges ===


* Image aka Intervention\Image\ImageServiceProvider
See the document part [[SDSM:Users_and_Privileges|Users and Privileges]].


Directly used by name in about 70 app PHP classes:
[[#top|RETURN]]


* Carbon\Carbon
=== List of Screens ===
* Carbon\Exceptions\InvalidFormatException


Directly used by name in 10 app PHP classes:
See the document part [[SDSM:List_of_Screens|List of Screens]].


* LdapRecord\*
[[#top|RETURN]]


Directly used by name in 9 app PHP model classes:
=== Performance Measurements ===


* GoldSpecDigital\LaravelEloquentUUID\Database\Eloquent\Uuid
See the document part [[SDSM:Performance_Measurements|Performance Measurements]].


Directly used by name in 5 app PHP classes related to Blackbaud or Bambora:
[[#top|RETURN]]


* GuzzleHttp\Client
== Appendices ==
* GuzzleHttp\Exception\ClientException
* GuzzleHttp\Exception\GuzzleException


Directly used by name in app/Models/Finance/Bambora.php or app/Http/Controllers/Api/UserProfileController.php only:
=== Historical Changes ===


* Beanstream\ApiException
See the document part [[SDSM:Historical_Changes|Historical Changes]].
* Beanstream\Exception
* Beanstream\Gateway


Directly used by name in 11 php files mostly database/factories/*.php:
[[#top|RETURN]]


* Faker\Generator
=== Pending Changes ===


Directly used by name in app/Models/User.php only:
See the document part [[SDSM:Pending_Changes|Pending Changes]].


* Lab404\Impersonate\*
[[#top|RETURN]]


Directly used by name in app/Providers/AppServiceProvider.php only:
=== Future Changes ===


* Dotenv\Dotenv
See the document part [[SDSM:Future_Changes|Future Changes]].


Directly used by name in app/Models/Pivot/FormCampaignPerson.php only:
[[#top|RETURN]]
 
* Staudenmeir\EloquentHasManyDeep\HasRelationships
 
Directly used by name in app/Http/Middleware/TrustProxies.php only:
 
* Fideloper\Proxy\TrustProxies
 
Directly used by name in app/Http/Middleware/AuthTimeoutMiddleware.php and app/Http/Kernel.php only:
 
* JulioMotol\AuthTimeout\Middleware\AuthTimeoutMiddleware
 
Directly used by name in app/Exceptions/Handler.php only:
 
* Symfony\Component\HttpFoundation\Response
 
Directly used by name in config/logging.php only:
 
* Monolog\Handler\*
 
Directly used by name in tests/Unit/ExampleTest.php only:
 
* PHPUnit\Framework\TestCase
 
Directly referenced by name COMMENTED-OUT in app/Http/Kernel.php only:
 
* Fruitcake\Cors\HandleCors
 
== Appendices ==


=== Proposed Layout of SDSM by Chetan Sondagar ===
=== Future Layout of SDSM ===


Chetan Sondagar proposed, on 2024 April 10, the following layout for this
The '''SDS Modernization (SDSM)''' document is currently missing a large
'''SDS Modernization (SDSM)''' document. The actual document layout ended
fraction of its intended content. In the meantime, it eschews empty
up being different, and the proposal is shown here for posterity.
placeholder sections, so one navigating its table of contents can easily
But while the actual document was in development and had substantial
discern what does or doesn't exist now. Instead, this current section
missing content, the proposal also served to illustrate what was missing.
illustrates the overall layout that the whole document is evolving towards.


# '''Introduction'''
# '''Introduction'''

Latest revision as of 14:25, 4 September 2024


This document consists of multiple parts; for a directory to all of the parts, see SDSM:Index.

Name

SDS Modernization (SDSM) - Modernization of SMUS School Data System

RETURN

Description

This document describes an active effort running through 2024 to modernize the School Data System (SDS) of St. Michaels University School (SMUS).

RETURN

Introduction

System Overview

School Data System (SDS) is an electronic records management system that empowers a school's fundamental operations by managing the school's records of its students and related data and business processes. This includes tracking students' identities, enrolment, classes, and marks. SDS is used directly by students, their parents, their teachers, and other staff of a school having various roles.

SDS is meant in principle to be usable by any school, but first and foremost to meet the specific needs of St. Michaels University School (SMUS). SMUS is the only school actually using it as of 2024, but SDS may be made available to other schools later. Historically, SDS was also used by Brentwood College School.

SDS has a client-server architecture, hosted on a network as a web server, and used by way of a web client. SDS should be compatible with all modern web clients, including Mozilla FireFox, Google Chrome, Microsoft Edge, and Apple Safari; it should be usable with all modern client devices and operating systems.

SMUS hosts all of its SDS instances, production and testing, on premises on network servers located at its Richmond Road campus. They are not hosted by a third party, whether "cloud" or otherwise.

See https://sds.smus.ca for the production instance.

SDS has 2 alternative versions in April of 2024, older and newer.

The older SDS version (SDS Gavintech), is actively in use in production, and its development is mostly frozen, with minimal updates only.

The newer SDS version (SDS Laravel or SDS API), is not currently used in production, and is incomplete; nearly all current development work is on this version, and it is intended to replace the older version in production once it is sufficiently complete.

The newer SDS version is meant to have essentially the same outward-facing or user-visible feature set, behavior, and appearance as the older version. The newer version also uses essentially the same SQL database schema as the older version, and they actively share a database, which makes for a more seamless migration as the database doesn't have to be "converted". Within these constraints of looking the same to users and having the same database, the new version is almost completely different internally, with a new internal code structure that is a lot more modern.

Each SDS version is written in the PHP programming language and uses a MySQL database. The newer version uses the Laravel PHP application framework, while the older version uses the Gavintech PHP framework. Both versions' production instances are on servers running the Ubuntu operating system and are behind an Apache web server. While Gavintech is essentially abandoned, very non-modern, and bespoke, all of the other named dependencies are actively maintained, modern, and very popular.

RETURN

Audience of the Documentation

The intended audience of this document is individuals who are savvy with electronic computer hardware and software, its use, installation, and maintenance. In particular, it is for individuals that are capable of writing, maintaining, integrating, testing software code, or installing and maintaining deployments of software on internet servers. Or it is for those individuals who directly communicate with or manage such people and technical projects, and have some understanding of technology.

This document is mainly for individuals who would be involved with the SDS Modernization (SDSM) effort, or who would be maintaining SDS afterwards, or who would be managing the people who do these things, or who want to be more informed about how SDS works.

This document is not specifically for those who are just end users of SDS, or for those who make higher level management decisions and are less technically savvy, but they might glean useful information from it. For these kinds of users, other derived or supplementary documentation may be better suited to their needs, or this document can be re-interpreted for them in other forms that better suit them.

RETURN

System Architecture

Network Diagrams

See the document part Network Diagrams.

RETURN

Environment Setup

Software Requirements

SDS is a web application written in 3 main programming languages:

SDS specifically uses PHP major version 8.1, which was first released for general production use on 2020 Nov 26 (https://www.php.net/ChangeLog-8.php); PHP 8.1 stopped receiving active support by its principal maintainers on 2023 Nov 25, and then for critical security issues it will only be supported by them until 2025 Dec 31 (https://www.php.net/supported-versions.php).

SDS specifically uses MySQL major version 8.0, which was first released for general production use on 2018 Apr 19 (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-11.html); MySQL 8.0 will stop receiving LTS support by its principal maintainers in 2026 April.

SDS can run on a variety of server environments and operating systems, same as PHP and MySQL do. However, its canonical (and also its Canonical) runtime environment is the Ubuntu operating system (https://ubuntu.com), which SMUS runs its production and shared testing deployments in.

Those production SDS deployments specifically use Ubuntu major version 22.04 LTS, which was first released for general production use on 2022 Apr 21; it will stop receiving standard support in 2027 and end of life support in 2032 (https://wiki.ubuntu.com/Releases).

SMUS uses the specific versions of PHP and MySQL that are provided with the Ubuntu version it uses, so the former are only updated when the latter is updated. Most notable is that SDS is constrained to using PHP 8.1 for as long as it is run on Ubuntu 22.04. While their principal maintainers may stop supporting those versions sooner, Ubuntu themselves would continue to provide critical security and bug fixes to MySQL and PHP bundled with their LTS releases, but not new major versions.

RETURN

Codebase Overview

Languages and Frameworks

See the document part Languages and Frameworks.

RETURN

User Interface Documentation

Users and Privileges

See the document part Users and Privileges.

RETURN

List of Screens

See the document part List of Screens.

RETURN

Performance Measurements

See the document part Performance Measurements.

RETURN

Appendices

Historical Changes

See the document part Historical Changes.

RETURN

Pending Changes

See the document part Pending Changes.

RETURN

Future Changes

See the document part Future Changes.

RETURN

Future Layout of SDSM

The SDS Modernization (SDSM) document is currently missing a large fraction of its intended content. In the meantime, it eschews empty placeholder sections, so one navigating its table of contents can easily discern what does or doesn't exist now. Instead, this current section illustrates the overall layout that the whole document is evolving towards.

  1. Introduction
    • System Overview: Brief description of the system, its main components, and its purpose.
    • Purpose and Scope: Clarify the intended use of the documentation and its intended audience.
    • Audience of the Documentation: Specify who the documentation is written for (e.g., developers, system administrators, end-users).
  2. System Architecture
    • High-Level Architecture: Overview of the system's architecture, including major components and how they interact.
    • System Components and Interactions: Detailed description of each system component and its role.
    • Network Diagrams: Visual representations of network and system architecture, if applicable.
  3. Environment Setup
    • Hardware Requirements: Specifications for necessary hardware.
    • Software Requirements: Required software and versions.
    • Environment Configuration: Instructions for setting up development, testing, and production environments.
    • Client Requirements: Required software and versions.
  4. Database Documentation
    • Database Schema: Detailed diagrams and descriptions of database tables, fields, data types, and relations.
    • Data Dictionary: Detailed definitions of all database elements.
    • Entity-Relationship Diagrams: Visual representation of data entities and relationships.
    • Database Performance Metrics: Information on database performance and optimization.
  5. Codebase Overview
    • Languages and Frameworks: Information about programming languages and frameworks used.
    • Repository Structure: Description of the code repository structure.
    • Coding Standards and Conventions: Guidelines followed in the codebase.
    • Repository Access: Instructions to access code repository.
  6. API Documentation
    • List of Endpoints: Detailed list of API endpoints and their functions.
    • Request/Response Formats: Specifications of request and response formats.
    • Authentication and Authorization: Methods used for API security.
  7. User Interface Documentation
    • Screenshots and Descriptions: Visuals and descriptions of key interfaces.
    • User Flow Diagrams: Diagrams showing user navigation through the system.
  8. Security Protocols
    • Data Security Measures: Techniques used for securing data.
    • Network Security Configurations: Network security tools and configurations.
  9. Installation and Deployment
    • Installation Guide: Step-by-step installation instructions.
    • Deployment Procedures: Process for deploying updates or new releases.
    • CI/CD Practices: Continuous integration and deployment methodologies used.
  10. Testing and Quality Assurance
    • Testing Procedures: Overview of testing strategies and methodologies.
    • Test Case Descriptions: Examples of key test cases.
    • Automated Testing Frameworks: Description of automated testing setup.
  11. Performance and Optimization
    • System Performance Benchmarks: Key performance indicators and benchmarks.
    • Optimization Strategies: Techniques and practices for optimizing system performance.
  12. Backup and Recovery
    • Backup Procedures and Schedules: How and when backups are conducted.
    • Disaster Recovery Plan: Steps and procedures for system recovery in case of a disaster.
  13. Access Control
    • User Roles and Permissions: Description of different user roles and their access levels.
    • Access Management Procedures: How user access is managed and controlled.
  14. System Integration
    • External System Integration: Details of integration with external systems or services.
    • Data Exchange Protocols: Protocols used for data exchange with external systems.
  15. Localization and Internationalization (if applicable)
    • Supported Languages: List of languages the system supports.
    • Cultural Adaptations: Adjustments made for different cultural or regional needs.
  16. Scalability and Future Development
    • Scalability Strategies: Plans and techniques for scaling the system.
    • Expansion Plans and Roadmap: Future development plans and system evolution roadmap.
  17. Customization and Extensibility
    • Customization Options: Options available for system customization.
    • API Documentation for Extensibility: Documentation for APIs available for extending the system.
  18. Operational Best Practices
    • System Maintenance Guidelines: Best practices for maintaining the system.
    • Security Best Practices: Guidelines for maintaining security.
    • Audit Trails and Logging: Information on system logging and audit trails.
  19. Feedback and Continuous Improvement
    • Feedback Mechanisms: How users can provide feedback.
    • Improvement Processes: How feedback is incorporated into system improvements.
  20. Appendices
    • Glossary of Terms: Definitions of technical terms used.

RETURN

Authors

Primarily written by Darren Duncan.

Includes portions written by or derived from sources written by:

  • Chetan Sondagar

RETURN

License and Copyright

Copyright © 2024, St. Michaels University School.

RETURN

Retrieved from "https://wiki.smus.ca/index.php?title=SDSM:Index&oldid=27316"