and yes, I'm also running phabricator on top of CentOS 7 (using PHP 7.x via SCL).

In T15047#1302, @Ekubischta wrote:

Isn't Centos End of Life soon?

^^ Awarding a Token to a "... awarded a token." Message would be a weird case. But what about removing this Message completely? (or add the Option to hide them) It bloats the history of some Objects imensely and is not that usefull in my opinion.

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.

Is it possible to pick a branching off point?

Also, https://secure.phabricator.com/T7413 for the phone-home feature.

The kind of teams that use Centos/Redhat are very conservative - they're exactly the teams that would not install PHP from an "alternative" source (or from source code). They also tend to keep to older OS versions, as long as they are supported, and would not be happy with a single machine being different from the rest.
All that to say, it would make these teams sad to require an upgrade.

I'm mostly a Debian person (so I'm not aware of CentOS specifics) but my understanding is that CentOS 7 shipped with PHP 5.4 and has newer versions available via alternative repositories (not sure if official or not), while CentOS 8 (and Rocky Linux 8, if that matters) had PHP 7.2 by default and shipped a few years back. Is there a reason we're not basing our PHP support on latest distro releases (plus something like a year or two for a transition buffer), especially if newer PHP versions are available for older distro versions available as backports? I don't think requiring PHP / distro upgrades every few years is unreasonable.

Isn't Centos End of Life soon?

+1 for CentOS 7.

Agreed. We should aim to follow some specific conservative release. CentOS 7 seems reasonable.

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!

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 will note that also the tech docs aren’t fully generated since there should be docs for most of the phorge/phabricator classes. Also the arcanist docs aren’t generated at all.

The Server also needs to periodically rebuild the Diviner Books to keep them in sync with Source Code. Eg. just set up a crontab entry. Or later, if more traffic is on the page: rebuild it once a commit affecting the Docs is committed.

The Herald rule should be project specific. If X happens then move task to Project->Column

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.

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.

In T15043#1258, @CSharp wrote:

Maybe the "move to column" rule should only apply if the task is already assigned to the project, if it isn't, it gets ignored.

In T15043#1256, @speck wrote:

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.

In T15043#1256, @speck wrote:

I think this will work out technically but it feels a bit nebulous to me, in that the rule isn't really clear about what it's doing as it's very dependent on the project workboard that gets triggered. For example some workboards might be roadmaps/planning and want to have columns for e.g. inbox, backlog, next_version, etc. but other workboards might be categorical in nature rather than planning and there would be no overlap between what column types exist on those boards. I think a solution revolving around Project-based rules should be investigated - for example is it reasonable/possible to have a herald rule on a project that says, "when a task on this project board changes status to: x, then move to column y"?

Dug up some more info as well...

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.

In T15043#1251, @speck wrote:

Maybe the herald rule should only apply to specific objects? I think there’s a concept like this already where certain rules can only be made at the object level and not global level, possibly for similar reasons.

@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/

• use weekdays.length

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 describes how to set up an IRC nick for matrix users: https://gist.github.com/LorbusChris/d44a5dd4671796cbf8528ca133dd909b

In T15043#1246, @TitanNano wrote:

Just having a dropdown here would be enough, I guess?

Indeed.

@TitanNano: One way to store the type, without changing any schema, would be to drop it into the metadata json blob which columns already use for recording which column is the 'default'. Unfortunately that isn't the most convenient thing to query, however, it's not that bad thanks to mysql's json functions.

• Merge branch 'master' into arcpatch-D25016
• Use Pipesymbol for splitting Day Abbreviation String

Just having a dropdown here would be enough, I guess?

It wouldn't be too hard to add a type to columns but we'd need a way to set the type from the UI somehow.

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.

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

In T15002#1224, @TitanNano wrote:

I just wanted to note that Phrequent is an integral part in my company, even though it's a prototype. We heavily rely on time tracking.

In T15002#1203, @MacFan4000 wrote:

I’ll note here that I’m going to work on creating projects for some of the prototypes that do get used.

Now that I look at this some more, this isn’t quite done - there are still some components of phorge that are missing projects.

Looks good, hopefully this can be landed some time soon.

I’ll note here that I’m going to work on creating projects for some of the prototypes that do get used.

I also agree that #3 seems promising. FWIW it's incredibly easy to develop new herald actions and as long as the current herald rules do the thing you want to do then the action would be very straightforward. Maybe the usability would be improved by exposing the rules that affect a board through the workboard UI instead of having them scattered around random and disorganized herald rules in the herald ui?

In T15044#1193, @speck wrote:

@TitanNano additional context around the development style that causes this issue to come up would be useful to include here.