A running record of the improvements shipped to SRKR's ERP, Academics Portal, and Instructor App — in plain language, updated every couple of weeks.
At the college's request, course schedules for the 5th and 7th semesters across all branches are being prepared for 21 to 31 October. The regular 7th-semester schedule is done and the 5th-semester regular schedule is in progress; Open Elective schedules for both semesters follow after that.
Arrear payments covering February to July 2026, paid out in September, have been recorded as Additional Salary records so they flow into the September salary slips. Two new salary components were created for this: Arrear Pay (an earning) and Income Tax on Arrear Pay (a deduction), both rounded to the nearest whole number, with arrear pay excluded from EPF and ESI. The records are dated 30 September and are picked up automatically when the September Payroll Entry is run. A requirements document for a dedicated Arrear Payment Report has been shared with the development team.
All lateral-entry students' IDs were updated with their registration numbers, and their student groups were updated in the ERP to match the list provided by the college.
Teachers were sometimes seeing a 'Submission Failed' error when marking attendance, because the background report refresh was holding on to attendance records and making submissions wait until they timed out. The refresh no longer blocks attendance entry. It now runs about once an hour instead of every 20 minutes, and skips the first minutes after each period starts, when teachers are marking attendance. Dashboards still refresh within the hour. This is the follow-up to the refresh-frequency change mentioned in the September performance upgrade.
Refresh jobs now run at READ COMMITTED with a commit after each REPLACE, so the SELECT side no longer takes shared next-key locks on every attendance row (a live run held several million row locks for minutes). Period starts are read from today's Course Schedule: the 5-minute tick never starts within 15 minutes after a period start, or if its 5-minute budget would overlap the next period, and runs at most about hourly. Expected after deploy: lock-wait errors in the Error Log drop to near zero.
Before running final enrollment, the new student data was cross-checked against the college's own lists. This found duplicate student records, inconsistent roll numbers and seat categories, lateral-entry students set to the wrong semester and regulation in the draft, and approved applicants who had never been converted into student records. First-year applicants were then enrolled, and section-wise student groups were created and filled for the first-year branches using the final class lists. Still in progress: the differences found are with the college administration for verification, two branches are on hold for revised class lists, and lateral-entry students are yet to be enrolled in Semester 3, pending confirmation of the regulation that applies.
Previously a new student's program enrollment pulled in every required course of the program, including courses from older regulations and other semesters. Enrollments now fill in only the required courses for the student's own regulation, which defaults from their batch. This also fixed lateral-entry students, who start at Semester 1 by default but need their regulation's courses from all semesters, and had to be corrected by script. Only draft enrollments with an empty course list are affected; submitted enrollments and hand-added courses are left alone.
CustomProgramEnrollment registered via override_doctype_class. Courses are the required Program Course rows matching the enrollment's regulation. First version also filtered on current semester (40a3ba7); changed to regulation only (cdd1a5a). With no regulation the table stays empty and fills on next save; a regulation with no required courses shows a warning.
The R26 regulation courses and syllabus data for Semester I were received on 1 October, and the first phase of digitising them is done. Syllabi for 12 B.Tech programs have been extracted and structured into a topic library (about 1,500 topics worded exactly as in the official syllabi), a course catalogue with credits, contact hours, assessment marks and descriptions, and mappings from courses to topics and from programs to courses. Courses shared by several programs, such as English, Mathematics, AI Tools and C Programming, are stored once and linked to each program after being checked against every syllabus. The data is ready for review and upload to the platform.
At the college's request, second-year course schedules were deleted for the mid-exam dates, and schedules for 24 and 25 September were removed because those days were declared holidays due to heavy rain. Clearing them keeps attendance and compliance reports from flagging classes that were never meant to happen. Separately, a student who was missing from an Open Elective III student group was added to the correct group.
June and July 2026 payroll were processed together with the Payroll Officer and checked against the source Excel data, with a full match on both; salary slips and payroll entries were submitted for both months. A few payment-day corrections for new joiners with partial loss of pay were applied for June. HR Reports were handed to the Payroll Officer for feedback and acceptance. For August, the data was analysed against July, processing files and a step-by-step instruction document were prepared, and the Payroll Officer is scheduled to process it independently.
The Students table inside every Student Group now includes a Student ID column. It is filled in automatically from the student's record, is read-only, and updates on its own whenever a student is linked, so nobody has to type it. The change applies to all Student Groups across all programs and batches.
Employee records now carry a Bill Category (Regular, PG or BBA). PG is assigned manually for faculty teaching M.Tech courses, BBA is worked out automatically from the department, and Regular is the default for everyone else; all existing employee records were updated and verified. A new LIC Policy record type was also added under HR to store each employee's policy number and monthly premium, with support for multiple policies per employee. Existing policy details were imported, and some employees with LIC deductions are still waiting on HR to supply their policy details.
Program enrollment for the Artificial Intelligence & Data Science program for the 2026-27 academic year has been submitted in the system. The team is now waiting on the R26 curriculum from the Dean of Academics before the program setup can be completed.
Attendance compliance reports for the Mechanical department were showing one unmarked class even though all classes for the day had been taken. The discrepancy was traced to a course schedule date issue, and attendance was submitted individually for the affected students to bring the records in line.
For one 3rd-year batch, the Daily Attendance report wasn't showing the lab subject for one course. The cause: the lab's Course Schedule record was never created — only the corresponding theory course's was — so there was nothing for lab attendance to attach to in the report. The gap has been flagged to the Admin Coordinator to create the missing schedule. Logged here as identified, not yet resolved.
Some users hit slowness on a Monday afternoon, especially while submitting attendance. The team identified the root cause the same evening and completed a major infrastructure upgrade that night, with zero downtime and no data loss — attendance submission was verified back to normal by evening and monitored closely through the following week. The underlying cause was rapid, genuine growth in attendance data combined with dashboards (Daily Register, HOD, and Principal views) refreshing every 20 minutes, which together pushed the database past its disk throughput limit during peak attendance-submission hours. Storage capacity and disk performance were substantially increased, the queries behind attendance screens were optimized to read only what they need instead of scanning everything, and search indexes were rebuilt for faster lookups across the system.
Scale at time of investigation: attendance records in the multi-million range, growing roughly half a million per month. Dashboards refresh every 20 minutes, recomputing the term's attendance dozens of times a day on top of live submissions — this combination pushed the database past its disk throughput ceiling during peak hours. Upgrade: substantially increased storage capacity and sustained disk performance (removes the burst-capacity ceiling that caused the slowness), query optimization so attendance screens read only needed rows instead of scanning everything, and a rebuilt search index. The team has also proposed moving report refresh from every 20 minutes to hourly to cut daytime load roughly 3x — not yet rolled out as of this entry; add a follow-up once it actually ships.
The Daily Register report can now be expanded into a period-by-period view for a section, across all of that day's subjects — click any date, or use the new date picker with a one-tap Today button. Each period shows present/absent status and an absentee count, and periods that haven't been posted yet are clearly marked as pending. This makes a practice that one department found effective — calling absent students right after each period's attendance is posted — effortless for every department, since an absentee list with contact info for that period is ready the moment attendance is posted.
Period-by-period view covers P1–P8. Each period's absentee list includes student ID, name, and mobile number (tap to call on a phone). Motivated by the EEE department's practice of calling absentees right after each period's attendance was posted, which measurably improved their attendance.
A detained student was removed from a mentor's counselling list following a department request. Separately, an employee record update was failing with a file-upload error — the employee's photo was already stored correctly, but the file path was mishandled during save. The same photo was successfully re-uploaded as a workaround while the underlying path-handling issue is looked at.
The daily job that texts parents when a student is marked absent, and the reminder that nudges instructors who haven't taken attendance, used to run every day regardless of whether classes were actually held. Both now check the college's holiday calendar first and skip themselves entirely on a holiday, since there's no attendance to summarize or remind anyone about on a day with no classes.
New _is_holiday() helper checks the default Company's default Holiday List for the processing date via frappe.db.exists. Wired into both send_daily_attendance_summary() and send_instructor_attendance_reminders() — each returns early with a log line if today() falls on a holiday.
The Holiday List for the new academic year (June 2026 to May 2027) was created and set as the college's default. Course Schedules that fell on the newly-added holidays were backed up and then removed, so they no longer show as expected classes on days there aren't any. Separately, final-year course schedules across all branches were removed for the mid-exams window per a department request, one student's record was disabled following a branch-status change, and an employee profile's user-ID mapping was corrected after a role-removal error.
This holiday list — and the company's default_holiday_list setting — is what the 2026-08-31 holiday-skip logic for the daily attendance summary and instructor reminder jobs (srkr_frappe_app_api) actually depends on to work; that code change landed a few days after this config was in place.
Continued progress on the payroll migration first reported in July: the Payroll Manager was walked through the full ERP payroll process end-to-end and independently re-verified March and April 2026 against the source Excel data, both confirmed correct. May 2026 payroll was then processed and verified successfully. Step-by-step instructions and all the data files needed for June and July were handed off, so the Payroll Manager can now process those two months independently rather than relying on the implementation team.
Walkthrough covered employee master setup through Payroll Entry, salary slip generation, LOP correction, and submission. June/July handoff materials: a step-by-step HTML instruction document plus data import files (Salary Structure Assignment, Additional Salary, DA/HRA updates, Tax, LOP reference) for both months.
Three improvements shipped to the Academics Portal's Reports Module based on feedback from professors and coordinators. The below-75%-attendance watchlist under My Class & Pending Works can now be narrowed by course and section before downloading or printing, and the exported file records which filters were used. The Daily Register now shows how many sessions were held on each date directly in the table, instead of only on hover. Program Coordinators can now access department-scoped reports themselves, the same view HODs already have, instead of going through a HOD.
Filters: 'All courses' / 'All sections' options included; Excel download and print output both respect the selected filters and print the selection criteria (instructor, academic year, semester, course, section) on the report. Daily Register: sessions-held count moved from a hover tooltip to a persistent row under the date; carried into the Excel export too. Access: SRKR Program Coordinator Profile now gets the same department-scoped Reports Module view as HOD; coordinators need to log out/in once to pick it up, and their Employee record must have a Department assigned.
Publishing or hiding an event in the Admin Portal wasn't reliably showing up on the public college website. Two causes were found and fixed: the website had been falling back to a handful of outdated built-in events whenever nothing current was published (these didn't exist in the portal at all, which is why hiding them in the portal did nothing), and separately, real status changes depended on a roughly 2-minute site rebuild that could silently fail and never show the change at all. The website is now the portal's live mirror for event status — publish or move an event to Draft, and it shows up (or disappears) within about a minute, no rebuild required.
The stale built-in fallback event list has been removed entirely — the portal is now the single source of truth with no fallback. The website now reads event status live from the portal rather than waiting on the static-site rebuild. Two statuses exist: Published (visible) and Draft (hidden). Past-dated events never appear in Upcoming Events sections even when Published, by design — verify with a future-dated event.
A 2nd-year ECE section's student mentorship profiles were updated per a department request. Separately, 3 students who had been placed in the wrong Open Elective group were reassigned to the correct one and removed from their old group, so they no longer appear in both places.
A sample export of a class group's student list was generated and shared to demonstrate the export feature. Reviewing the sample surfaced a gap: the exported list doesn't currently include student register numbers, which support staff need for their downstream work. This has been logged as a needed enhancement rather than a completed fix.
An Open Elective change list was received for third-year first semester, a second Open Elective addition needed group-name clarification and a recheck against existing assignments, and an AIML section showing an inflated student count was corrected.
A mentor reassignment request was received but held pending confirmation after it conflicted with a newer list; counselling data for CSE, AIML and CIC second-year students was added to the reporting system across two follow-up rounds; and two mentor records were replaced in the second-year mentor data on request.
The reporting site was reported as running slowly with an accompanying attendance-submission error, and a separate report of intermittent slow loading was investigated in person — the site was found to be responding normally at check time.
Searching and filtering course schedule records — by course code, instructor, class group, or date — was slow during busy hours, and staff had reported it. The way these records are looked up was optimized, and course-schedule lists and filters that used to take noticeably long now respond almost instantly, even at peak usage. Confirmed working in production two days after rollout, with no more of the slow responses that had been reported before.
Course schedules for a second declared holiday (Aug 10) were removed to prevent attendance being logged that day.
A dense week — roughly eight separate requests: a data/group update was scheduled, a student was added to a third-year ECE section, a register-number clarification closed out a Civil-B section list, an Open Elective addition needed batch clarification, a section-number correction was made for a second-year section, a reported student-number error was corrected, and second-year EEE and ECE class lists and lab batches were refreshed against the latest merit lists.
Mentor data was updated and confirmed complete for the week.
The safety-net check that alerts staff when some students still haven't received their absence SMS was itself crashing on a formatting bug — meaning on at least one night, 42 absent students went unnotified with no alert raised to anyone. That's now fixed.
frappe.log_error was called with arguments in the wrong order, exceeding the Error Log title's 140-character limit and throwing before the retry batch could dispatch. Confirmed in prod on 2026-08-11 20:30. Fix: pass title/message as keywords.
Course schedules for a declared holiday (Aug 5) were removed college-wide so attendance wasn't taken in error.
Follow-up confirmed that a detained-student list had been fully processed.
Staff records were updated from five supplied PF numbers, though one could not be located and was held for follow-up; a mentor-mentee file update carried over from the prior week was confirmed complete; and an updated mentor-mentee spreadsheet was forwarded to the implementation team for processing.
An attendance-compliance discrepancy flagged in a department HOD's marking-compliance report was investigated, and attendance was updated once the underlying issue was resolved.
The daily 6 PM job that texts parents when a student is marked absent was silently failing partway through — it needs 11-12 minutes to text ~2,000 students one by one, but the job's time limit killed it after 5 minutes with no error raised. On every normal school day from July 30 to August 6, only 800-1,300 of ~2,000 absent students actually got notified. The job now splits the work into small batches that run in parallel with automatic retries, so it reliably finishes and every family gets notified.
send_daily_attendance_summary is now a fast dispatcher that enqueues 100-student batches on a long-running queue (1,500s timeout) with deduplicated job IDs. Retry sweeps added at 19:00 and 20:30; the final sweep raises an Error Log alert if anyone is still un-notified.
A duplicated class-schedule issue for a 4th-year Civil section was resolved by rescheduling the affected course.
14 new Open Elective (OE-IV) courses were imported and OE-III groups were updated from a revised list; a student-level regulation mismatch was flagged and held pending confirmation; and an incorrect student number reported for a 2nd-year AIML section was queued for correction.
A mentor transfer request was processed; mentor and teaching-staff files were received and reconciled against employee records, with an employee-list filtering approach worked out for future use — present mentor data was updated while records missing source information were held back for follow-up.
A question about whether Professional Elective classes were counted in 4th-year ECE cumulative attendance was raised after a report appeared lower than expected; clarification was requested.
A department's attendance and at-risk numbers were blending its own students with students from other branches just visiting for an open elective — sometimes more visitors than own students (EEE: 937 visiting vs. 424 own). This made department numbers misleading and put students HODs had no authority over onto their at-risk lists, while dropping some of their own genuinely at-risk students from those lists. Dashboards now show both populations separately, and every at-risk list is scoped correctly to the students each HOD can actually act on.
Classification now runs on Program Enrollment rather than group name (group type couldn't distinguish labs from electives). At-risk percentages are now computed cumulatively across every course a student takes, not just courses within the viewing department — closing a gap where 149 students below 75% college-wide looked clear on their home department's list.
Previously, picking a semester in the portal mixed all four years of students together, since "semester" refers to the term, not the year. Principal and HOD views now have a Year of Study filter that applies across KPIs, the attendance heatmap, marking compliance, and at-risk lists. A related fix also removed "All Departments" (a data artifact, not a real department) from every department picker, where it had been incorrectly showing a mix of unrelated open-elective students.
A course-swap display issue affecting a 4th-year section and a similar Civil-department case was investigated after the wrong course appeared selected in the schedule.
Another dense week — around eight separate group/list requests: ECE Professional Elective groups were finalized, Civil second-year class lists were corrected for missing/incorrect section numbers, a misplaced student was moved to the correct section, second-year class and lab batches were completed for Civil, Mechanical, ECE and EEE, second-year group lists were held for consolidation against the latest master list, and revised class lists plus a Professional Elective syllabus were processed for eight departments.
Instructors were advised to use the paper Attendance Register temporarily after inconsistent student roll lists were reported, until the underlying lists could be corrected.
Previously, once attendance was submitted for a class, correcting a mistake meant escalating to a program coordinator — even for a same-day typo. Instructors can now edit attendance for their own classes up until 5 PM on the day it was taken; after that, or for any past day, it's locked exactly as before and still requires escalation.
Server computes the edit window (not the device clock) and re-validates on every submit. Corrections update existing rows only — never creates new ones — and leave an audit comment on the Course Schedule.
Two more reports moved from the old Frappe interface into the portal: a midterm marks sheet (per-question internal marks, Mid-1/Mid-2/totals) for professors, HODs, and admins, and a morning operations view showing which of today's classes have had attendance taken, partially taken, or not taken yet.
A new panel gives admissions staff a live view of applicant volume, status breakdown, and how many admitted students are still missing their allotment letter (146 as of the AY 2025-26 cycle) — timed for the new academic year's intake, which opened the same week.
A scheduling error reported while setting up the AIDS second-year timetable was investigated; the fix was still under review at week's end.
A high-volume week — roughly eight separate group/section requests: IV-year OE-IV sections were created across departments alongside a new course rollout, students were promoted from second to third semester with new OE-III groups created, EEE third-semester section counts were reconciled against the official class list, subject/syllabus mappings were processed for multiple departments, second-year groups and lab batches were created for several departments, and IV-year ECE Professional Elective groups began being built from option-form and syllabus data.
A previously reported issue was confirmed resolved, another image-reported issue was updated and confirmed fixed, and a report that student IDs weren't displaying correctly was investigated and resolved.
Submitting attendance for a full class (measured over 2,600+ real submissions) took 4.4 seconds on average and up to 34 seconds at peak times, occasionally locking up when many instructors submitted at once near the bell. The submission process was rebuilt to do the work in bulk instead of one student at a time. A data completeness issue introduced during the brief rollout window (July 15-16) was caught and backfilled — no records were lost, some optional fields were briefly blank and have since been filled in.
Old path: full Frappe document lifecycle per student (~16 queries each, 1,000+ round trips for a 67-student class). New path: one validation pass + one bulk insert per class (~6 queries total). A fetch_from field-resolution gap in the first rollout created ~47K rows with three fields NULL over the Jul 15-16 window; idempotent backfill script added, gap fixed in the resubmitted version.
Academic structure, class rosters, results, and attendance summaries now sync automatically every night from the ERP to DeployU, SRKR's LMS — the ERP stays the single source of truth, DeployU just mirrors it. This removes what was previously manual, error-prone data entry duplication between the two systems.
Rolled out in stages: structure (AYs, terms, programs, batches, sections) first, then roster/results/attendance. Nightly cron at 03:00, watermarked incremental sync after the first full load, disabled by default until explicitly enabled per site.
Classes with multiple periods in one day (double theory sessions, 4-period labs) were having their separate session records collapsed into a single cell, under-counting attendance totals. The register now correctly aggregates all of a day's sessions per student while keeping the totals accurate. A related fix also corrected a timezone bug that was mislabeling month headers (e.g. showing "Jun 2026" for July dates), and decluttered the professor's home screen so multi-period classes show as one row instead of four nearly-identical ones.
Coordinators scheduling classes can now pick a start period and a block type (single/double/4-period lab) instead of hand-typing from/to times — validated against 136,000 real schedule rows from last year. A follow-up update made the whole block conflict-safe: before creating anything, every period and date is checked for instructor, room, and section conflicts, and any conflict blocks the entire batch with a clear table of what clashed, rather than partially creating a broken schedule.
An audit found 14 of the portal's 25 report screens were dead ends. Every summary now click-throughs to its detail — department names lead to that department's dashboard, heatmap cells lead to a class's daily register, at-risk names lead to student lookup, and so on — all while staying within what each user is allowed to see.
The portal gained proper charts (department attendance bars, grade distribution), trend sparklines on KPI cards, and loading indicators. Admins and the principal now land on an institution-wide scorecard when they log in, rather than a single class's register. HODs of newer specialization departments (like AI&DS or CSBS, run under IT and CSE respectively) now also see their specialization's data on their own dashboard.
148 IV-year first-semester courses were added and the semester's class schedule was set up with defined start and end dates, completing attendance-readiness ahead of classwork.
OE-I groups were created across nine departments (ADS, AIML, CSBS, CSE-IOT, EEE, Civil, ECE, Mechanical, Mathematics), with six groups held for confirmation before being finalized.
Mentor-mentee mappings were updated on request, including a batch reassignment to one mentor; multiple faculty/PF-number mapping requests were processed for CSE, AIML and AIDS; three faculty who were visible as system users but missing from the instructor list were added for the CSE department; and mentor-list corrections were made after mismatched PF-number mappings were reported for Civil and other departments.
A reported issue was investigated from a shared screenshot; the fix was confirmed the following week.
A new, dedicated read-only reporting site went live, covering attendance, academic performance, and enrollment data across 25 role-scoped reports — 6 for professors, 9 for HODs, 8 for Principal/Management including multi-year trends, and 6 for academic administration. Every number was verified against the existing Frappe reports before launch (30/30 sections matched exactly). Login uses the existing ERP account via single sign-on. Report data refreshes automatically every 20 minutes during the day, with a full nightly rebuild.
READ_MODE=reports serves from a separate srkr_reports summary schema (9-29ms queries) kept fresh by two new scheduler jobs in srkr_frappe_app_api: incremental_refresh (every 20 min) and nightly_full_rebuild (2 AM, reconciles hard deletes). Auth via Frappe OAuth2; scope resolved server-side from role profiles.
The Full Term Daily Attendance report now correctly restricts course and student-group selection based on the instructor group a user belongs to, closing a gap where the report's filters weren't respecting those boundaries.
IV-year first-semester syllabus and subject-code mapping was requested and processed across all branches, laying the groundwork for the new term's course structure.
A revised OE-I class list was received and the corresponding student groups were updated to match.
An attendance-report manual was shared for circulation to department staff, and guidance was given on which application to use for viewing course-topic information.
The new-student-registration form (Student Applicant web form) got a full pass: new fields (Allotment Date, Ward Number, Type of Study for 10th/12th, Mandal, Study Certificate), several fields made mandatory, and a set of conditional rules so applicants are only asked for documents that actually apply to them — e.g. Ward Number, Caste/Income Certificate, and the bank passbook are only required for scholarship-eligible applicants; Guardian Aadhaar is only required if a guardian is named; XII Medium of Instruction is skipped for Lateral Entry applicants, who don't have that requirement. Guardian details were added to the form entirely. Separately, all transport routes, pickup points, and fees were refreshed in the ERP and now show live on the form when an applicant selects transport.
14 field-level changes total, all mapped to custom_* fields on Student Applicant. New fields carry over automatically to the resulting Student record on admission. Validated live: Lateral Entry applicants completed the full application successfully, exercising the scholarship, disability, and guardian conditional paths.
The payroll migration from Excel to the ERP completed its setup phases in July 2026: employees imported with new payroll-specific fields (DA%, HRA%, ESI eligibility, and more), two salary structures and 25 salary components configured with verified formulas, and April 2026 payroll verified as a full match against Excel for benchmark employees. The scope has since expanded — production is being fully rebuilt and five consecutive months (March through July 2026) will be processed in sequence as the official go-live. As of August 2026 this is still in progress, not finished: March and June are ready to process, May and July are still being analyzed, and a handful of HR/Finance decisions (duplicate designation names, cost center setup, some missing employee records) remain open.
Go-live approach: cleanup existing prod payroll config (employee records/custom fields/access control retained) → rebuild components/structures/period/tax slabs from verified formulas → process each month in sequence (change analysis → master data update → Additional Salary → Payroll Entry → verify vs. Excel → submit). Critical operational rule established: always submit all salary slips for the current month before updating master data for the next, since amending a submitted slip re-fetches current master data.