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.

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

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

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.

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

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.

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?

Based on the entries so far it seems like possible window of time for meeting would be 4pm-8pm GMT? That would mean 9am-1pm for GMT-6 and 6pm-10pm for GMT+2. If that time window seems reasonable would any day of the week be better than others?

Should this be the responsibility of the linter/tester and not part of Arcanist itself? Updating arcanist to handle the many different environment-dependent systems for languages would mean accounting for nearly every language like Javascript/npm, Ruby/rubyenv, etc. right?

That would be useful, though we might not want all disabled accounts to have their profiles description hidden for accounts disabled which aren't spam.

Thanks for reporting, I've disabled the account.

Evan just posted some comments regarding 8.1 compatibility (as well as building PHP binary to ship with Arcanist, for Mac systems at least)
https://secure.phabricator.com/T13588#256390

I just checked the emails I receive to my gmail account and noticed that the emails seem to be from the secure.phorge.dev domain. Should those be received from we.phorge.it instead? I was in the process of filling out an issue form for Microsoft and noticed this discrepancy. Could that cause issues like this?

I noticed this recently too. These PHP 8 updates have been frustrating because it breaks Arcanist for users as well...

Time tracking is an interesting topic. At my company we addressed this by having a Herald WebHook hit our internal server whenever activity we're interested in tracking happens. Our internal server tracks these activities from multiple sources (not just Phab/Phorge) and users can go in to see all their activity linked up and input the approximate time spent on those activities.

A few months back this story came up on hackernews which seems relevant. There might be things in there we can attempt to appeal to Microsoft to allow emails from this Phorge instance to go through

What mobile display are you using? From the screenshots it looks like based on the dimensions of the display phorge isn't detecting that it should render as mobile view.

I think updating the current pem file is a good holdover patch for now (sorry for the delay in reviewing the change). Re-working how arcanist manages certs is something we can look at addressing long-term.

I computed the sha256 sum of the change/updated file and verified that it matches the cert file on https://curl.se/docs/caextract.html for 2021-09-30.

Thank you for going through to make these all consistent!

Thanks for setting this up. I would like to be a group contact for the room.

Thank you for submitting this change!

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

Since it matches the other user select that’s setup in this file this is fine but it could just be the standard + WebKit one

The effort to rebrand Phabricator is going to result in changes to a lot of text which would likely invalidate a large number of translation entries.

At my company we have a similar situation however our management system is something we also actively develop. We solved this problem by configuring a web hook to hit an endpoint for the activities we are interested in having people track. The endpoint receives the transactions, pulls some additional info, and creates time-tracked activities for them in an aggregated list. Employees review the list and update time for each activity. It works pretty well and is not limited to activities from Phab allowing other systems to post activity to report, and for employees it’s nice because we can present the activity they’ve done and only require they estimate time spent as all other context is linked up.

Thanks!

Because of security issues related to this I’d like to have a verification of this type of change since this inherently defines the trust used by arc.

I think that makes sense. Could you make a task to address this so we don’t lose track of it? Then let’s get this landed.

Ah interesting. Could we follow the information you found and just include the WebKit one for now. I’m not as concerned with consistency after your findings. I appreciate that you investigated!

It seems like only the WebKit variant may still be necessary. What do you think about updating both areas to just have the WebKit version in addition to the standard?

Let’s update to include the same set of user-select cross-browser as the blame info

I tried on Firefox on mac and there are tabs included

I mentioned on the diff but also mentioning here. Blog posts can be directed to users external of the system where monograms might be more confusing. Maybe we can find another place on the page to put the monogram that doesn't affect the title?

Marking as request changes during discussion

Thinking about this a little more it could be intentional for these to not have monograms displayed in the page title. Tasks, Revisions, etc. are more meant to be directed to internal users of the system while Phame blog posts may also be directed to external users where a monogram might be more confusing. What do you think?

lgtm - I compared to a few other views just to confirm this is the same approach for adding monogram to the title. Thanks!

Is it possible to pick a branching off point?

Yep I think this makes sense and is why I think our first release should still support PHP 5.4 but we can move off it after that.

Expressing the desired behavior here seems difficult to fit into Herald.

• Level: Global
• Trigger: When a task's status is changed
• Action: Move the task to a different column X on project Y

In D25015#735, @avivey wrote:

I may be late for the party, but can't the translated verbiage be provided to the dialog in the $form_attributes in AphrontDialogView.php:337, and read using form.getAttribute(key) in the js?

I looked at the $form_attributes a week or so back but I think those end up being transformed into the literal HTML attributes of the dialog's <form> element. I think we need to add a new field to the dialog, something like setMetadata() that @dcog found in the workboard view.

We should include the Diviner and tech docs generation as part of the upgrade process of this server, that should ensure it's always up to date.

@MikeCripps welcome aboard! I added you to trusted contributors group.

I think our general strategy here should be focused around the versions of PHP available from the default/common package repositories for major server-based Linux distributions. There might be some situations where those package repositories only support very old versions (e.g. CentOS 7) which we should only plan to provide documentation for how to get the required version of PHP installed.

Thanks for submitting this update!

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

@Leon95 updated/included some translated text for calendar widgets under D25016 which may also be useful as reference. However one big difference is that the calendar widget has its own explicit view/behavior, whereas front-end workflows have multiple varying uses with different content.

Thank you! This looks good and the translation stuff you used here answers some questions for me about how to get translated text into the front-end, something that has come up in D25015. I'll try to get this landed shortly.

Came across someone else's notes about submit/merge queues - https://epage.github.io/dev/submit-queue/

In T15043#1244, @TitanNano wrote:

I started to implement this as a new herald action. There is just one major problem. I would have to load all columns from every project and present them to the user. A user could then select one specific column of one specific project for his herald action... This seems kind of pointless to me. It's way too specific to be usable.

I think we first need some way to target project columns in a more generic way. If columns had a type, like "backlog" or "in_progress", then we could say, move this task on every related workboard into a column of type "in_progress".

This is something we probably want to wait for the rebrand to occur as it could be considered "releasing". Granted these repos are already public so it wouldn't be too different than what we have now.

Thanks for looking into this. I ended up submitting the initial simple change to fix fwrite vs. fprintf to upstream and discussing with epriestley he recommended to instead just remove the use of logging. I ended up making a larger change that also corrects the error-handling when running arc liberate. We can probably hold off on changes here and merge in changes from upstream -- https://secure.phabricator.com/D21718

I didn't manage to get #phorge:libera.chat to work, but here's what I did:

Automated Landing should be what adds the "Land Revision" button to revisions -- so not fully automated but allows someone to land without needing a local clone to manage.

Functionally I think this makes sense, though from a higher perspective the concept of "multiple authors on a revision" might need to be discussed and fleshed out.

I agree with @CSharp that option 3 is probably the best approach here. It looks like on https://secure.phabricator.com/T6409 the initial request was that items get automatically moved based on state change and the main pushback is against the design of an approach like 1 or 2. I think setting this up utilizing Herald makes sense though. I wasn't aware that triggers/transactions weren't fired from both locations though. That might be a bit involved.

I'll try to look into feasibility of this later this week. Presumably it shouldn't be too difficult, adding a few configs to point to the certificate files and updating the DAO (I think is named Lisk?).

@TitanNano with the matrix bridge up could you provide instructions on how to connect to that? I setup the Element client on my machine but I'm not sure how to get on that phorge channel.

Thanks for submitting these changes!

Thanks for submitting this!

It looks like there is a JX.phtize() which appears to be used to create a function that mimics pht() in JavaScript but I believe requires that whatever is passed to phtize() is effectively a map of translations which is presumably passed from the server somewhere. I've not yet uncovered this later part.

I think these changes look good. Prior to landing this should pass unit test runs. I created T15042 as a means to make landing changes easier and it should also involve setting up a staging area which then runs both lints and unit tests.

Thank you for the submission @roguelazer!