If you are interested in submitting a fix, you should probably follow https://www.mediawiki.org/wiki/Gerrit/Tutorial and produce a patch to mediawki-core I guess. A good first step would be to reproduce the same in your latest development environment.
Sun, Oct 20
Sep 1 2019
arturo> tonythomas: I can give you some more concrete information if you are interested 16:27 <tonythomas> arturo: please yes! 16:29 <arturo> tonythomas: first, I would point you towards this: https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/DNS_domain_usage#Resolution i.e, we plan to use `$tool.toolforge.org`. For implementing that, upgrading our kubernetes deployment is probably the first step, and we are working on that in this phabricator task: T215531 16:29 <•stashbot> T215531: Deploy upgraded Kubernetes to toolsbeta - https://phabricator.wikimedia.org/T215531 16:37 <tonythomas> arturo: thank you. I will keep an eye on those tasks! Thanks.
Aug 28 2019
Sounds like this task is blocked on the road by https://phabricator.wikimedia.org/T215531 ? Atleast that is what I hear from #wikimedia-cloud. :-(
Jun 18 2019
Jun 16 2019
Good one @bd808. I missed that the In addition, part was an addition to in-org use case.
Jun 8 2019
May 25 2019
May 24 2019
Thank you! Just waiting for it to roll out!
May 19 2019
May 18 2019
Thanks @zeljkofilipin ! This is green now! a
Let’s do it.
May 17 2019
@zeljkofilipin I was looking at the results of the build, and things of interest are:
Alpine users please run: `sudo apk add python make g++` gyp WARN EACCES user "jenkins-deploy" does not have permission to access the dev dir "/nonexistent/.node-gyp/6.11.0" gyp WARN EACCES attempting to reinstall using temporary dev dir "/tmp/.node-gyp" Traceback (most recent call last): File "/usr/local/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py", line 13, in <module> import gyp File "/usr/local/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/__init__.py", line 8, in <module> import gyp.input File "/usr/local/lib/node_modules/npm/node_modules/node-gyp/gyp/pylib/gyp/input.py", line 5, in <module> from compiler.ast import Const ImportError: No module named compiler.ast gyp ERR! configure error gyp ERR! stack Error: `gyp` failed with exit code: 1
Adding to Wikimedia hackathon board as we have the team here that can get this fixed.
Dec 22 2018
Nov 18 2018
I think this is more or less a file related issue. Like I can see this error showing up while opening up the second file https://drive.google.com/file/d/1RD-M9jhI_Sj980F1uMxS_41YTgETIvm_/view?usp=sharing on google-chrome. See:
Nov 10 2018
Nov 3 2018
Oct 28 2018
I like that button (or something similar) saying View new issue though.
I think should be done at this point. I added some #CONTRIBUTING docs too for the Mozilla program.
Sounds reasonable, but we need some mockups. If someone can push this, we might be able to get this into Google-Code-in-2018.
I was thinking about it for a while, and here are my impressions:
In terms of UI, the field would be optional (now is required) and by default it would show the title of the page to be created, in gray letters. The label would still say "Wiki page with information about the newsletter", no changes there.
All patch-sets related to this task are merged. Safe to close ?
Looks like a good Google-Code-in-2018 task as well. Let me upload this to the GCI site.
All patch sets are merged. This is good to go.
Since we are using ContentHandler and hence extending MW base page objects, caching is not required anymore.
Alright. Lets make it required then. Makes sense to me.
Jul 28 2018
@Niharika can you also point on which wiki this is happening ? Probably it was from a previous version I guess - but cant say without taking a good look. Thanks.
Jul 22 2018
Jul 21 2018
Found a hack btw. Now it works like this:
- When the are subscribers logs public is checked, *everyone* see the whole version of the message.
- When its unchecked, publishers see an anonymised version of the subscription logs (also on Special:Log). This would just say - A subscriber was added/removed on Newsletter:Link
We ran into a problem. Newsletter logs are by default logged in Special:Log. Currently, I can configure the extension to not show up this at Newsletter:NewsletterName, but this wont stop it from showing up at Special:Logs/newsletter. Currently, mediawiki-core do not allow some kind of dynamic plugs on this.
Jul 20 2018
- While creating a newsletter, now you can specify if the subscription logs are public. Probably add something like a checkbox there ? Default to False
- Add a Subscription activity log to Newsletter:Name bottom. This is only available to publishers/admins when above setting is unchecked. Else, available to public.
Jul 19 2018
Notifications are maybe the only thing that worries me a little. Right now on local, it redirects me to the page on my local language.
So I just thought about it - and found that we are not really using the issue id for anything else at this point. This would mean that I can safely implement the feature without affecting migrations, even though I would get the desired:
Initial impression: If we are supporting interwiki links, we need the following changes:
- Store interwiki links somehow in nl_newsletters. Right now we store nl_id. Probably we store the whole title name then ? 🤔 (also, this needs to be done for all newsletters). This might need migration changes as it cannot be empty for existing deployments.
- Modfily newsletter contenthandler to add the whole title as well.
- API edits ? Needs changes on DataUpdate
- Validation changes (fail only if not interwiki link, etc).
Jul 18 2018
smoothFactor in lib/external/mapbox/mapbox-lib.js: 8768 can do what we want.
But announce and notification will be triggered on local wiki, I hope, not on meta?
We just discussed this and it seems like notifying a user on a specific wiki is possible. We have to think:
- Should a user be able to configure, say by Special:Preferences on which wiki to get notified
- Always notify on the $wiki the newsletter is connected to. (we have this information already)
Tentative plan after meeting with @Addshore:
I see that this is the task blocking our deploy strategy.
Jun 4 2018
Well, the idea was that the parent - https://phabricator.wikimedia.org/T194959 - to introduce selenium test to Newsletter extension, and this one to actually test a specific Newsletter use case.
May 19 2018
Thanks @Florian for pitching in.
May 18 2018
Apr 6 2018
Apr 3 2018
Feb 14 2018
Feb 12 2018
Since I couldnt mentor as many tasks as I mentored last year, I dont know where my answer stands - but count me in as well if there is space :P
Feb 1 2018
All patchsets merged, closing now. Thanks.
All patchsets merged, closing now. Thanks.
Jan 31 2018
Jan 13 2018
Jan 3 2018
Nice catch. Thanks!
Dec 31 2017