fwiw, this is how I handled it in the wikimedia fork:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 25 2022
Mar 21 2022
Yes I agree, this is something I did on wikimedia's instance because we were getting a lot of spam with links in the profile description.
Mar 15 2022
Mar 14 2022
@MacFan4000 the mediawiki auth is in core afaik. There is some custom stuff for the wikimedia ldap setup but the oauth part was merged upstream ages ago.
Yeah admittedly what I did was just a hack because I didn't want to implement storage and UI for a new "hidden" boolean flag.
Mar 13 2022
On Wikipedia’s phabricator instance I implemented a patch that hides the profile text on disabled accounts which helps (slightly) to disincentivize spammers.
Mar 12 2022
Feb 25 2022
Feb 1 2022
Dec 5 2021
Once the rebranding is complete we can send updated strings to translatewiki so that everything remains in sync.
Nov 27 2021
I didn't know columns could be deleted... I thought they were only ever hidden.
Oct 15 2021
Sep 30 2021
In T15048#1311, @Leon95 wrote:^^ Awarding a Token to a "... awarded a token." Message would be a weird case. But what about removing this Message completely? (or add the Option to hide them) It bloats the history of some Objects imensely and is not that usefull in my opinion.
Sep 14 2021
Sep 10 2021
In T15043#1246, @TitanNano wrote:
Indeed.
@TitanNano: One way to store the type, without changing any schema, would be to drop it into the metadata json blob which columns already use for recording which column is the 'default'. Unfortunately that isn't the most convenient thing to query, however, it's not that bad thanks to mysql's json functions.
Sep 9 2021
It wouldn't be too hard to add a type to columns but we'd need a way to set the type from the UI somehow.
Sep 5 2021
I also agree that #3 seems promising. FWIW it's incredibly easy to develop new herald actions and as long as the current herald rules do the thing you want to do then the action would be very straightforward. Maybe the usability would be improved by exposing the rules that affect a board through the workboard UI instead of having them scattered around random and disorganized herald rules in the herald ui?
Aug 22 2021
Ok my implementation had a couple of additional search constraints which are missing here. Otherwise this looks good to me and is more complete. I'll probably abandon my patch and apply this one if you don't mind including the additional search constraints. (See suggested edits.)
FWIW here is my implementation which overlaps somewhat:
Aug 18 2021
Wow, this is something I developed for wikimedia but not nearly as extensive! I'll try to give some code review when I have a few minutes to look this over.
+1 this has bitten me before.
Jul 29 2021
I can help out with upstream merges. I've been doing it on a regular basis for Wikimedia for a long time now. It's rarely been a problem but I'm been careful to make sure that Wikimedia's fork doesn't drift too far away from upstream.
Jul 19 2021
regarding a monorepo, I'm not sure if there is an advantage to that, I'm fine with individual repos. I currently maintain most of Wikimedia's extensions in a single monorepo but I'd consider splitting them out into individual repos if any one them were candidates for upstreaming.
I'd like to host https://github.com/wikimedia/phabricator-antivandalism here, perhaps under a new name.
Jul 14 2021
Jul 12 2021
I landed this upstream.
Jul 3 2021
@willson556: phorge-devcontainer looks awesome. I'll try it out asap. I may be able to contribute as well, I've got a bit of experience building reusable development environments.
Jun 22 2021
In T15004#100, @speck wrote:On the topic of increasing community involvement we will also want to produce documentation for setting up development environments as well as the steps to submit changes upstream (like a quality checklist). To make development environments even easier we might want to consider supporting something like a vagrantfile so people can get started with very few steps.
Jun 20 2021
fwiw the old upstream workflow has been very easy to follow as a downstream fork maintainer so I like keeping it mostly unchanged.
Shouldn't we also think about changing the name of arcanist or does it make sense to have a fork with the same name?