I've been trying to finish this patch for the ArtistCreditEditor. basically what I've determined is that it'd be easier if it used the actual field data it its state, but we need a nicer way to attach additional state to a field
2025-10-29 30214, 2025
bitmap[m]
s/it/in/
2025-10-29 30235, 2025
bitmap[m]
since FieldT etc. are exact types and a lot of places don't like if you add additional properties to those, rn I'm adding a field_state property which can store whatever we want
2025-10-29 30236, 2025
reosarevok[m]
Naughty
2025-10-29 30257, 2025
reosarevok[m]
How are you going to make it play well with Flow?
2025-10-29 30247, 2025
bitmap[m]
it'll actually be a type parameter than you can optionally pass to FieldT/CompoundFieldT/RepeatableFieldT (but it defaults to null)
2025-10-29 30231, 2025
bitmap[m]
this does make some of the code more annoying though since e.g. state.names is now state.field.names.field
2025-10-29 30237, 2025
reosarevok[m]
heh
2025-10-29 30255, 2025
reosarevok[m]
Well we already have stuff that has field.field so
2025-10-29 30208, 2025
reosarevok[m]
I guess we'll live, if it's properly and clearly documented (wink, nudge)
2025-10-29 30221, 2025
bitmap[m]
I'll try!
2025-10-29 30225, 2025
reosarevok[m]
I've been working on converting more stuff to React
2025-10-29 30204, 2025
reosarevok[m]
Worked a bit on disc ID stuff, some of it ready, some of it in progress while I fight the kinda messy cdtoc/lookup page
2025-10-29 30216, 2025
reosarevok[m]
Nothing probably super complicated, just kinda annoying
2025-10-29 30205, 2025
reosarevok[m]
Although we have three similar, but not equivalent CDTocPossibleMediumRow, CDTocMediumListRow and CDTocReleaseListRow components now, which prooobably should be mashed together in some way or another
2025-10-29 30251, 2025
bitmap[m]
do they have any meaningful differences?
2025-10-29 30223, 2025
bitmap[m]
sounds like a good idea to combine them if not
2025-10-29 30243, 2025
reosarevok[m]
Well, they have extra columns sometimes, in different orders sometimes
2025-10-29 30207, 2025
reosarevok[m]
They're all the same general "table with info about a medium and its toggleable tracklist" but with changing contexts
2025-10-29 30235, 2025
reosarevok[m]
For now I'm converting as-is, but we can look at whether we can improve it in a subsequent commit or something
I suspect a bunch of work there is probably duplicating my recording PR, and we'll need to put them together a bit, but that's neat
2025-10-29 30253, 2025
reosarevok[m]
Thanks serial_ata! :)
2025-10-29 30256, 2025
anuj_ has quit
2025-10-29 30239, 2025
bitmap[m]
nice work serial_ata!
2025-10-29 30229, 2025
bitmap[m]
reosarevok: do you think it would make sense to change admin/RemoveEmptyAccounts.pl to allow removing accounts with a verified email? (I think we should also verify that the user name/ID isn't referenced at all in other projects' tables, but assuming we do that)
2025-10-29 30204, 2025
reosarevok[m]
Is this connected with the MeB users migration?
2025-10-29 30213, 2025
reosarevok[m]
Because I would expect this to happen on that level from now on?
2025-10-29 30238, 2025
bitmap[m]
it's only connected in that it would probably remove 99% of historical spam accounts and reduce the number of users that need to be migrated
2025-10-29 30221, 2025
reosarevok[m]
That sounds like a one-off script then
2025-10-29 30235, 2025
reosarevok[m]
But I guess it could work either way
2025-10-29 30249, 2025
reosarevok[m]
But this is more of a mayhem question
2025-10-29 30206, 2025
reosarevok[m]
Since removing verified accounts (even if empty) is less trivial
2025-10-29 30222, 2025
reosarevok[m]
I think it makes sense, mind, but maybe with some extra restrictions (of how old they are or whatnot)
2025-10-29 30256, 2025
mayhem[m]
I think an account that has a verified email, no edits and hasn't been logged into in 5 years is fit for deletion.
2025-10-29 30202, 2025
mayhem[m]
perhaps send a warning email?
2025-10-29 30246, 2025
bitmap[m]
sure, we could try that
2025-10-29 30211, 2025
wargreen_ joined the channel
2025-10-29 30252, 2025
bitmap[m]
with the `last_login_date < now() - interval '5 years'` restriction, that's 612,680 accounts (majority are spam)
2025-10-29 30211, 2025
reosarevok[m]
Seems sensible enough to me
2025-10-29 30243, 2025
reosarevok[m]
Mass-spam everyone of those with "we're planning to remove your account for inactivity unless you log in within a month"
2025-10-29 30255, 2025
bitmap[m]
some of them may now be empty because they only submitted PUID edits in the past, but they are unused now at least
2025-10-29 30215, 2025
reosarevok[m]
Think we can live without some editors who last submitted PUIDs
bitmap: if you're going to keep getting adventurous with the recording form, we can also look into this new area one first, see if there's some improvements from the recording form PR we can already use here too as well
2025-10-29 30213, 2025
reosarevok[m]
(but if you think it'll be ready soonish that's fine too - I'm off next week so you can take some time playing with it and I'll recheck after that)
2025-10-29 30238, 2025
bitmap[m]
it should be ready soon and I don't plan anything else besides the AC validation, but I'll def. look at the area one soon too
2025-10-29 30241, 2025
reosarevok[m]
yvanzo should replace me as your partner for next meeting :)
2025-10-29 30225, 2025
reosarevok[m]
Ok, if it's ready to test further before Monday, I should be around (Monday is a home day and I can work a bit if we want to check stuff and potentially put it on beta)
2025-10-29 30249, 2025
reosarevok[m]
Tuesday to Sunday I'm away from home
2025-10-29 30254, 2025
bitmap[m]
it should be ready today or tomorrow (Friday I might only be around in the morning)
2025-10-29 30221, 2025
reosarevok[m]
That's what I thought about the recording form for a month now!
