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!

I'm going to look at trying to land this today. Additionally I created T15042 to avoid situations like this where the changes are accepted but don't get landed for some time.

Reference to the last Phabricator starmap prior to deletion. Phorge's starmap will likely align very closely with Phabricator's, initially.

With this change these log messages are being written out, even though the default of $this->quiet is true. I think this is because rebuild-map.php script unconditionally calls setQuiet() with the value it's passed from the command-line, however ArcanistLiberateWorkflow does not specify or pass in a quiet argument.

I think this looks good, and based on the (non-search-engine) conduit API stuff I'm familiar with I think everything looks correct.

Is there information about the IRC channel or Matrix channel on how to get set up? If there's chat I'll try to join in but I won't be able to be always-connected.

I added you both as well! Welcome to the team. If anyone has pre-existing functionality that they feel would be good to include in the upstream feel free to submit the changes. There's ongoing work (unfortunately slowly) to rebrand the project, but that's not holding up other changes at this time.

In D25015#633, @avivey wrote:

In this case I think the error text is agnostic of the instance of the dialog.

I was thinking about this use-case, which implies to me that the dialog author should be involved in the error text:

For the case of email headers

In https://secure.phabricator.com/T13658#256009, @epriestley wrote:

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

Depending on how many of these we end up with, I think an email-header-prefix sort of config option might be reasonable.

Ah I did not look closely enough. Dang. We should be attaching the message to the view on the server then, somehow.

This looks good to me.

I added @dcog @codemouse92 and @mydeveloperday to the trusted contributors group. Glad to have everyone involved!

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!');
}

I'm not familiar with the search engine or legalpad frameworks but things look like they line up

The ubuntu/rhel scripts have been removed in the upstream (https://secure.phabricator.com/D21678). We can probably avoid making changes to those files as they should go away once we merge in changes.

The arcanist source in general seems to be split between fwrite(STDERR, $message."\n") and fprintf(STDERR, "%s\n", $message); I decided to go with the latter.

I think the latter format would be preferred as the formatting is more common elsewhere in the code, as opposed to concatenation.

I think this would be reasonable but I think it requires setting up an account on GitHub or Google on behalf of Phorge (rather than using a member's personal account). If someone wants to set up a GitHub/Google account for phorge we can set it up here. It'll require an email address though and I'm not sure how to handle an organization email like that.

I'm not a big fan of IRC because in order to look through history or pickup where a user last joined it requires individual users to maintain their own tooling/practices. The temp-community chat was the first Zulip chat that I've used, and installed the mobile app for. I thought Zulip worked pretty well and wouldn't mind continuing with that. I've used Matrix (Element?) briefly but didn't feel too strongly about it. It's probably worth mentioning that our current Zulip instance has ~135 members and we've still had ~1-2 new people join per week lately. Though there's not much actual discussion going on there.

Handling of merging upstream changes will probably lead to some challenging merges done by people who did not author the original changes in Phorge. I don't know what the best way is to work around this. Maybe if we regularly (daily?) pull in changes from upstream, merge into our own master branch which everyone lands onto that should mostly catch merge issues?

Would it be easy to change the prompt to be more descriptive with actions? It’s generally more clear to have the buttons read “Discard changes” vs. “Ok” or “Yes”

Yea I think it will be easiest to host this on the same server that's running we.phorge.it. If we're able to build it as an extension application for phabricator it can be setup in the same installation and then we can route the web server to host it properly.

If it's not worthwhile then let's not do it

nit-pick: maybe name them phabricator/master and phabricator/stable.

I'm fine with whatever naming

I was discussing with @deadalnix a bit and I think it would make sense to retain branches in our fork that represent the master and stable branches from upstream, but not be the primary branches we commit/land phorge into. That would allow us to keep synced with upstream's changes and regularly merge those in. I think operating in this way would also let us be a little more flexible with allowing other changes to be worked on and landed in the phorge branches without being blocked by the rebrand changes. Then at some point in the future the rebrand changes would come in from the upstream branch, merge in, and we could make an official Phorge release.

The future plans for the domain landing page are under T15008: Build Welcome Site. I'll close this out for now since the redirect is working.

I think it makes sense to host repositories here. If we go with monorepo what would general permissions be for something like that?

It looks like all @20after4 has to do is land that change into the upstream as it's approved. It might be better to have it land upstream then we pull in changes from upstream (there are a number of changes this fork is now behind on)

Thanks for pointing this out. I updated the link to the correct one. Somehow an extra hyphen appeared in the URL which I swear I had copied directly from the page.

Hm I tried updating the nginx configuration to do a temporary redirect to https://we.phorge.it but it doesn't seem to be functioning properly. Someone else with better nginx experience might need to lend a hand -- @Matthew maybe?

Are we supposed to make a similar lengthy statement?

Heh, I wasn't really sure what people were expecting so just wrote up some stuff to explain who I am and what my role will probably end up being.

After agreeing and signing the document I submit myself here as a core team member, officially.

@jupe thanks for pointing out the typo, I've updated to fix that.