For reviewing a recording from LB using the cb review modal, instead of greying out the option if the user has not connected cb, we can direct the users to the connections page.
Moreover, we should add some relevance of the features available on the homepage. This is something which could be general because currently the users will not have a clue of how to use/where to look for such features.
We even need to update the docs for lb and add the configuration changes for config.py and mention about adding cb.
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda (meetings on summer break; next one: 2021-09-06): Reviews, MBS-11938 (reo), MBS-6479 (reo), MeB Summit (lucifer)
Use case: I was actually trying to review my listens from LB and was unable to find any of my listens reviewable or available on MB. Maybe I'm too modern but can't we add the data we fetch from Spotify to our database?
ruaok
akshaaatt[m]: normally the MB crowd dislikes anything that adds data to MB>
akshaaatt[m]
Right
ruaok
akshaaatt[m]: the right way to do this is to use the "data not in MB" data that we already have in the LB db.
and display that to our users, and then have an HTTP post form fill out the submission pages to MB
akshaaatt[m]
Right. Sounds good
reosarevok
The rightest way is to add the MB album before you even listen to it ;p
the reviewable listens situation will improve once we have the mapped mbids being sent along with listen data to frontend.
akshaaatt[m]
Makes sense. I'll look into it further
lucifer
reosarevok: sir's url import fails for me, even when using the current master! 😞
reosarevok
Huh, wtf
MrClon
Begin submiting tags from Bandcamp. Got 2 502 (One of our servers appears to be misbehaving. Please try again later.) per 200 requests. It's performance issue? I can slow down submission. Now i do sleep92) between requests
* sleep(2)
yvanzo
MrClon: Please self-limit the speed of your bot for its first edits at least so they can be possibly checked by voters.
When reosarevok mentioned the limit of 1000 edits per day, it is actually his bot who self-limits to that.
reosarevok
yvanzo: it's not edits, it's tags, we don't technically have a limit for that
That said, it seems sensible to self-limit, yes :)
yvanzo
Also, please link to bot’s source code to its profile.
Shouldn't setting something to stash in one page and trying to access in the next work? I'm guessing actually not, since it doesn't seem to work, heh :D
Do you remember what would be a working alternative?
Toasty joined the channel
I'm trying to avoid a chain of three different steps, each of which posts to the next, if possible, because it feels a bit weird and I'm not sure how that'd work with the csrf stuff
yvanzo: also, have you seen url import fail in sir? See lucifer's comment above
MrClon
yvanzo: Voters check for tags voting?
yvanzo
MrClon: as reosarevok said, I thought that was about edits, but it's about tags, still it would give time for manual checking.
reosarevok
At least the first day or so, some people might want to check from the forum :)
yvanzo
reosarevok: you might want to use query parameters instead?
lucifer: what is the logged error message for sir's import failure?
About code: it's really simply but pretty ugly code that use 3 local databases (json files) maintaining by bunch of other scripts. Make all this mess publishable — big work
ruaok
monkey: alastairp: any plans for coming to the office on a weekly basis? I'd love to get back to that.
alastairp
hi ruaok. yes, absolutely
maybe from next week. Wednesdays or Thursdays. Got to work out how to fit it into back-to-office at MTG too
ruaok
monkey just waltzed into the office too.
alastairp
hi monkey
monkey
Hi !
I think Wednesday sounds pretty good
Err, or maybe Thursday
alastairp
let's play it by ear again. given I have to be in 2 offices a week, I have a feeling that Thursdays might be better for MeB, but I'll give it a few weeks to find a rhythm
ruaok
wed or thu works for me.
monkey
Let's do Thursdays then. I more often have engagements on Wednesdays for some reason.
alastairp
ok!
ruaok
ok
monkey
ok
ook oook !
(that's speciest)
Toasty has quit
ruaok
gah. it took one day to catch up all the BS from the last two weeks. real work done: 0
reosarevok
ruaok: if you did manage to catch up already in one day, I'd call that a win...
ruaok: i guess my day hasn't been the most unproductive after all then. setting up a debugger to work inside docker is still a mess 😢
reosarevok: will take a look.
bitmap
reosarevok: I only tested the triggers and ExportAllTables changes so far. but we could install them on test.mb next and setup a slave server that replicates from that
reosarevok
But this is only a draft in that it needs testing then?
bitmap
right
reosarevok
Also, will the replication packages be a lot bigger if we store old values?
I seem to remember large packages were sometimes problematic historically
bitmap
iirc mbslave imports packets into memory instead of PG tables first -- we should probably check that. it wouldn't be a problem with our replication scripts but they are larger, yes
not so much after being compressed (or we can make them smaller than the current ones if we switch to .xz)
reosarevok
Well, sounds promising so far, but we should check that, yeah
Where I do $c->response->redirect($c->uri_for('/admin/delete-users-confirm')); can I pass the POST stuff there? As far as I understand, we can pass arguments to uri_for_action, but do those get passed as GET or how?
Yeah, I'm mostly in agreement, but not sure what's the best alternative :)
bitmap
so I guess there should be another POST field like `confirm=1` or something and it renders the confirmation page if that's not set
& you can keep the previous POST parameters in the page with root/static/scripts/common/components/PostParameters.js
reosarevok
Oh, so do it all under one single method?
bitmap
I think so
reosarevok
And first thing check if "confirm" is set, if not it loads the Admin::DeleteUsers form but if it is it loads the SecureConfirm one?
Feels a bit weird to have a method that's a 2-in-1, but maybe :)
bitmap
well I was thinking confirm=1 (confirmed?) would make it actually submit the deletion
reosarevok
Oh, ok
So, right now this is meant to have: Freso enters the (newline-separated) usernames, then clicks Next
Then the usernames are loaded as editors (if valid), a list with all the data is shown, then with all that data, Freso can confirm and delete if it looks correct
bitmap
the second page is the confirmation page? or there is another one after that?
reosarevok
Second page is the confirmation page
So, two forms, one to send all the editor names, one to confirm once they're shown with the data
Is the idea at the moment, anyway :)
prabaaaaal has quit
bitmap
makes sense. on the formhandler side it probably has to be a single form, but