Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help channel message count features #285

Open
ceSchueler opened this issue Apr 19, 2024 · 5 comments
Open

Help channel message count features #285

ceSchueler opened this issue Apr 19, 2024 · 5 comments
Labels
feature Feature to be worked on

Comments

@ceSchueler
Copy link
Collaborator

ceSchueler commented Apr 19, 2024

This ( #164 #167 ) should

  • exclude messages sent in channels in the "Special Help" category (360689175944626176).
  • include a command for staff to check a user's message count in help channels.
    • total count in help channels
    • rolling total of the last two months
    • rolling total of the last three months

Perhaps related to this: staff-only command to make queries to the DB?
Of course only if it can be made zero-trust, i.e. that you can't execute DROP TABLE or make injections.
Idk if there would be any sensitive queries content-wise that Moderators (Guides definitely) could do...

@ceSchueler ceSchueler added the feature Feature to be worked on label Apr 19, 2024
@sebastiaan-daniels
Copy link
Collaborator

sebastiaan-daniels commented Apr 25, 2024

exclude messages sent in channels in the "Special Help" category (360689175944626176).

Ok.

include a command for staff to check a user's message count in help channels.

I'll try to create a command for that soon:tm:

staff-only command to make queries to the DB?

Absolutely not. No No No....
Best case scenario you can try to create some CRUD pages for certain fields but otherwise no

@ceSchueler
Copy link
Collaborator Author

Absolutely not. No No No....
Best case scenario you can try to create some CRUD pages for certain fields but otherwise no
How about some _ R _ _ pages (so only Read) for all fields?

Actually, I don't know all the fields we have in the DB, is that documented somewhere, or would I need to check the code?

@sebastiaan-daniels
Copy link
Collaborator

Actually, I don't know all the fields we have in the DB, is that documented somewhere, or would I need to check the code?

Yes, it is quite easy, Download this program and open the file in database/ERD.mdj

How about some _ R _ _ pages (so only Read) for all fields?

There are 5 database tables, 3 of those are directly related to staff applications. These are already part of a fully working CRUD.
The other two is the user table and alerts table.

For the user table, as you've suggested the only thing kept there is the message count. There will be a command to read those soon. We could do something similar for the alerts.

If we'd do that we would have pretty much the entire db covered.

@ceSchueler
Copy link
Collaborator Author

ceSchueler commented Apr 26, 2024

Yes, it is quite easy, Download this program and open the file in database/ERD.mdj

Ooh this looks great, thanks!

For the user table, as you've suggested the only thing kept there is the message count. There will be a command to read those soon. We could do something similar for the alerts.

And cooldown, but I guess that would only be relevant if a user complaints that they can't submit an application and then only to see if cooldown >0.

If we'd do that we would have pretty much the entire db covered.

Yeah, that would be great!

@ceSchueler
Copy link
Collaborator Author

Edited issue to reflect some additional feature requests for the staff command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature to be worked on
Projects
None yet
Development

No branches or pull requests

2 participants