Since all changes are going to be submitted to the upstream prior to landing here in Phorge it would be easiest if changes were made to a clone of Phabricator and not a clone of Phorge.

epriestley was very much against this idea but wikimedia's users loved it.

Thanks for your comments! Namespacing might be useful, we would have to figure out what that looked like. I was thinking "/book/group/link" as that would be pretty natural (and is very close to what Diviner does already: "/book/group/filename"). It would also allow for us to eventually make Diviner widely useful, see secure: T4558. However, that is a broader discussion that should probably wait...

A few thoughts. This sounds like a great idea as searching by article title seems a little fragile as you mention. I think a good practice for using the proposed @link would be to fully namespace it somehow like @link development.processes.i18n, though I'm not totally sure what that looks like as I'm not familiar with the Diviner format or structure. If we have the use of namespaces then managing multiple @link declarations might lead to confusion or tedious to maintain. To me this also feels more similar to something like an @id rather than @link. What are your thoughts?

A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.

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.

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.

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...

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.

lgtm.

The upstream discussion is at https://secure.phabricator.com/T8787

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/

Interestingly accessing /status on secure.phabricator.com seems to return a json object instead of ALIVE.

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.

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?