Fri, Jul 5
@Hanna_Petruschat_WMDE How do you feel about the message: Your change could not be published. You can try clicking the publish button again.
Feel free to change however you see fit :) Can you put the ticket to the bottom of ready for pickup once you are happy with the message? Thanks!
I don't manage to test this before my vacation anymore, my newly created account has too few rights, and my actual one too many :/ Could you please self test this one? Thank you!
Sounds good to me!
@JJMC89 thanks for the feedback! It makes complete sense for me, let's add the info where exactly to find the file to the edit summary! Even though this info might be visible on the file page, especially when considering logs it is much more handy to be able to check everything from the edit summary and not having to switch back and forth between file page and log.
I open the ticket to indicate that there is an open task, but I am (even more) happy if you close it again and create a new ticket for the sugggested change (it's just time that makes me not do it now)
sorry, it slipped my mind :/ Let's go with what you have implemented now, and we can always come back later and change it if we see fit.
Hi @jeblad, could you confirm that both community consensuses voted for rolling out reference previews? Thank you!
Wed, Jul 3
ok done already :)
I can confirm the deletion works! However, I now used up my test file and cannot test that it doesn't always delete. I'll check tomorrow with a new file
Tue, Jul 2
oj interesting! FYI @JStrodt_WMDE
@Jan_Dittrich Do you have an opinion?
I was expecting one box for all the info, in yellow, because it is a revertible error message, thinking this was mediawiki standard behavior. Do you know what the standard behavior is?
Question: Can we give more specifics about why the source wiki couldn't be edited automatically?
If that is not a 5 minute task, but we could theoretically do it, could you please create another ticket for it?
Mon, Jul 1
Take a look here. I think on de.wikivoyage, an example was for example an image of Berlin that linked to the wikivoyage article of Berlin
I don't know how I could test the last criterion, and am taking your implicit word for it.
yes, that is correct!
This looks great now! I just could not test yet, what text appears if the source wiki was automatically informed. So I'm keeping the ticket open as a reminder to check once we have that functionality.
Thu, Jun 27
The font looks good now, but the messaging is a bit confusing, since it is both the variants we described, and not just the one where we know how the template is called:
Tue, Jun 25
can we trust those numbers, though? Aren't percentiles for events that don't trigger at least every minute by default wrong on grafana? That's why I'm super happy with the heat map solution you used for the other cases.
import time and MBs moved look awesome!
What I am still looking for is no of file revisions and no of text revisions :)
@awight, oh I see, yes then demo column is great :)
sounds great! @JStrodt_WMDE any objections?
- it is possible to change the AbuseFilter so that it is not blocking FileIMporter events in all cases
- people with rights of changing rules in the AbuseFilter would be abler to use a special keyword when defining/modifying an AbuseFilter rule, e.g. something like "ExecuteThisOnOldRevisionsWhenImportingWithFileImporter = false"
- if people are not using the keyword, we stick to the current behavior.
I think this is working great. There are just a few things I cannot test, so I would highly appreciate if you could just tell me my assumptions are right :)
On beta commons I see this:
- The target wiki is called "Commons", which is not what I expected (I expected Beta Commons or so). But this is just the way the wiki is set up, and if the target wiki was called differently, we would see another name, right?
- Same goes for "NowCommons", doesn't it? The template name for en beta is just coincidentally the same as the one we have e.g. on en wiki?
The dashboard is looking great now!
I just have one thing:
- The graph contains both recoverable and unrecoverable errors. Let's focus on unrecoverable errors for now (but if it is a 2 minute thing to do, I would be interested in a seperate graph for recoverable errors, too)
Amazing testing prep, thanks! What is not working for me yet is:
- The messaging is not what is described in the acceptance criteria
- The font color is green, which is rather unexpected. or is this a mediawiki standard setting?
Mon, Jun 24
Wed, Jun 19
Tue, Jun 18
Mon, Jun 17
@Wurgl It should have been deployed last week, but if I remember correctly, there was no train last week due to an offsite of the team responsible for the deployments. I will close the ticket now, but I'm happy if you reopen, if you notice anything weird after Thursday!
Hi @Wurgl, the changes have not yet been deployed to the live version yet, they will be visible starting Thursday evening on de-wiki. However, they can already be checked on beta. Do you still experience the issues there?
Jun 14 2019
Report time taken to fail?
I don't think we need that yet. Right now we are interested in step 1: Knowing how often which errors appear.
- the code changes not being trivial and probably in mediawiki core
- there still being some uncertainty how this could exactly be achieved
- the question whether we really want to suppress things, where nobody could ever see what was suppressed for which reasons and from whom
the decision is to stick to current behavior: If the AbuseFilter is blocking a move of any of the revisions, we are not moving the file. (However, the question of whether there is a way to run certain checks only on the newest revision is still under investigation in T225521: Investigate whether the AbuseFilter can specify which revisions to execute a rule on
Jun 13 2019
Jun 12 2019
Dear Readers-Web-Backlog team, I'm just wondering what the status is on the ticket?
Sounds sensible to me! @Hanna_Petruschat_WMDE ?
I checked and there is a few things that I found, but I don't expect any of this to be an acceptance blocker:
- If I log in after having clicked on "Log in" on our overlay, when they redirect me to the page I receive the info that I am logged in, but need to reload:
This info does not go away, even after hard reloads, and our overlay also doesn't disappear. I am assuming that this is a beta wiki issue, and the fact that the overlay still shows up is related to the wiki, although knowing that I am logged in, not being able to deal with that fact. Do you concur?
- Right now, I think the buttons will be in a separate line each for most of the phones. But I will follow up with @Hanna_Petruschat_WMDE and if necessary, this would become a new ticket.