NOTICE: MBS-14196 (https://tickets.metabrainz.org/browse/MBS-14196): Rename label "founded" to label "started"
2025-12-10 34428, 2025
petitminion joined the channel
2025-12-10 34432, 2025
petitminion has quit
2025-12-10 34415, 2025
_BrainzGit
[musicbrainz-server] 14reosarevok opened pull request #3690 (03master…MBS-13898): MBS-13898: Show existing primary alias in alias edit form and alias edits https://github.com/metabrainz/musicbrainz-server/…
NOTICE: SEARCH-750 (https://tickets.metabrainz.org/browse/SEARCH-750): Tags and genres are generating bad search results
2025-12-10 34455, 2025
vardhan joined the channel
2025-12-10 34413, 2025
vardhan has quit
2025-12-10 34421, 2025
SigHunter has quit
2025-12-10 34419, 2025
SigHunter joined the channel
2025-12-10 34428, 2025
bitmap[m]
reosarevok: yvanzo: hi
2025-12-10 34434, 2025
reosarevok[m]
Hi!
2025-12-10 34440, 2025
yvanzo[m] joined the channel
2025-12-10 34440, 2025
yvanzo[m]
Hi!
2025-12-10 34422, 2025
bitmap[m]
I'll start with an update on the metabrainz-accounts branch I'm working on
2025-12-10 34427, 2025
bitmap[m]
to continue allowing local account use in development, I decided it would be easiest to preserve the existing registration / login forms, but require LOCAL_ACCOUNTS_ENABLED and DB_STAGING_TESTING_FEATURES flags to be enabled to use them
2025-12-10 34406, 2025
bitmap[m]
new account passwords would be hard-coded to 'mb' and I would remove features not essential to development, e.g. the verify-email, lost-username, lost-password, change-password, reset-password endpoints
2025-12-10 34434, 2025
bitmap[m]
I also planned to remove unnecessary strings and strip i18n from them
2025-12-10 34443, 2025
bitmap[m]
does that make sense?
2025-12-10 34441, 2025
reosarevok[m]
Seems sensible enough in principle to me
2025-12-10 34445, 2025
yvanzo[m]
Why two tags?
2025-12-10 34422, 2025
reosarevok[m]
I guess the features you're removing would not be developed further since they'd now live in MeB for all non-dev-testing accounts, so dropping them seems fine if not needed
2025-12-10 34437, 2025
reosarevok[m]
I guess in theory keeping just DB_STAGING_TESTING_FEATURES would make sense if we are removing all the other stuff and do not want to support local accounts at all otherwise (for forks or whatnot)
2025-12-10 34446, 2025
bitmap[m]
yvanzo: it might only require `LOCAL_ACCOUNTS_ENABLED` actually, I was using `DB_STAGING_TESTING_FEATURES` for something else
2025-12-10 34425, 2025
reosarevok[m]
But having a separate LOCAL_ACCOUNTS_ENABLED option I guess makes sense if we might want to test some things which do require MeB accounts?
2025-12-10 34441, 2025
bitmap[m]
but it would make sense to allow enabling testing features while still using oauth, e.g. on test.mb
the issue we discussed previous regarding the MB session cookie expiring was resolved by adding a dialog that opens the MeB login page in an iframe and refreshes the session cookie. it's only needed in pages that submit edits using JavaScript
2025-12-10 34431, 2025
bitmap[m]
as soon as you hit the submit button in the relationship editor, if it returns a specific error code indicating you're logged out, the dialog pops up and logs you in immediately, then auto-closes and continues the edit submission
2025-12-10 34436, 2025
reosarevok[m]
How does it work for the user?
2025-12-10 34448, 2025
reosarevok[m]
Like, does it show "logging you back in" or something?
2025-12-10 34404, 2025
bitmap[m]
if you have "remember me" enabled on MeB, it all happens pretty fast, the dialog just flashes open and then closes. it can look kinda janky so can be improved in that regard
2025-12-10 34451, 2025
bitmap[m]
if you didn't have an active session on MeB, it stays open on the MeB login form and closes once you finish that
2025-12-10 34420, 2025
reosarevok[m]
Oh, ok, so it's either automatic, or you can still log in and not lose the submission but you have to do the logging in
2025-12-10 34431, 2025
bitmap[m]
correct
2025-12-10 34406, 2025
reosarevok[m]
If it's not super common, it might even make sense to let the user know we logged them back in automatically and having them say ok rather than flashing a dialog... but that'd get annoying if it happens often so I dunno
2025-12-10 34420, 2025
reosarevok[m]
Anyway, as long as it works, it can be improved later with aerozol I'm sure
2025-12-10 34402, 2025
bitmap[m]
but again this is only needed on pages that submit edits with javascript, for other edit forms that POST to FormHandler, the form state is preserved in the Catalyst session and we go through the whole OAuth redirect chain
2025-12-10 34446, 2025
yvanzo[m]
We are going to do more JS editing though.
2025-12-10 34453, 2025
bitmap[m]
reosarevok[m]: I'll experiment with this at least
2025-12-10 34410, 2025
yvanzo[m]
As edit preview does use JS IIRC?
2025-12-10 34401, 2025
bitmap[m]
yvanzo: most likely yeah, so it's worth polishing the UI here
2025-12-10 34405, 2025
mayhem[m]
sorry for the lame questions, but I'm finally feeling a bit better and coming back around to doing dev work. where do I setup the OAuth keys for a new app that uses the /new-oauth2 base URL?
2025-12-10 34422, 2025
bitmap[m]
mayhem: IIRC /new-oauth2/client/create and /new-oauth2/client/list are the endpoints to manage those
2025-12-10 34406, 2025
mayhem[m]
ahh, thanks!
2025-12-10 34419, 2025
yvanzo[m]
<bitmap[m]> "if you didn't have an active..." <- Is there a time limit to submit this form?
2025-12-10 34457, 2025
bitmap[m]
I'm pretty sure the MeB login form uses CSRF tokens which may expire, though in that case it should just reload and allow you to submit it again as normal (?), but I haven't tested this scenario
2025-12-10 34445, 2025
bitmap[m]
there's no time limit on the musicbrainz side
2025-12-10 34401, 2025
reosarevok[m]
So basically do I understand correctly that the whole thing is basically ready even though it might benefit from some improvements?
2025-12-10 34431, 2025
reosarevok[m]
I know we were hoping to have oauth out early Dec, not sure if MB is the only one lagging a bit behind?
2025-12-10 34445, 2025
bitmap[m]
there were some account things on the metabrainz side that remain unimplemented, e.g. the user.deleted and user.updated webhooks
2025-12-10 34416, 2025
mayhem[m]
reosarevok[m]: I think we should have a chat with lucifer about this soon, I'd like to get caught up on this as well.
2025-12-10 34423, 2025
bitmap[m]
I believe Discourse SSO needs to be implemented too
2025-12-10 34447, 2025
reosarevok[m]
With Christmas coming soon, I expect a realistic deadline now then would be mid-January at best
2025-12-10 34454, 2025
reosarevok[m]
But having a meeting to check would make sense
2025-12-10 34408, 2025
bitmap[m]
yes, a meeting would be helpful
2025-12-10 34436, 2025
lucifer[m]
bitmap: is the MB-side of things ready for login?
2025-12-10 34438, 2025
bitmap[m]
lucifer: login is working for me locally, should definitely be tested more, but yes
2025-12-10 34410, 2025
lucifer[m]
ah cool, yes once its ready. we can do a meet to discuss deployment.
2025-12-10 34452, 2025
mayhem[m]
do we have the most needed people here for such a quick meeting to happen now?
2025-12-10 34409, 2025
bitmap[m]
lucifer: I think the webhooks branch was deleted btw, which branch should I be using?
NOTICE: MBS-14178 (https://tickets.metabrainz.org/browse/MBS-14178): Indicate the edited release on recording and RG edits entered from the release editor
2025-12-10 34453, 2025
reosarevok[m]
Other than that, not much to say :)
2025-12-10 34420, 2025
reosarevok[m]
yvanzo: what about you, how is stuff looking?
2025-12-10 34422, 2025
bitmap[m]
lucifer: IIRC there a google doc outlining the deployment plan though I can't find it, do you have a link handy?
2025-12-10 34430, 2025
yvanzo[m]
reosarevok: I don’t have anything to add about label search, thanks for looking into it.
2025-12-10 34447, 2025
v6lur joined the channel
2025-12-10 34430, 2025
reosarevok[m]
Oh, about that, if you don't have any particular suggestions I'll just try and play with it when I find some time (I still need to retest a bunch of search stuff I have up, but I've been mostly focusing on React stuff recently)
2025-12-10 34426, 2025
lucifer[m]
bitmap: i don't have a document at the moment actually.
2025-12-10 34451, 2025
bitmap[m]
ok, no problem
2025-12-10 34401, 2025
lucifer[m]
but the broad idea is decide a time to disabled login/registration on MB/MeB. run a script to migrate users from MB db to MeB db. deploy new code.
2025-12-10 34403, 2025
mayhem[m]
sounds like something for the todo list. :)
2025-12-10 34435, 2025
lucifer[m]
yes, i'll prepare a more detailed doc.
2025-12-10 34439, 2025
mayhem[m]
what is left to do before we disable MB logins?
2025-12-10 34423, 2025
bitmap[m]
reosarevok: yvanzo: I have nothing else for the MB meeting, thanks for your time
2025-12-10 34430, 2025
reosarevok[m]
Thank you!
2025-12-10 34432, 2025
lucifer[m]
I am satisfied with the changes on MeB, CB, LB side.
2025-12-10 34452, 2025
lucifer[m]
I can make the necessary changes for the BB side in a day or two as well.
2025-12-10 34419, 2025
yvanzo[m]
reosarevok: There is a debug mode in Solr to be used for this purpose.
2025-12-10 34440, 2025
bitmap[m]
in the (outdated) webhooks branch I was working with, the user.deleted and user.updated webhooks aren't implemented, any progress there?
2025-12-10 34456, 2025
lucifer[m]
bitmap, do your changes for MB server include updating the existing MB OAuth provider from MeB DB/API?
2025-12-10 34440, 2025
lucifer[m]
bitmap[m]: that is additional functionality that doesn't exist curerntly so my intention is to add it after the initial deployment.
2025-12-10 34443, 2025
bitmap[m]
lucifer: right now it just handles meb_ tokens as before, I haven't made any other API changes
2025-12-10 34446, 2025
yvanzo[m]
bitmap[m]: Thanks!
2025-12-10 34402, 2025
lucifer[m]
bitmap[m]: i see, i wonder if we need it for Picard.
2025-12-10 34422, 2025
lucifer[m]
i guess if MB handles the user.created webhook then it should be fine without extra changes?
2025-12-10 34441, 2025
bitmap[m]
the user.updated one is needed to inform MB about email changes though, isn't it?
2025-12-10 34452, 2025
mayhem[m]
lucifer[m]: zas: ^^
2025-12-10 34458, 2025
lucifer[m]
that is a separate event. user.verified iirc.
2025-12-10 34438, 2025
lucifer[m]
which is implemented.
2025-12-10 34440, 2025
bitmap[m]
ok, yes I've implemented that one. I guess it would be helpful to clarify which properties user.updated will send so I can verify if MB needs them
