I have been trying to see about another way to do this until this is added (if it is I should say). We are finally getting ready to move to Phabricator, and I was hoping there was at least a shortcode or something I can use. Currently what I was trying to do was paste the query URL for a particular project's Passphrase credentials. What we were going to try was getting the query for whichever project's passwords, copying it, and adding it to the Project as a custom link.

Hi @tappers, I can't get your query flow to work on my machine, would it be possible for you to give me a simple example of a working query ?

The apparent lack of support for scheduling in UTC in much more mature calendar software (Google Calendar / Calendar.app) further suggests that this is not an important feature for most users.

You need to clear some caches too - ./bin/cache purge - but I'm not sure which; And then hard-refresh the in the browser.

Generally, this sort of discussion is better on Discourse (https://discourse.phabricator-community.org) than here.

I'm going to merge this into T4369, which has some similar discussion and more context.

It should also work with Mercurial (D18652 and D18653 were my Mercurial tests).

I missed your question in (1). A typical scenario for this would be when working on a feature which requires some refactoring work to be done. A revision is created with just the refactoring work and then a dependent revision is made which includes the actual feature work. During feature work additional refactoring might be made and need to update to that changeset and either add/amend changes, rebase the dependent revision back on top. Having the bookmarks auto created would help especially when using arc:bookmark when updating revisions back to phab.

Is the experimental fix git-only or can we test with mercurial as well?

D18651 is marked as fixing this. The "fix" is very rough and will land in the experimental branch, see T11911 (and perhaps T12996) for followups.

We generally stopped seeing this after moving to InnoDB FULLTEXT, which seems less prone to table crashes than MyISAM FULLTEXT was. See also T12819 for the fate of InnoDB FULLTEXT.

We'll consider offering instances in the Sydney region in the future, but this isn't really a valid feature request or bug report. Feel free to continue discussion on Discourse.

Should be quick to implement.

See also PHI41.

Just sweeping this up, rewriting the property display to show +x seems reasonable to me but I think it's self-evident enough that we don't need to keep a task around for it.

I don't think this meets the high bar required by modern feature requests (see "Upstreamable Feautures" in Planning).

(This isn't anything upstream-actionable.)

In T10890#231066, @epriestley wrote:

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

remind me to add some more icons for Link.

That looks pretty hawt.

Happy to take a look if you found a reasonable way to get access to $request. If you're reading $_REQUEST['__path__'] directly or something though the eventual upstream version probably won't look too similar.

I've written a patch to make this work for the project sidebar nav for my organization's install. I don't want to take up your time with it if it's not helpful, but let me know if you'd like me to push a diff.

I'm just going to merge this into T5258. There are two separate issues here:

This bug does exist on this server, but unclear why. Maybe related to size of image, but probably best solution is some command-line tool to regenerate all file transforms? I don't think making PHIDs easy to find inside the app is very user friendly.

Doesn't look like the repository will even attempt to clone over HTTPS:

In T12950#230520, @chad wrote:

Why did they need regenerating in the first place?

Why did they need regenerating in the first place?

This is an unusually low-tech solution but I can't think of any reasons why it won't work.

I'm obviously low on AM brian power today.

Heh, that was going to be my suggestion in the original discourse post, but I figured it was too simplistic. Glad to hear we're on the same page. Thanks everyone!

That sounds much easier than all the solutions I came up with.

Is there any reason that the rule "if any menu items have the same link target as the request URI, highlight the first one" wouldn't work?

Or maybe there is a simple way to get the link to highlight, I couldn't think of one though.

A link doesn't stay highlighted if clicked on. Like dashboards, I can understand wanting multiple board views from the sidebar.

• What's the root problem?
• Why can't they use links?
• How is this different from T12374?

Oh, I didn't even expect that option to be configurable on Phacility given it's a security related setting. I'll turn it on and do some speed tests next week to see if I get any measurable difference in cloning.

Have you enabled diffusion.allow-http-auth?

When you click Clone in the Phacility UI on a repository, it doesn't show any HTTPS URLs. It's possible it works if you copy the URL from the address bar, but the UI in Phacility itself doesn't give any kind of indication that it will work.

Feel free to use our Discourse for general admin questions (as opposed to our working tasks). Thank you!

@ofbeaton Thanks for the tips. Sounds better than the approach we are using to slightly modify the code base.

@jessjohnson We use puppet to deploy phabricator stable from a copy on a local file server, then have it run a shell script that applies our patches using git apply on .patch files. Lastly we restart services.

@ofbeaton Just curious what's your strategy on applying patches as part of your deployment for phabricator? Do you use a find/replace strategy? Apply diffs?

Agreed. I haven't experienced the problem since I upgraded, so I think it was related to an earlier fix, even if it wasn't the identified fix (which should have already been in my install when I did have the problems). There's nothing that needs to be addressed here.

This is vague and may not actually identify a problem; I don't plan to pursue it.

This seems to mostly be a matter of taste, and we already have behavior similar to the behavior of git, which seems reasonable.

We aren't going to implement a bin/phd start-missing-daemon command.

I'll add a link too, it's reasonable.

The problem here is the default for the default branch, when the user didn't set it explicitly. In a user perspective it's then hard to know there's this option at all. Some link to set the default branch from the error could be more clear, but I don't think that's a common in phab to do that.

In T12896#228825, @jmeador wrote:

We"solved" the problem with a small python daemon that pings repository_statusmessage.epoch every minute and calculates the delta. When these deltas surpass Phabricator's max delta (21,600 sec) we page the oncall. For repositories that are mission critical, we use a smaller value. It obviously isn't a perfect solution, but it gets the job done and it's been extremely stable.

What if they're on the page, is that notification annoying? I love click that little guy.

+1, we've also had a handful of users request this as a per-user preference.

Or just have a subtask-array configurable, going with the inline approach mentioned above:

Also, it would be great if you can choose an optional "default subtask subtype" where you configure the subtypes. Something like this:

T4411 discusses some similar issues, although it predates Spaces and focuses on subscribers rather than assignees.

The page implies that all I should need to do is POST up, for example, the following:

Can you point me at where that's implied so I can make it more clear? That isn't currently expected to work. ... We do not currently support a blob of JSON as the post body, and the documentation shouldn't imply that we do (if it does, I'll fix it).

Methinks that the Rube Goldberg solution for this would be to get unittest.skip to have another argument with a task number, and then validate with lint/runtime that it look like T1234. And then maybe grep the body of the ticket for the filename.