If you are really really really interested in hard-blocking Task creation from custom rules using Herald, it should be probably developed a new Herald Action to support the "block Task creation" if something happens. But I honestly cannot implement this feature, so at the moment I hope the "auto-comment" is enough for you.

One thing that could be done right now is:

Thank you again for your question. Sorry if I start marking this as closed since currently this specific Task with this title is probably not implementable as-is. We have some approaches, but without much feedback from the original poster and from other users it's very difficult to do something concrete that do not impact other workflows.

As a proof of concept I've uploaded a GIMP image (GIMP = green is my pepper) as Task image.

OK no sorry, it already does not show any content.

@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

The concept we're aiming for is "Extension Store" - Core to be minimal,. and everything else to be an optional install, with an "app store" somewhere here, and making installing extensions easy.

Isn't it possible to open a branch for that? who decide what feature can be integrated in Phorge? Just a remark, Phrequent *is* the application for time tracking, even quite empty by now

D25015 was by @dcog If it can't be fixed with an update, this should be reverted

In T15034#2338, @Ekubischta wrote:

Hit esc today - Lost lots of typing

Just an upvote for landing D25015

Looks great. I implemented a rough and simple logging feature over Phrequent, your extension looks more precise. I would think its better to merge/replace Phrequent rather than adding more implementations, though

https://secure.phabricator.com/book/phabricator/article/custom_fields/ custom fields allow you to set the required property in configuration. I'm not sure if you can use this to override a default built-in field but you could possibly replace the built in field with a custom field with same/similar name and type: users.

@avivey Thanks a lot for the hints. I will take a look at the Spaces. That sounds like it could be helpful for our purposes.
@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

(Regarding the original task description:)

But still it is worrisome that we can configure visibility only by Administrators, yet everybody can assign the project as subscriber... Maybe that is a bug ?

@rraval Right, i overlooked this setting. I managed to hide most projects from the Subscribers Search panel. We also have reduced the number of Projects to keep things more tidy.

@Higgs You should be able to Project → Edit Details → Visible To → Project Members. Does that do what you expect?

We use Projects for grouping users into teams. But unfortunately every user can see all Projects and assign them as subscribers to Tasks, regardless if they are members or not. Normally (in our case) Tasks are only relevant for users in the same project. Having the other projects displayed in the subscribers selection is unfortunate in this case.

Our instance uses a ton of projects as "groups of people that need to be notified", so we use project subscribers a lot.

I don't think we have this capability right now.

Please do not triage tasks yourself, we will integrate it into the roadmap as we go.

Hit esc today - Lost lots of typing

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.

I'd definitely love to see this later. I MIGHT be able to get to this later.

This looks pretty great! - I think T15030 is the general covering task for Extensions

Thanks!

In D25015#826, @speck wrote:

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.

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.

I feel like we should move translation to a new revision, so we can move forward with this one.

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

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.

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?

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

Dug up some more info as well...

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

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.

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.

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:

What are the implications of making changes to the javelinjs.com https://github.com/phacility/javelin/ library?

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

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

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

+1 this has bitten me before.

The translated text can be a property of the dialogue itself, if we're worried about having extra objects laying around - the confirmation feels like it's a feature of the dialogue anyway.

There's no way to invoke pht from JS (because it's really complicated in the general case). The general practice is to provide the translated value from PHP when building the relevant objects. There should be an example in the UIExamples app - there's a page with buttons built in JS.

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.

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

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”