As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 29 2022
I put up some coding guidelines that I could recall from when I was working with upstream on example changes. I won't be back at my home office for another week so there may be some things I'm missing but I think a number of things were covered/discussed with Evan on the example changes in https://secure.phabricator.com/D21712.
I am closing this, future meetings are scheduled now. See March 21, 2022 for more information.
Mar 25 2022
In T15080#1970, @speck wrote:Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?
What you're talking about is more like mTLS (mutual TLS), that's not actually how WebAuthn works. (Though supporting mTLS for sign-ins might also be something worth looking into)
- e95157e39bf5 Show matching context from the document body in ferret search results
- This is not perfect but it generally works - display a snippet from the matched document and highlight the matched words - kind standard and expected from any full-text search engine. Probably not my best work as far as code quality / it's a bit hacky and performance may not be stellar, however, it's been in use at wikimedia for quite some time without any major issues that I'm aware of.
- bba62cf52435 Hide the "hidden" fields on custom form previews.
- This is a single line change to css that makes things a lot cleaner when you have a lot of custom forms with a lot of custom fields.
- submitted as D25037
- 9191d4838278 Make "task type" and date-type custom fields work in herald.
- 3d33d1cceac7 Implement Atom/RSS discovery on Phame blog pages
- ebfe30890b52 Add column sequence to the conduit api results for column.search
- This seems like an obvious omission from the conduit api for columns and the change is straightforward.
- submitted as D25038
- 893664bd44b8 EditEngine: 'Duplicate Form' action to create new forms from existing config.
- This makes it much easier to clutter up your custom forms with 100 variations of your forms. It also makes it much easier to make a new form vs. starting from scratch every time. It's sort of a hack and the custom form management UI needs a lot of improvement generally, this was just the minimum change I could implement to make life slightly easier for myself and fellow Wikimedia phab admins. Not sure it's a good idea in the upstream without further changes to go with it.
- 44a94dc04b3f Fix validation of "column" transaction type in "maniphest.edit"
fwiw, this is how I handled it in the wikimedia fork:
Ah interesting. My own preference would be updating PhabricatoPeopleProfileController as I would associate this more as a view-level change but looking again at how this is structured I don't think it would cause any issues and I don't feel too strongly about changing it.
In D25035#1059, @speck wrote:Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).
Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).
In D25035#1051, @speck wrote:I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...
All that should be required to land is being in Blessed Committers I think, which you are a member of
Address code review comments
In T15080#1970, @speck wrote:Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?
I've only looked at the new auth frameworks briefly (WebAuthn, is there another standard too?). My basic understanding is that the browser provides the client with its own certificate which HTTP requests are able to include with it, as a means of providing authentication for the user. This seems like a reasonable thing to allow though I'd also be interested in learning more about the tech in general.
Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?
I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...
Mar 24 2022
Thank you for the review, @avivey !
We should definitely focus on implementing WebAuthn, as that allows us to support almost every standard hardware key solution out there.
The upstream discussion is at https://secure.phabricator.com/T8787
Mar 23 2022
Mar 22 2022
Mar 21 2022
Closing this task now, to prevent it from turning into a perpetual task.
For an account marked as spam we might also want to hide their username from the UI, essentially hiding all possibly user-entered text from appearing on any page so it won't show up in search results.
As discussed in {E1}, we will actually add another action aside from "Disable Account." This action will mark the account as a spammer, which will take the following non-distructive actions:
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.
The choice to not allow administrators to edit profiles is a strange one... at the very least, we should probably upstream Mukunda's patch.
Another one popped up: https://we.phorge.it/p/seo-auckland/
Mar 20 2022
Interestingly accessing /status on secure.phabricator.com seems to return a json object instead of ALIVE.
Mar 19 2022
Mar 17 2022
Mar 16 2022
I had experience with emails from my self-hosted mailserver not reaching Microsoft-hosted mailboxes. As far as I remember, their SMTP replies to "suspicious" mail servers with a message that includes a link to some sort of a form which the mail admin should fill out. That worked for me - might need to dig through the server logs to see the link though.
Might be worth it having the linter classes inherit from a language-specific class that would handle things like environment initialization and dependency installation.
I also created a Jitsi meeting and put that in the description of {E1}.
I turned on prototypes and created {E1}, adding everyone currently (individually) cc'd on this task as an invitee.
Yeah, I think we'd like to try and update arcanist to account for this with a general solution if possible and not making updates for each individual linter which might necessitate this. There's probably some general restructuring that needs to happen to account for the same odd scenario with Java and so forth.
Mar 15 2022
In T15071#1840, @speck wrote:should we enable prototypes on this install to try and use the calendar application for organizing this event?
Checking the source in Arcanist repo, it seems like none of the python linters are actually configured to use an interpreter. (If I attempt to specify one for Pylint anyway, it fails with Got unexpected parameters: interpreter)
I think that's roughly what I ended up doing in https://secure.phabricator.com/D14632 for launching separate Java linters, where java had to be configured as the "interpreter" and checkstyle.jar (or whatever) configured as the "binary" (https://secure.phabricator.com/D15067 added the ability to pass flags to the "interpreter").
Phabricator has a Calendar application but is prototype. I believe it's mostly functional -- should we enable prototypes on this install to try and use the calendar application for organizing this event?
Mar 14 2022
4pm-8pm GMT (6-10pm GMT+2) sounds good to me - I can even go up to ~midnight and looks like I'm the east-most.
Modern(ish) linters support a separate "interpreter" config - if that's set, they run $interpreter $binary $args rather then just $binary $args. Can this be utilized?
@20after4 per commits like https://secure.phabricator.com/D9202 the changes were abandoned - there is no MediaWiki auth provider in core
@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.