cerca icon indicating copy to clipboard operation
cerca copied to clipboard

Modlogging claimed invites?

Open decentral1se opened this issue 9 months ago • 4 comments

2025-03-29 11:45:03 d1 created a batch of invites

We seem to be missing something following this which registers consuming the invite?

XXXX-XX-XX XX:XX:XX $baz created an account from invite $foo (created by $bar)

(or whatever?)

Opening this up following the report:

_ and I checked the _ applications received and we sent invite urls, all good, but cerca does not keep a log of used invites, only the ones claimed, so we need to figure out how to keep track of who has been invited and what has not.

(hope i captured this request well @320x200)

decentral1se avatar Mar 29 '25 16:03 decentral1se

@decentral1se yup!

Pretty much everything else works so far. Having a trace of used invites would help us share the load amongst us for the invite making task. Without the log it's hard to figure out where the last invite went to. As a workaround we're using a shared document elsewhere but it's not ideal.

320x200 avatar Apr 01 '25 10:04 320x200

I think this is would be a sensible addition! Currently, the only place one can somewhat track a user <-> invite coupling is at /admin by clicking on the invite/register info summary/details element for a particular user. Been a busy weekend and will be a busy week too but would like to tend to y'alls suggestions :)

Image

cblgh avatar Apr 01 '25 14:04 cblgh

@decentral1se @320x200 looking into adding support for this and some other modlogging! what that means in practice is i am currently looking at creating a secondary, more freeform, database table to capture output that isn't necessarily of the format {userid, userid, actionInteger} (current modlog table design); e.g. above we'd need at least also an extra piece of info (invite code)

this relates to #102 and #99. not sure about the schema or naming yet, but here's the scenarios i'm thinking of and the preliminary table layout:

actingUser TEXT NOT NULL
action INTEGER NOT NULL
field1 TEXT
field2 TEXT
reason TEXT 

plus the obvious stuff like incrementing id and date

examples i'm thinking of that this should support:

[actingUser:cblgh] [action:deleted the thread] [field1:xxxyyzz] reason: [reason:blah]
[actingUser:cblgh] [action:renamed the thread] from [field1:xxxyyzz] to [field2:bbb] reason: [reason:blah]
[actingUser:cblgh] [action:deleted the user] [field1:user]
[actingUser:d1] [action: changed username] to [field1:d2]
[actingUser:$baz] [action:created an account from invite] [field2:$foo] (created by [field1:$bar])

for admin actions on thread titles #102, i'm thinking of a [ ] censor original thread title checkbox that will just xxxx out the thread title in case it's offensive and it should not be present in the modlog. i think it's powerful to keep history for admin actions, and even if its censored then it's clearly censored for users and they can decide if its fishy or not :)

cblgh avatar Apr 10 '25 18:04 cblgh

Looks legit to me @cblgh 🎉

decentral1se avatar Apr 18 '25 13:04 decentral1se