Tool/dev

.github/workflows/tests.yml

@@ -6,7 +6,7 @@ on:
   pull_request:
 
 jobs:
-  test:
+  backend-test:
     runs-on: ubuntu-latest
 
     steps:
@@ -46,4 +46,29 @@ jobs:
         uses: actions/upload-artifact@v4
         with:
           name: coverage-html
-          path: htmlcov/
+          path: htmlcov/
+  frontend-test:
+    timeout-minutes: 60
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v4
+    - uses: actions/setup-node@v4
+      with:
+        node-version: lts/*
+    - name: Install dependencies and Run Playwright Tests
+      run: |
+        cd src/frontend/
+        npm install
+        cd ../../test/frontend/
+        npm install
+        npx playwright install --with-deps
+    - name: Run Playwright Tests
+      run: | 
+        cd test/frontend
+        npx playwright test
+    - uses: actions/upload-artifact@v4
+      if: ${{ !cancelled() }}
+      with:
+        name: playwright-report
+        path: playwright-report/
+        retention-days: 30

.gitignore

@@ -298,3 +298,6 @@ db.sqlite3
 *.rdb
 dump.rdb
 *venv
+
+
+

docs/Design/SoftDetailedDes/MIS.tex

@@ -2394,5 +2394,33 @@ \section*{Appendix --- Reflection}
   (LO\_Explores)
 \end{enumerate}
 
+\textbf{Peer Implementation Reflection:}
+
+  Implementing team 25's module was very manageable because the MIS clearly listed the exported constants and exported access
+  programs which gave a strong starting point for the structure and naming. The most helpful part of the MIS was the access routine,
+  since it clearly stated the expected conversion approach (repeated division and remainder for decimal to dozenal, 
+  and the positional evaluation for dozenal to decimals). The main challenge i think however was that the MIS did not fully define the allowed 
+  digit-symbol mapping for the two extra dozenal digits beyond 0-9, so some of the implementation choices made required assumptions 
+  to a level (e.g., choosing \texttt{X} and \texttt{E} as canonical symbols and supporting alternate inputs). 
+  Another difficulty was deciding how strict i should make normalization, especially around things like handling whitespace, casing, optional
+  plus signs, and the leading zeros. 
+
+  To improve implementability, the MIS could include explicit examples of valid and invalid dozenal
+  strings, plus sample inputs and outputs for each access program (including edge cases like 0, negative numbers, and error
+  strings). This process really helped to reinforce the importance of specifying specific or rather strict input validation rules and canonical formatting 
+  expectations inside the MIS so people implementing do not rely on interpretation or assumption (but i guess you always have to to some extent). 
+  Overall, implementing this module helped confirm
+  how small missing details in a specification can affect consistency across different implementations, but a good MIS can still make implementation manageable.
+
+  \paragraph{Reflection on Another Team's Implementation (M18).}
+  Team 22's implementation of our M18 Logging Module mostly matched the MIS well (same exported access programs, exceptions, 
+  log levels, \texttt{LogEntry} fields, and the \texttt{logEvent} threshold behavior). The main issue 
+  I noticed was around \texttt{archiveLogs()} when using \texttt{RotatingFileHandler}: rotation can happen automatically
+   during logging, which can make \texttt{archiveLogs()} do nothing afterward because \texttt{app.log} becomes small again. 
+   This showed me that the MIS needs to be more explicit about how archiving should work with automatic rotation and how
+    compression/retention should be handled (for example, whether compression happens during rollover, and how backups are
+     kept and named).
+
+
 
 \end{document}

docs/projMngmnt/Rev0_Team_Contrib.tex

@@ -24,186 +24,224 @@
 
 \section{Demo Plans}
 
-\wss{What will you be demonstrating}
+% \wss{What will you be demonstrating}
+For our Rev 0 demo, we will begin with a brief introduction
+to the project and a short update on the research progress.
+We will then walk through the main user flow end-to-end to
+show that the core system components are integrated and
+functioning. Starting from the Home page, the user navigates
+to the Sign-In page and logs in. After signing in, the user
+is taken to the Visualization page, where they can enter a
+GitHub repository link and submit it for analysis. Our backend
+retrieves repository data via the GitHub API, processes the
+retrieved information, and returns results to the frontend.
+We will demonstrate that outputs are successfully rendered
+and that the system is usable end-to-end. The demo will also
+highlight improvements since the PoC demo (e.g., more robust
+data handling, clearer outputs, and a more consistent user
+experience). If any planned functionality is not yet
+implemented, we will state it explicitly and describe next
+steps.
 
 \section{Team Meeting Attendance}
 
-\wss{For each team member how many team meetings have they attended over the
-time period of interest.  This number should be determined from the meeting
-issues in the team's repo.  The first entry in the table should be the total
-number of team meetings held by the team.}
+% \wss{For each team member how many team meetings have they attended over the
+% time period of interest.  This number should be determined from the meeting
+% issues in the team's repo.  The first entry in the table should be the total
+% number of team meetings held by the team.}
 
 \begin{table}[H]
 \centering
 \begin{tabular}{ll}
 \toprule
 \textbf{Student} & \textbf{Meetings}\\
 \midrule
-Total & Num\\
-Name 1 & Num\\
-Name 2 & Num\\
-Name 3 & Num\\
-Name 4 & Num\\
-Name 5 & Num\\
+Total & 4\\
+Awurama & 4\\
+Fei & 3\\
+Ghena & 4\\
+Haniye & 4\\
 \bottomrule
 \end{tabular}
 \end{table}
 
-\wss{If needed, an explanation for the counts can be provided here.}
+Most communications have been made over Discord channels outside of meeting times.
 
 \section{Supervisor/Stakeholder Meeting Attendance}
 
-\wss{For each team member how many supervisor/stakeholder team meetings have
-they attended over the time period of interest.  This number should be determined
-from the supervisor meeting issues in the team's repo.  The first entry in the
-table should be the total number of supervisor and team meetings held by the
-team.  If there is no supervisor, there will usually be meetings with
-stakeholders (potential users) that can serve a similar purpose.}
+% \wss{For each team member how many supervisor/stakeholder team meetings have
+% they attended over the time period of interest.  This number should be determined
+% from the supervisor meeting issues in the team's repo.  The first entry in the
+% table should be the total number of supervisor and team meetings held by the
+% team.  If there is no supervisor, there will usually be meetings with
+% stakeholders (potential users) that can serve a similar purpose.}
 
-\noindent \textbf{Supervisor's Name: } [fill in this information]
+\noindent \textbf{Supervisor's Name: Dr. Spencer Smith}
 
 \begin{table}[H]
 \centering
 \begin{tabular}{ll}
 \toprule
 \textbf{Student} & \textbf{Meetings}\\
 \midrule
-Total & Num\\
-Name 1 & Num\\
-Name 2 & Num\\
-Name 3 & Num\\
-Name 4 & Num\\
-Name 5 & Num\\
+Total & 1\\
+Awurama & 1\\
+Fei & 1\\
+Ghena & 1\\
+Haniye & 1\\
 \bottomrule
 \end{tabular}
 \end{table}
 
-\wss{If needed, an explanation for the counts can be provided here.}
+% \wss{If needed, an explanation for the counts can be provided here.}
 
 \section{Lecture Attendance}
 
-\wss{For each team member how many lectures have they attended over the time
-period of interest.  This number should be determined from the lecture issues in
-the team's repo. You can find the number of lectures in the time period of
-interest by looking at the
-\href{https://calendar.google.com/calendar/u/0/embed?src=rnboqiaki1k2la7rpu3bn0um58@group.calendar.google.com&ctz=America/Toronto}
-{Google calendar} for the capstone course.}
+% \wss{For each team member how many lectures have they attended over the time
+% period of interest.  This number should be determined from the lecture issues in
+% the team's repo. You can find the number of lectures in the time period of
+% interest by looking at the
+% \href{https://calendar.google.com/calendar/u/0/embed?src=rnboqiaki1k2la7rpu3bn0um58@group.calendar.google.com&ctz=America/Toronto}
+% {Google calendar} for the capstone course.}
 
-\wss{NOTE: There will be approximately 1 lecture between the POC and Rev0 demos}
+% \wss{NOTE: There will be approximately 1 lecture between the POC and Rev0 demos}
 
 \begin{table}[H]
 \centering
 \begin{tabular}{ll}
 \toprule
 \textbf{Student} & \textbf{Lectures}\\
 \midrule
-Total & Num\\
-Name 1 & Num\\
-Name 2 & Num\\
-Name 3 & Num\\
-Name 4 & Num\\
-Name 5 & Num\\
+Total & 1\\
+Awurama & 0\\
+Fei & 1\\
+Ghena & 1\\
+Haniye & 0\\
 \bottomrule
 \end{tabular}
 \end{table}
 
-\wss{If needed, an explanation for the lecture attendance can be provided here.}
+% \wss{If needed, an explanation for the lecture attendance can be provided here.}
 
 \section{TA Document Discussion Attendance}
 
-\wss{For each team member how many of the informal document discussion meetings
-with the TA were attended over the time period of interest.}
+% \wss{For each team member how many of the informal document discussion meetings
+% with the TA were attended over the time period of interest.}
 
-\noindent \textbf{TA's Name: } [fill in this information]
+\noindent \textbf{TA's Name: Tanya Djavaherpour} 
 
 \begin{table}[H]
 \centering
 \begin{tabular}{ll}
 \toprule
 \textbf{Student} & \textbf{Lectures}\\
 \midrule
-Total & Num\\
-Name 1 & Num\\
-Name 2 & Num\\
-Name 3 & Num\\
-Name 4 & Num\\
-Name 5 & Num\\
+Total & 1\\
+Awurama & 1\\
+Fei & 1\\
+Ghena & 1\\
+Haniye & 1\\
 \bottomrule
 \end{tabular}
 \end{table}
 
-\wss{If needed, an explanation for the attendance can be provided here.}
+% \wss{If needed, an explanation for the attendance can be provided here.}
 
 \section{Commits}
 
-\wss{For each team member how many commits to the main branch have been made
-over the time period of interest.  The total is the total number of commits for
-the entire team since the beginning of the term.  The percentage is the
-percentage of the total commits made by each team member.}
+% \wss{For each team member how many commits to the main branch have been made
+% over the time period of interest.  The total is the total number of commits for
+% the entire team since the beginning of the term.  The percentage is the
+% percentage of the total commits made by each team member.}
 
 \begin{table}[H]
 \centering
 \begin{tabular}{lll}
 \toprule
 \textbf{Student} & \textbf{Commits} & \textbf{Percent}\\
 \midrule
-Total & Num & 100\% \\
-Name 1 & Num & \% \\
-Name 2 & Num & \% \\
-Name 3 & Num & \% \\
-Name 4 & Num & \% \\
-Name 5 & Num & \% \\
+Total & 44 & 100\% \\
+Awurama & 18 & 41\% \\
+Fei & 6 & 14\% \\
+Ghena & 0 & 0\% \\
+Haniye & 20 & 45\% \\
 \bottomrule
 \end{tabular}
 \end{table}
 
-\wss{If needed, an explanation for the counts can be provided here.  For
-instance, if a team member has more commits to unmerged branches, these numbers
-can be provided here.  If multiple people contribute to a commit, git allows for
-multi-author commits.}
+% \wss{If needed, an explanation for the counts can be provided here.  For
+% instance, if a team member has more commits to unmerged branches, these numbers
+% can be provided here.  If multiple people contribute to a commit, git allows for
+% multi-author commits.}
+\noindent\textit{Note:} These commit counts are not an accurate depiction
+of overall contribution. Most development work for the tool
+was completed on a separate branch and has not yet been merged
+into \texttt{main}, so the \texttt{main} branch commit totals
+underrepresent the actual work completed during this period.
 
 \section{Issue Tracker}
 
-\wss{For each team member how many issues have they authored (including open and
-closed issues (O+C)) and how many have they been assigned (only counting closed
-issues (C only)) over the time period of interest.}
+% \wss{For each team member how many issues have they authored (including open and
+% closed issues (O+C)) and how many have they been assigned (only counting closed
+% issues (C only)) over the time period of interest.}
 
 \begin{table}[H]
 \centering
 \begin{tabular}{lll}
 \toprule
 \textbf{Student} & \textbf{Authored (O+C)} & \textbf{Assigned (C only)}\\
 \midrule
-Name 1 & Num & Num \\
-Name 2 & Num & Num \\
-Name 3 & Num & Num \\
-Name 4 & Num & Num \\
-Name 5 & Num & Num \\
+Awurama & 8 & 15 \\
+Fei & 12 & 25 \\
+Ghena & 43 & 4 \\
+Haniye & 20 & 9 \\
 \bottomrule
 \end{tabular}
 \end{table}
 
-\wss{If needed, an explanation for the counts can be provided here.}
+% \wss{If needed, an explanation for the counts can be provided here.}
 
 \section{CICD}
 
-\wss{Say how CICD is used in your project}
-
+% \wss{Say how CICD is used in your project}
+We use GitHub Actions to support both documentation
+and software development workflows. For documentation,
+GitHub Actions automatically builds/compiles modified
+\LaTeX{} files on pull requests and merges to \texttt{main}.
+Members merge changes into a feature branch after comments
+are addressed. When at least two team members have approved,
+the feature branch changes are merged into \texttt{main}.\\
+
+For the software workflow, active development takes place
+in our \texttt{release} branch. When changes are pushed or
+a pull request is opened to update \texttt{release} or merge
+into \texttt{main}, GitHub Actions runs automated checks on pull requests
+(e.g., the \texttt{Run Tests} workflow) before merging. These checks help ensure changes
+integrate cleanly before merging. Once the \texttt{release}
+branch is stable and reviewed, it is merged into \texttt{main}.
 \section{Team Charter Trigger Items}
 
-\wss{Provide a summary of the quantified triggers identified in the team's
-charter.}
-
-\wss{Provide a list of any violations of the triggers.  If the team wishes, the
-violations can be summarized on aggregate, instead of naming specific team
-members.}
-
-\wss{Provide a plan to address the violations.  This could include revising the
-triggers, if they are found to be too weak, strong or ambiguous.}
+% \wss{Provide a summary of the quantified triggers identified in the team's
+% charter.}
+\subsection{Summary of Triggers}
+\begin{enumerate}
+\item{Attending every weekly Monday virtual meeting during lecture time when there are no lectures. Unless the whole team decides to cancel}
+\item{Team members expected to attend all meetings on time, fully prepared and having reviewed relevant materials and the agenda for the meeting}
+\item{All deliverables must meet the team's agreed-upon standards}
+\item{Deliverables must be reviewed by all assigned team members through the "reviewed" confirmation on GitHub, before deliverables are ready to be merged.}
+\item{Feedback on deliverables and revisions must be made within 24 hours}
+\end{enumerate}
+
+% \wss{Provide a list of any violations of the triggers.  If the team wishes, the
+% violations can be summarized on aggregate, instead of naming specific team
+% members.}
+No present trigger violations.
+% \wss{Provide a plan to address the violations.  This could include revising the
+% triggers, if they are found to be too weak, strong or ambiguous.}
 
 \section{Additional Productivity Metrics}
-
-\wss{If your team has additional metrics of productivity, please feel free to
-add them to this report.}
+No additional productivity metric was used by the team.
+% \wss{If your team has additional metrics of productivity, please feel free to
+% add them to this report.}
 
 \end{document}