What is the criteria for determining the intentions of various accounts and banning?

What about a snippet from this (1-1.5 sec snippet)? https://yewtu.be/watch?v=JvgF83OHV9c

Did we ever find out more about the hosting situation for phorge.it?

If the users want to use milestones instead of subprojects, can they not change the language settings to Pirate English or something and go from there?

Oh, nice!! Lol, when I saw "Update Diviner links" I thought it was something else, then checked the site and found the broken links and created the Diff

It slipped me to use arc diff to add this revision, I uploaded a patch file out of first instinct

It sounds specific to people who already have access, thank you -- do very much need to pull in latest

Thanks -- Offhand do you know if this is related to login in that a malicious actor can gain access to source code when unpatched?

I would think that your method produced the results we want... though I was noticing this:

I see it looks Harbormaster itself does the testing?

My vote is that if tests pass we go ahead and do the thing.... More changes in upstream seems fine, and moving forward if we keep up it should get easier and easier hopefully

Oh nice!!

This would be a legitimately good exercise to try and do "properly"... although, the thought of not doing it optimally can be a bit of a barrier to starting..

@dtf Pointed out that this thread on secure is highly relevant:

Thinking that based on the first item in (2) Rebrand here: https://we.phorge.it/w/planning_meetings/2022-05-03/#agenda-items-and-notes

Here is one thing I noticed... In at least a couple of the files, there may be changes that:

Referencing a comment from the earlier document:

In D25036#1086, @avivey wrote:

I think we should either just git merge the upstream in, or cherry-pick individual commits - that way we'll still have all the history of each change.

In D25036#1083, @speck wrote:

Heads up that Evan us actively working on other changes upstream which includes both PHP 8.1 compatibilities and some additional fixes for the recent Git changes.

translations,The rebranding approach of changing the pht() keys will invalidate a lot of existing translations. Investigate if there are ways to avoid this.

In D25036#1081, @speck wrote:

This large diff affects 125 files.

oof

Created D25036: Catch up the master branch to upstream

As I started to thinking about the script to process the pht() files, it hit me that converting something something like:

FYI, it seemed that the issue with the wiki preview loading may be been related to tagging names... if the tags are removed, the preview loads

Some initial findings on Rector...

In T15071#1840, @speck wrote:

should we enable prototypes on this install to try and use the calendar application for organizing this event?

Would be a very good way to use a break during the week, and totally flexible for weekends here in that timeframe.. not sure if many are 9-5'ers Mon-Fri

Thanks -- I'm curious as to what makes this not particularly suitable for development, though?

In T15033#1516, @gadgetsteve wrote:

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

In T15006#1429, @speck wrote:

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.

Also this Vagrant pattern should work first-run with vagrant up: https://we.phorge.it/T15027#852

I'm down to do a https://meet.jit.si/ with someone else who is also down for this idea as well as the idea of translatable generic confirm() and alert() dialogs that can trivially go from pht() in PHP to JavaScript. Anyone?

We can have a i18n option for both confirmDialog and alertDialog.... Let's do this, who is down?

In D25015#793, @dcog wrote:

In D25015#792, @dcog wrote:

Thanks -- Can anyone think of a more generic solution here as far as dialogs? Something for both confirm() and prompt().

One thing to note here: Native JavaScript blocks execution when these functions are used. This is apparently nearly impossible behavior to mimic exactly, but we can solve this with asynchronous functions with our generic and platform-specific confirm() and alert() functions. Otherwise, should there be an always-available global translation for both alert() and confirm()?

Example of custom confirm():

JX.confirm({
  message: "Form data may have changed. Are you sure you want to close this dialog?",
  buttonConfirm: "Discard Changes",
  buttonCancel: "Cancel",
  onConfirm: function() {
    // Something something
  }
});

But it would need translation added...

In D25015#792, @dcog wrote:

Thanks -- Can anyone think of a more generic solution here as far as dialogs? Something for both confirm() and prompt().

One thing to note here: Native JavaScript blocks execution when these functions are used. This is apparently nearly impossible behavior to mimic exactly, but we can solve this with asynchronous functions with our generic and platform-specific confirm() and alert() functions. Otherwise, should there be an always-available global translation for both alert() and confirm()?

Thanks -- Can anyone think of a more generic solution here as far as dialogs? Something for both confirm() and prompt().

What if, to get this functionality pushed through, we for now change the verbiage to two English words -- "Discard changes?"

Any chance that anyone has insight on D25015? Specifically, a way to get l18n (internationalization/translation) information from PHP into JavaScript from a minimalist approach

In T15010#1272, @MikeCripps wrote:

Really glad to see Phabricator will live on - I've previously managed some bugfixes in an external repo and would love to try to get them into upstream. I've run Phabricator instances for 7 of the last 9 years (and was unable to convince my previous employer to switch) so I've got a bit of experience on the managing side as well.

Dug up some more info as well...

In D25015#678, @speck wrote:

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.

Does anyone like, not like, or have additional thoughts on the general idea of making one or more unique identifiers that isn't "phorge", for the purpose of an identifier that is unmistakably greppable? I outlined some notes on this idea here: T15006#831

Also I don’t believe javelin.io is related to the Javalin used in Phab.

Oh, another potential concern...

In D25015#616, @speck wrote:

In this case I think the error text is agnostic of the instance of the dialog. From looking at AphrontDialogView I didn't see any obvious way to include additional fields/text that could be pulled out here on the front end. Looking elsewhere in this file (line ~297) it looks like some other generic text is used

if (!this._paused) {
  JX.$E('Resuming a workflow which is not paused!');
}

However that's the only case where JX.$E is used outside of an is-development check. I'm not sure where these Javascript translations would go or when the translation file is generated.

In D25015#539, @Ekubischta wrote:

I 100% agree with this. Is there no way to invoke internationalization via JS only? If not, that's perfectly great, but wondering about an answer offhand.

I would like to be a part of the core team, and I've signed the document.

On a related note, tonight I discovered this UIExamples application (changing links from my Vagrant install):

In D25015#532, @speck wrote:

It’s generally more clear to have the buttons read “Discard changes” vs. “Ok” or “Yes”

I agree

Would it be easy to change the prompt to be more descriptive with actions?

For me, I think it might be on the hard side... and maybe add some bloat? Unless there is a styled generic confirm box created that maybe uses a callback instead of blocks execution...