(In the longer term, the permissions here could probably be cleaned up, but I think that's the cleanest fix without upstream changes.)

You can edit the "Create Form" form and change "Visible To:" to "Members of Project: Doctorate in Form Theory". Then only members of that project will be able to create other forms or edit the form form, I believe.

Ah. I think you'd just see this, then:

Overall, you only get checkboxes for users, packages and projects which are already reviewers, with the exception that you'll get one for yourself if you aren't a reviewer yet.

I think there is also zero legitimate reason for the form-configuring-form to be editable and this entire workflow essentially represents a trap for the unwary.

If you can't enable that form, you might need to go hunt it down in the database and manually enable it (or tell me what you hit and we'll fix it if it's a bug).

Can you click that link, then "Enable Form"? Or do you get some kind of error?

A MARVEL OF ACADEMIC PURITY, EDITENGINE PUSHES THE BOUNDARIES OF ADVANCED FORM THEORY TO NEW DEPTHS

DO YOU HAVE ACCESS TO FORMS FOR CONFIGURING FORMS?!

Yeah, there's no real hint about that in the UI to suggest that the box will update, and it's easy to miss since it looks nearly identical after it updates. I'll add a piece of hint text to hopefully make it more clear.

Oh, maybe we could make this more clear. Here's how to use the examples to figure out how to make a call:

(Kicking Documentation off because this would just be another tab next to PHP / cURL / arc in Conduit, not static documentation.)

Can you use a service like https://requestb.in with curl?

Does your webserver error log have a more specific stack trace on the server? I can't reproduce this locally.

I don't really see a pathway to turn this into a particularly useful and/or hilarious feature that has enough of a payoff to justify the legwork.

Actually, this is a little different from what I've been seeing locally. I'm just going to merge this into T11037, which discusses some general improvements to phd status output.

Based on like 10 seconds of looking at the code that's where I'd start. 💯

We should still be able to handle this case, but I can take a look at what's happening since this is a nonstandard element and the fix is probably easy once I understand what's going on with the logic.

See also T5853 (distinguish between "blocking" and "reviewing" in email) and T10574 (provide more guidance around the pathway toward a revision becoming accepted).

I can't think of any offhand. It might be easier to fix the dashboard/panel stuff first (i.e., inherit parent dashboard permissions) and then do this rather than the other way around, though.

We can also shrink/hide buckets from the panel context but keep them from the ApplicationSearch context. I think that's desirable -- if you go to /differential/ it's probably good to see all the bucket headers? Just not so good if you have a "Stuff to Review" panel on your home page.

With subprojects, #project changed to mean "that project, and all its descendant projects", but any(...) and not(...) still mean "just the parameter, exactly". I think viewerprojects() and projects(user) are also "just the parameter".

Great! Thanks for the report, and for your help confirming the fix. Let us know if you run into anything else.

Thanks! That's consistent with 32-bit and I suspect the & 0x7FFFFFFF part of rP9326b4d131ce will fix it.

(Alternatively, upgrade to rP9326b4d131ce and run the bin/people ... command again and see if that just fixes it.)

@deathsyn Can you show me the output of this command on your system to help confirm that there's a 32-bit issue at play here?

We could probably ship it (.md in Diffusion rendering as GitHub Flavored Markdown) this week -- it wouldn't be perfect, but we do have total freedom there to iterate as we find cases we're missing there -- it's just a pretty hard sell as a priority for me relative to the development cost. Obviously it would be nice if you bring in your repository to Phabricator and the README.md renders perfectly instead of rendering mostly-okay-but-a-bit-buggy, but it's hard for me to imagine we're losing many users there.

I think the two goals are sufficiently in conflict and the value of supporting these rules is so low that it probably isn't worth the effort to try to get it right most of the time.

My viewpoint is that Markdown was developed for writing first-party blog posts, not for technical discussions about software.

Oh, sorry! I totally missed the bit with italics which described things quite precisely.

@cspeckmim I think that patch fixes the issue, thanks for hunting down those reproduction steps!

I haven't seen more of this and there's no planned action on our end, so I'm going to presume we've weathered the storm.

I'm going to fix the bug with these reproduction instructions:

T12003 is also related to this (providing more explanatory, contextual help for users executing searches which may not be doing what they want for technical reasons).

There's some additional stuff in D17384, where Elastic has an internal hard limit of 10K results.

@beber, please file a new task with reproduction instructions that work on a clean install if you believe you've found a bug.

One other thought as a sort of counterpoint to myself: if we do implement T11367, I probably would expect it to work more like "portals", where you define a portal/directory/volume and everything inside it shares the same permissions. But that's because I'd plan to eventually build DefinitelyNotDropbox.app for bridging file directories to the desktop so you could mount the filesystem on your computer as a disk, and I think we get into enormous amounts of trouble if I mount the phacility_tax_documents/ drive locally and then individual files inside it might have individual permissions so I couldn't view or edit some of them, since there's no way we can give users guidance about that from a filesystem mount. But maybe we have more flexibility there than I think.

I think we could just add spaces without any real fuss, yeah. Two possible considerations:

I do think we could make a product argument like "the hierarchical permissions system is too complicated for users to understand, and they'd be better off with a less powerful system". That might look like:

I think PhrictionPortal probably doesn't look too much different from "make a second wiki, except this time you don't have permission to edit the root document, and it's locked to public / all users visibility automatically, and it's at some other URL other than /w/, and remarkup has two different rules".

When I create a second portal ("Encyclopedia of Fruit") and a page ("Orange"), what URL does the page exist at?

I 😍 love staying in touch with my favorite brands. 🎁

I got the python script working by changing "w" to "wb" like a comment suggested, but I'm only getting all-black bitmaps out of it.

Does anyone actually use the "Stories" feature in one of the other things that implements it (Excel, Settings.app, Disk Recovery Utility, etc)? Why is it compelling?

The UI should probably look like this (not 100% final/polished yet):

I think pictures are part of a "story"? We can have users upload pictures and take pictures with phones. There doesn't seem to be a native CLI way to get Macbooks to take photos but we can make users brew install imagesnap, it seems, and then arc could update stories.

Thanks for the extremely thorough bug report. This should be fixed in HEAD of master, and promote to stable within about 72 hours.

I'd guess there is a ...->setContinueOnMissingFields(true)->... missing on an Editor somewhere.

Actually, that fix is completely bogus and there's no inverse edge type so this is perhaps somewhat more involved.

This is probably a one-line fix, but let me repro + get test coverage on it.

This is expected:

I can't reproduce this. Phriction is successfully public on this install:

It's a lot easier to merge stuff than split it, so don't worry about filing new stuff if there's any ambiguity. We can merge them with a couple clicks, but if you've really described a different issue then splitting them is much more of a pain.

(And it's easier to build query panels.)