Can you show me the output of these commands?

Actually, I'm slightly wrong about dropdowns-in-dropdowns being the issue, looks like some kind of rendering order problem instead.

Dropdowns need a bit of CSS tweaking but they feel OK to me.

e.g., pretty sure we can do slightly better than this without resolving any big philosophical questions:

We can/should also make hovercards richer -- I think that's mostly "free" in terms of product/design tension, especially for cards like mocks which have received very little attention.

oh, yeah derp. single line with more info would kick ass

Yeah, I'm leaning toward starting there too.

Oh, I wouldn't plan to make them meaningfully taller vertically -- I'm primarily imagining a very small adjustment ala "Reviewers" in Differential, e.g.:

Let's start with the two dropdowns and see how it goes.

In T11085#181202, @scode wrote:

@eadler Did you have enough insight/recollection as to whether all our reported cases were due to users editing in the web UI?

I go back and forth on if Tasks/Revisions/Commits should be richer. I do think maybe we can leave them as a list but have a button/dialog to pull up their full cards? My main concern UI wise is they'll take up a ton of space on larger tasks and really force the content down.

Yeah, I think that's totally reasonable. I want to fix up the UI for showing subtasks and revisions and stuff as part of T4788, so I'd expect to do this:

I'd probably turn this into two sections (I guess?) if we had a dropdown/disclosure element:

I was sort of hoping to make Pholio (for instance) a rich panel in the main column. So if I attached M1464, I would get a Pholio Panel with

Some ideas here:

I'd like to have a clearer sense of how we're planning to resolve T10034 before moving forward here, even if we don't actually build any of it yet. Briefly, I think some of the problems here are:

If I have to write code and drop it into my local install to reproduce the issue, it's custom development and it's not supported. The documentation may be incorrect, but like a prototype, it's not intended to be ready for end-user use (only internal developers).

I did not ask for support in third party development.

See T5447 for more details on the state of app development,

Damn man you're good.

We don't support third party app development.

Run your-package-manager install php-xml or php5-xml or php7-xml or whatever it's called on your system.

Relatedly: it would be nice if milestones copied the settings of previous milestones, sort of a pseudo template behavior, where milestone2 copied the defaults from milestone1 automatically (so that if you set a series to default to the workboard, every newly created milestone would share that setting unless you override the default)

Personally I'm using milestones to represent releases and the workboard is the farthest thing from what I'd want to show when clicking on the milestone.

Thanks asherkin! I was looking for it!

I saw the issues about windows being generally broken. I sympathize with the team's plight having been there too many times with cygwin and git bash over the years. FWIW I think the best approach is to normalize the path references back to unix format as fast as possible. The approach of mapping driver letters C:\ D:\ to /c and /d etc is reasonable. Beyond that there is the usual handling of spaces and () {} etc to consider where php/bash might get confused.

So I managed to resolve this eventually. It looks like the underlying cause of all the problems was that the SSH daemon on the build server itself had got into a weird state where it would accept connections, but not initiate an actual SSH session.

So I manually set the resource to a destroyed status, cleared out drydock_command and saw Drydock attempt to start allocating a new resource. However, now I'm getting:

@epriestley no i dont have any relationship with core Sandstorm, I'm a user and a fan of both apps. I'm just a student who wants to make life easier for the end user , and you create as much repercussion about it, I want to help phabricator and all other tools that I believe I send this text.

I followed up on this in #sandstorm on Freenode but this isn't officially sanctioned as far as anyone there knew. They're not particularly happy about this either, but obviously there's little anyone can do about users going vigilante with evangelism.

Oh, you've just been spamming tons and tons and tons of projects with the same message:

I noticed you posted the exact same message that you posted here to Drupal, with the same spelling error of "Oasis":

@chad yes, and want to help who don't know how to deploy Phabricator to use Phabricator and Sandstorm is perfect to that.

@MatheusVieira are you asking us to support it because you're a Phabricator user?

Link to the Sandstorm Vagrant SPK documentation - https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tutorial/

Ok, but nowhere in your first message did you mention Phabricator. It looks like cut and paste spam to me.

No not a mistake, i think that Phabricator could be on Sandstorm Market.

Did you post here by mistake? This doesn't look intended for us.

Custom domains probably need a way to link to an alternate root (e.g., the main company site).

The major custom domain issue is that there's no way to specify a protocol (HTTP vs HTTPS) or port (although this is less important). In particular, http://blog.phacility.com/ works and is the default live URI for that blog, but we would prefer https://blog.phacility.com/ to be the default URI and for http to redirect to https.

@epriestley Any of what's left reasonable for me to accomplish? Or are they all super technical?

I saved "Ignore Conflict" here and on phabricator.wikimedia.org , but a few hours later the warning message overlay has reappeared. Im going to ignore it here, so that the devs can see when I last saved "Ignore Conflict".

Hit by this again on a trip to a nearby country. Can the "Ignore Conflict" option be moved out of the list so the user doesnt have to click "Save Timezone" to in fact register they want no change. I instinctively want to hit the Cancel button on this popup/overlay, as I dont want to change my timezone. I just want the message to stop.

If you're trying to create projects here, you don't have permission. This is the Phabricator upstream (for building Phabricator). It's not a test install.

I don't know who this task is intended for. Are you looking for a different Phabricator install perhaps?

Awesome response, also fair that this won't be primary functionality. I feel our case is extremely edge due to poor environmental composition, which phabricator shouldn't be attempting to solve for us.

This is sort of exceptionally stupid and probably fairly broken until T10769 is further along, but we have a cluster read-only mode now (used when the master database is lost in a cluster configuration). Rather than using it as a disaster recovery / availability mechanism, you could force users into read-only mode explicitly, by doing something like this:

Might not be a strong use case, but we stumbled on this while talking internally about it. In our environment we've got many developers using phabricator, and an external 'manager' that basically just wants to see activity, but none of the developers want that manger to have direct interaction with their objects.

I just encountered the same problem and this solution worked for me as well. Thanks @DheerendraRathor !

In T4631#181162, @epriestley wrote:

you'll need to figure out how to get users to upgrade arc on your own until T5055.

It's probably the correct solution to create ancestor slugs automatically if you so choose. I believe this is what you're running in to?

After D16145, Harbormaster should immediately release resources which no remaining (running or queued) build step takes as an input.

Ah sorry for the confusion. I was trying to keep up to date on the weekly updates and didn't realize this flow had changed. I'll look at upgrading in the following week or two.

There are two completely different flows. At HEAD, the flow is entirely different and uses none of the same code.

there's no way to change "Edit Policy" from the initial form page

Is that not the same thing as "Editable By" during repository creation?

It's also insanely trivial to allow empty pages too though.

I'm hesitant to pursue any feature that really just serves as a temporary band-aid for one install. It's probably the correct solution to create ancestor slugs automatically if you so choose.

This would work now, except that there's no way to change "Edit Policy" from the initial form page.