I work on Phabricator.
Thu, Jul 18
This is expected behavior, but not exactly desirable. See https://secure.phabricator.com/T8952 upstream for some context.
I'm not sure what the purpose of the cookie is...
Wed, Jul 17
Ah, good catch. Yeah, files.viewable-mime-types is likely the culprit here.
One of these is detecting as MIME type video/ogg; one as application/ogg. The files.video-mime-types configuration option in Phabricator includes both of these MIME types by default, but it may have been adjusted on this install to include only one. If so, a simple remedy might be to add application/ogg to files.video-mime-types, if there isn't some reason that it was removed/disabled and I'm guessing right about what's going on here. Locally, with the default configuration, this file embeds with video player controls for me:
Mon, Jul 15
My expectation is that you need "Can Configure Application" on the Maniphest Application to edit Maniphest forms, and so on:
This is linked elsewhere in connected tasks already, but I believe the upstream change in https://secure.phabricator.com/D20647 should fix this.
I think Auth → Customize Messages → Login Screen Instructions should now let you configure this. I expect this approach should prove more stable than the older approaches.
I believe this install is currently configured to use ElasticSearch for global search. Search in other interfaces (including Maniphest advanced search) is powered by Phabricator's builtin engine, "Ferret".
Triggers currently only activate when a task card is dropped into a column with triggers (see this comment for details). They don't impose a global performance cost like Herald, and act on behalf of the user moving the card.
Sun, Jul 14
I've filed this upstream in https://secure.phabricator.com/T13340. See that task for more details.
Wed, Jul 10
This should be resolved upstream by https://secure.phabricator.com/D20644. The two changes noted above were similar, but didn't completely resolve this.
Wed, Jul 3
Tue, Jul 2
I think this will be substantially improved by the upstream change in https://secure.phabricator.com/D20636, which separates these actions:
Sat, Jun 29
Thanks, this should be resolved upstream by https://secure.phabricator.com/D20624.
Jun 6 2019
May 30 2019
This should be resolved upstream by https://secure.phabricator.com/D20562.
I can't figure out how to reproduce this in modern Phabricator. I suspect the original bug was related to inbound email processing of mail with extra whitespace in the mail body, but the transaction pathway has generally become more unified since this was originally reported and mail/web/API go through most of the same code now.
I can't immediately reproduce this in modern Phabricator. Here's a user who can use the "Paste" application:
I suspect this is largely obsolete nowadays with the option to add instructions to custom forms? The New Bug Report form now has a block of instructional text, particularly.
This reproduces for me in browsers other than Opera, but requires the "Persistent Chat" option in Conpherence be enabled.
Upstream, https://secure.phabricator.com/D20561 will add a "View Task" button to the upper-right corner of HTML email from Maniphest.
After https://secure.phabricator.com/D20527, commenting with the full URI of a paste or task on an object will count as mentioning that paste or task. That is, commenting P123 or https://phabricator.example.com/P123 both generate an "alice mentioned this on Txxx." story on the paste.
I think we're very unlikely to implement this specific change (placeholder cards) in the upstream. See also T187051#5191464 for a similar issue.
Based on this request, I don't currently plan to change this behavior upstream.
This looks like a couple of different requests:
It is intentional that bots trigger notifications and can not be silenced. This serves to prevent a rogue administrator from creating a bot, grabbing a bot API key, and then making a bunch of secret edits which don't notify anyone. Phabricator does not allow any user to act silently without CLI access.
I think there are at least a few different flows here:
This should be resolved upstream by https://secure.phabricator.com/D20559.
I think we can do something to make this less confusing, this isn't the first time I've seen someone run into trouble with it.
I think this is likely an upstream problem. I think we try to add the "natural" hashtag on a rename, but maybe we're looking at the old "hashtags" field, seeing the "natural" hashtag is already there, and not realizing that it's being removed by the edit. Let me see if I can reproduce/understand this.
May 24 2019
I believe this should be fixed upstream by https://secure.phabricator.com/D20340, I think this install just hasn't deployed the fix yet.
To remove actions from the stack of actions above the comment area on device with small screens, swipe left on the action.
May 23 2019
This should be resolved by https://secure.phabricator.com/D20552.
Yep, this reproduces for me. (Although I think the behavior is an infinite loop of prompts, not just "twice"?)
Yeah, spam/abuse are pretty clear-cut (and probably 90%+ of our upstream disables are for those reasons too), but we've also had a nontrivial number of "this guy was kind of a jerk / lawbreaker" cases where I probably wouldn't want the comment public.
I'm theoretically supportive of this but it's not obvious to me how I'd implement it. Did you have a plan in mind?
May 20 2019
If the root problem here is something like "Users who are familiar with syntax X in tool Y may try to use that syntax when filing a task and be surprised that it does not work in Phabricator" and this is causing a substantial amount of confusion, a cleaner remedy might be to forbid the syntax outright:
I don't see how that commit explains why including the public key in the email is a safety feature, or what attack this feature is defusing, or why including the key is "better" than not including the key.
Can you walk me through a scenario, step by step, where the having the public key in the email makes things safer than not having the public key in the email?
May 19 2019
Why is including the public key in the email a safety feature? (How does this make things safer?)
I'm not sure what makes the Gerrit message "better" here so I'm not sure what changes are desired. The Notification-header-login-success/en link also doesn't make what changes are desired clear to me. Is this task specifically asking for guidance to "contact your administrator"?
This has shown "Restricted Task" for some time, I believe.
This is declined upstream and not likely to move forward.
I'm not sure how to reproduce this. I don't see any scrollbars in Chrome on this task, or T180864, or locally, at any zoom level (I'm on OSX).
Administrators with CLI access can bin/remove destroy Zxxx to destroy a Conpherence (or most other types of object).
The upstream is exceedingly unlikely to change this. Although "KB" is not a technically precise unit, it is widely understood by users and is the unit used by both MacOS ("KB" in "Size" column) and Windows ("GB" in "Disk Space" readout) to identify filesizes:
Differential has had policy support ("Visible To" and "Editable By") for a long time (upstream in https://secure.phabricator.com/T603).
I've included this upstream along other planned improvements to sounds: https://secure.phabricator.com/T13292.
See also T76095. Until recently, referencing an object with a full URI (https://phabricator.wikimedia.org/Pxxx) instead of a bare monogram (Pxxx) did not activate any special rendering/processing. Now, it does (see T76095#5191016 for details).
From a technical point of view, I think this is effectively a duplicate of T1016: if we added SVG support, all contexts (including avatars, attachments, cover photos, etc) would support it. However, it currently seems unlikely that we'll add SVG support because of the very difficult security landscape and limited interest (largely only WMF).
This is an issue with orientation metadata (usually EXIF?).
Titles are plain text.
May 17 2019
The workflow parameter was removed some time ago.
I believe this was resolved by changes connected to https://secure.phabricator.com/T6367.
See also T86464. I don't currently plan to make further changes here to support customization of relative/contextual human-readable dates like "Jan 1 20XX" and "Mon, Jan 1". Dates in most other contexts are customizable and support ISO formats, and times in all contexts are customizable and support 12-hour and 24-hour formats.
I also can't reproduce this on this install, in the example link:
I changed this to "" somewhat recently, which I'm sure everyone will agree on unanimously.
We consider object open/closed status to be private information, so the upstream is very unlikely to make changes which expose it to users who can't see the objects.
Titles are plain text, so the plain text input is always a faithful preview of the result.