Ability to add reason for disabling commands #219

Closed
opened 2026-01-28 06:28:27 -05:00 by sirdog3355 · 5 comments
sirdog3355 commented 2026-01-28 06:28:27 -05:00 (Migrated from github.com)

What it says on the tin. I'd like the bot to be able to output why a systems operators has chosen to disable one of EnduraBot's commands, were that to ever occur.

What it says on the tin. I'd like the bot to be able to output why a systems operators has chosen to disable one of EnduraBot's commands, were that to ever occur.
sirdog3355 commented 2026-02-05 01:01:40 -05:00 (Migrated from github.com)

Unnecessary.

Unnecessary.
sirdog3355 commented 2026-02-05 16:35:58 -05:00 (Migrated from github.com)

Well, given #229 and the necessity of disabling a command, I would actually really like this now. Shouldn't be hard anyway, just a key:value JSON pair.

Well, given #229 and the necessity of disabling a command, I would actually really like this now. Shouldn't be hard anyway, just a key:value JSON pair.
sirdog3355 commented 2026-02-05 19:15:45 -05:00 (Migrated from github.com)

Addressed by #230. Documentation update unnecessary given the example file. Closing.

Addressed by #230. Documentation update unnecessary given the example file. Closing.
sirdog3355 commented 2026-02-06 07:05:35 -05:00 (Migrated from github.com)

Reopening. PR #230 introduces a bug wherein the new loop in main.py, if it detects that the first key:value pair does not match, simply jumps to the Access denied codeblock. Need to re-write and test more vigorously than I did.

Reopening. PR #230 introduces a bug wherein the new loop in `main.py`, if it detects that the first key:value pair does not match, simply jumps to the `Access denied` codeblock. Need to re-write and test more vigorously than I did.
sirdog3355 commented 2026-02-07 20:18:19 -05:00 (Migrated from github.com)

New issue addressed in #233. Closing again.

New issue addressed in #233. Closing again.
Sign in to join this conversation.
No description provided.