Updated Staff Management System docs

[Kevinking500]

Type of PR

• Translation update / creation
• New documentation page
• Content update (not a typo fix)
• Typo / grammar fix

Summary

This PR updates the SMG module documentation to actually represent the module and not make made up information

Checks

• I have verified that my changes do not contain em dashes, smart quotes, or other special characters (the CI lint will catch these).
• If I changed an original (English) file's content or meaning, I have updated all translations of this file.
• If I added a new page, it has correct frontmatter (sidebar_position, title, description).

[cloudflare-workers-and-pages]

Deploying scnx-docs with    Cloudflare Pages

Latest commit:	715024d
Status:	⚡️  Build in progress...

View logs

[Kevinking500]

@SCDerox Could you confirm if my method with data storage/usage is fine? It's a big module, so I am committed to the data transparency. I think it doesn't look bloated at all actually when previewing it.
Please lmk :)

[SCDerox]

Thanks for bringing this up, I'll flag it internally and will get back to you within approximately 2 business days. Thank you for your patience!

[Kevinking500]

Huh?

[Kevinking500]

@SCDerox Sorry again, but your last comment was a bit confusing. Could you please confirm if my method is fine? The main reason I am doing it is because every single name (spread across the many models this module has) serves a different purpose for each feature

[Kevinking500]

Guess I don't know. Could you check what might be wrong?

[SCDerox]

Thanks for being so patient today!

The build fails because PR #140 contains this malformed heading in staff-management.md line 638:

  ### Staff Shift {data-usage-shifts}

It should be:

  ### Staff Shift {#data-usage-shifts}

Without a #, MDX treats {data-usage-shifts} as a JavaScript expression.

As a helper, you can find build logs here: https://dingbot.scootkit.com/docs-build

---

Also regarding the formatting of the data used section, please avoid using detail tags so we can render the raw markdown more easily outside the docs themselves (e.g. in files and other plattform surfaces).

[Kevinking500]

Thanks for the bug fix - Though could you explain the last part a bit more, as in like not having those headers with tags, and instead like bolded titles so that the stored data section is 1 name?
If so, I can quickly do that ^^

[Kevinking500]

Ohh wait do you mean the tags themselves and keeping the headers?
Please lmk :)

[Kevinking500]

Oh wait I just realized, do you mean the dropdowns? (

Details

stuff)
If so, should I replace it with a table or just bullet points, lmk what's best

[SCDerox]

Yeah, we replacing with either a table or bullet points would be awesome if possible

[Kevinking500]

Forgot to say it, whoops - I changed them to bullet points and it's ready for review ^^

[SCDerox]

Thanks for the big rewrite, Kevin! Quick note: I used AI to help check the claims in the docs against the module code, and this comment was AI-generated to summarize what it found. Reading the page through myself, it looks good. The config tables and the command table match the module exactly. The comparison did turn up a few places where the docs don't match what the code does. Most of these are in the Stored data section, which is the part that has to be accurate.

Data deletion claims

The data deletion options in the user panel (executeDataDeletion in staff-management.js) do less than the docs say:

• Staff Profile: the docs say all StaffProfile data is deleted with "Delete Shifts". It only resets onDuty, onBreak, breakStartTime and lastClockIn. The profile row itself is never deleted, not even by "Delete ALL data" (that clears nickname, intro and suspension fields but keeps the row).
• Staff Shift: the docs say all StaffShift data is deleted with "Delete Shifts". No StaffShift rows are deleted at all.
• LoA/Status requests: the docs say all LoaRequest data is deleted with "Delete Status". No LoaRequest rows are deleted. Only activityStatus on the profile is set to null.
• Activity Checks: deleting ActivityCheckResponse rows works, but the user's ID stays in the respondedUsers field of ActivityCheck.
• Infractions and Reviews: only rows where the user is the target are deleted. Infractions they issued (issuerId) and reviews they wrote (authorId) stay.
• Promotions: the Promotion model is missing from Stored data, even though the panel has a "Delete Promotions" option. Please add a section for it.
• Timestamps: all models store createdAt/updatedAt timestamps, which should be listed too.

There are two ways to fix this: change the deletion logic in the module so it matches the docs, or change the docs to describe what actually gets deleted. Either works, but the docs shouldn't promise more than the code does.

Behaviour claims

• /duty time (Shifts section + command table): the docs say you can view "your own or another user's" duty time. The command has no user option, and buildDutyTimePayload always uses the person running the command.
• Activity status (Staff Profile data): the docs list values like "off-duty, on-duty, suspended". The field only ever holds ACTIVE, LOA or RA. Duty and suspension are stored in onDuty and isSuspended.
• /staff-management panel (command table): the docs say "Supervisors+ only", but I couldn't find a permission check when the panel opens or when switching between its pages. /staff-management infraction history has no check either. Only the data deletion itself is limited to management. Can you check this? If it's meant to be supervisors+, it probably needs a fix in the module rather than the docs.
• Minimum shift duration (Shifts section + troubleshooting): shifts under the minimum aren't just left out of the total. The shift record is deleted when the shift ends. Please say that explicitly so admins know those shifts can't be recovered.
• Activity checks (Features): the docs say "admins" can host activity checks. It's actually supervisors and above.
• RA configuration rows: "Maximum RA Duration" and "Require Approval for RA?" still have the LoA text ("request an LoA", "LoA requests require...").
• Enable Status System: it's off by default, and the LoA/RA commands only appear once it's turned on. Please mention this in the "I cannot see the commands" troubleshooting entry, since enabling only LoA or RA isn't enough.

Thanks again, this is a big improvement over the previous version!

[Kevinking500]

I'll circle back to this tomorrow when I am back on my computer, I actually used AI to check which parts were deleted and basically told me what's in the docs, so I'll manually re-check tomorrow since I genuinely forgot what gets deleted. Thanks for letting me know