How I Actually Use Sociology Planner Weekly Instead of Fighting It
The first time I installed it, I spent three hours trying to get the recurrence engine to handle biweekly class meetings that skipped one week out of every two. The documentation says it supports custom intervals, but the UI only shows a simple dropdown for daily, weekly, and monthly. I ended up writing a small Python script that exports the planner data to CSV, filters out the weeks I don't need, and re-imports it. That workaround still works fine. I haven't bothered to find a prettier solution. Sociology Planner Weekly is essentially a scheduling layer built on top of a sociology department's recurring events — seminar series, reading groups, office hours, thesis defenses, grant deadlines. It isn't a full LMS. It doesn't manage grades or student submissions. What it does do is centralize the weekly rhythm of academic life so nobody has to check five different spreadsheets to figure out who is presenting next Tuesday.
What Makes Sociology Planner Weekly Different From a Normal Calendar
A normal Google Calendar treats every event as atomic. You create it once and it exists. A sociology department doesn't work like that. Reading groups rotate leads every week. Guest lectures arrive with a two-week notice and sometimes get swapped. Office hours shift when a faculty member is at conference. The planner handles this by treating recurring patterns as first-class objects rather than just "repeat this event." The core data model has three layers. Patterns define the recurring skeleton — things like "every Wednesday 4pm reading group." Sessions are individual instances that may override the pattern — a canceled meeting or a special guest. Dependencies link sessions together so that when one event moves, connected events automatically prompt a review. This third layer is the part most people skip over initially, and it is also the part that saves you from disasters later. I learned this the hard way in 2023. Our department had a dissertation defense scheduled for April 14. The committee had three other events that week. When the defense got moved to April 21, the planner should have flagged the conflict with the visiting scholar's colloquium that the committee member had already committed to attending. It didn't. I spent the next week manually checking Slack threads because the dependency engine was disabled by default. The fix was to enable the auto_review_dependencies flag in the config file. It is not obvious where that lives. The setting is buried under Admin > Advanced > Recurrence Behavior. If you are running this for a department larger than ten people, turn it on immediately.
Installation and First-Time Setup
The software runs on Node 18 or later. It needs a PostgreSQL database — SQLite will technically work for a single user, but it corrupts the recurrence index under any real load. I have seen it happen twice. Both times the department lost a semester's worth of reading group schedules. Download the latest release from the official repository and run the setup wizard. It will ask for the database URL, an admin password, and whether you want to enable LDAP integration. If your institution uses Active Directory, just say yes and paste the domain controller address. If you do not have LDAP and try to force it anyway, the auth module will silently fail and lock every user out of the calendar view. That happened to my colleague. He spent four hours resetting the authentication config. After installation, the default state is a bare skeleton with no departments, no users, no recurring patterns. You have to build everything from scratch. The import feature accepts a JSON file with the standard format, which helps if you are migrating from another tool. The format is documented but the examples are thin. I ended up reverse-engineering mine by exporting a working instance and inspecting the output.
Get the Full Details
Configuring the Weekly Rhythm
Let me walk through what actually matters in practice rather than repeating the manual. First, create your departments. Each department gets its own namespace. Faculty and graduate students are assigned to one or more departments. This is straightforward. Second, define your patterns. This is where most people waste time. A pattern is not a calendar rule. It is a template that generates sessions. When you create a weekly reading group, you are not creating "a recurring event." You are creating a pattern that knows how to generate individual session objects for the current academic year. The planner will generate sessions up to 90 days into the future by default. You can change that window in the config. Setting it too far out creates database bloat. Setting it too short means you have to regenerate constantly.
Third, handle overrides. A canceled meeting is an override. A changed location is an override. A substitute speaker is an override. The key insight is that overrides do not break the pattern. They sit on top of it. When you look at the planner six months from now, you see the original pattern structure with the overrides marked. This makes it easy to spot anomalies. If a pattern has three overrides in a row for the same recurring slot, something is wrong and you should investigate. Fourth, set up dependencies. Link defense dates to committee availability. Link colloquia to room bookings. Link reading groups to the assigned reader. This is the layer that prevents the kind of double-booking nightmare I described earlier. It also adds latency to certain operations. When you move a defended event, the planner has to traverse the dependency graph and prompt every connected session. For large departments with hundreds of linked events, this can take several seconds. I have seen it timeout on the web interface. The workaround is to move events during off-peak hours or use the CLI instead of the browser.
Common Problems and What to Do About Them
The recurrence index gets corrupted. This is the PostgreSQL issue I mentioned. If your planner starts showing missing sessions or duplicate entries, check the recurrence_index table for gaps. The fix is to run the built-in repair command: planner repair --full. It rebuilds the index from the pattern definitions. It takes about twenty minutes for a typical department. Do not skip the --full flag. The incremental mode misses edge cases in schedules. LDAP auth stops working after a semester break. Your institution's directory server rotates certificates or changes the bind DN between terms. The planner caches the LDAP connection for performance. When the cache becomes stale, users see "authentication failed" even though their credentials are correct. Clear the cache with planner cache clear --auth and restart the service. If that does not help, check whether your AD schema changed. I have seen this happen when the IT team updates the group policy. Export to iCalendar produces duplicate events. The ICAL export has a known bug where overridden sessions get emitted twice — once as part of the expanded recurrence and once as the override itself. The maintainer is aware of it. The workaround is to filter the exported file through a small cleanup script before importing it into Google Calendar or Outlook. The script removes any DTSTART that appears more than once with the same SUMMARY.
The web UI freezes when viewing more than 60 days at once. This is a rendering issue, not a database issue. The planner loads all sessions into a single JavaScript array and renders them client-side. For departments with high event density, that array gets too large. Switch to the compact view or reduce the visible range to 30 days. The compact view uses virtual scrolling and stays responsive even with thousands of sessions.
Who Should Not Use This
If your department has fewer than five people and only needs a simple shared calendar, do not install this. It is overkill. A shared Google Calendar with color-coded events will serve you better and with half the maintenance overhead. If your institution blocks Node.js on its internal servers or requires software to be signed by an approved certificate authority, you will struggle. The build process is not set up for enterprise deployment out of the box. I have a fork that adds a Code Signing config and a Dockerfile, but maintaining it takes time. If you need grade management, LMS integration, or student-facing submission portals, this is not the tool. It is strictly a scheduling and coordination layer. People who expect it to replace Canvas or Moodle will be disappointed.
Bottom Line
Sociology Planner Weekly does what it claims to do. The claim is narrow enough to be believable — coordinate recurring academic events across multiple departments with override support and dependency tracking. The reality is close to that claim, with a few sharp edges around database maintenance, LDAP stability, and export correctness. If you are willing to invest a few hours in initial setup and keep an eye on the recurrence index, it will save you probably three to five hours per semester in scheduling conflicts and manual coordination. That is the actual ROI. Everything else is secondary.
