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:

Ok I think this is mostly a UI issue then, and I didn't think this entirely through. Also, spaces then should just work?

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:

(this is a problem for me switching on and off projects, haha, I forget design decisions)

I probably solved most of this with my Phriction redesign which visually treated child pages as navigation.

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

Hmmmmm, so this essentially exists but you have to make /w/ public in order to achieve it?

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

Yeah, we kind of fake that now by offering an index page on Phriction welcome with major projects being there on "root" level.

I'd love to see anchor indicators when hovering headings.

Sorry, this isn't a feature request we can accept. See Support Resources for help understanding what kind of support is available, and Contributing Feature Requests for help with feature requests.

That sounds good to me.

I think it would be reasonable to treat this field as remarkup (at least, internally -- probably no bulky UI) so we end up generating a mention on the task. I have similar reservations about making "fixes X" start performing magic in surprising contexts.

P2028 is a really quick bookmarklet that will pull the content of a given Phriction document and insert it into the current Phriction edit page's textarea. Hopefully it'll save a few clicks for those of us who write lots of pages with a similar structure.

This is pretty old and doesn't meet the requirements of a modern feature request (notably, clear definition of a root problem). Feel free to file a new request if this is still an issue. Particularly helpful would be discussion of why editing the page to say "Go see <other page>" is insufficient.

(Also, I can't reproduce this.)

Generally there shouldn't bee a "New <object>" on edit object pages. I think this goes away with EditEngine.

I also had the same problem and solved in the same way!...

I'm going to kick this out of the queue for now and we'll reconsider it alongside other internal priorities once the queue clears. I think it's probably secondary to Conpherence now, at least, product-roadmap-wise, maybe?

@epriestley , do you have an example of how one can use 'arc call-conduit phriction.query' ?

In T3353#196761, @chad wrote:

Can you do that today with view and edit policy?

Can you do that today with view and edit policy?

In T3353#179075, @epriestley wrote:

• Text/Phriction Inline Comments: See T1894 for followup. I'll update this shortly in light of T7643.

@chad Can you land this revision yourself, or give me the permissions to do so? I'm currently not able too :-/

thanks!

• Fixed issue pointed out by @chad

hm, ok, that was the reason. I don't checked that, sorry. Feel free to comandeer that rev, and upload a better patch.

Did you click "Submit" and verify the tag you specified was on the document?

At least it did what I wanted, and it worked without an error:
Before:

This shouldn't work, since your changing the variable name as well below, but not above to write the changes. I'd expect this to not record the tag.

Did you try to actually set a project tag with this change? I'm pretty sure it wouldn't work.

This works?

Going to upload a fix myself.

How about subpages? It would be really useful to be able to print out / export an entire hierarchy with one click.

I'm vaguely assuming this should work reading the code for PhrictionDocument.

See T4675#57776 for a local workaround for now.

There's a separate task floating around for making Phirction changes reviewable. I think that should be separate from this task to keep things lightweight.

No! I hadn't noticed it, sorry. I've had a look now and will endeavour to give some specific comments over there later. I don't think the 'addressing comments in multiple updates' will be a problem, though.

Did you check out the mock in Pholio?

It's vaguely possible we could use a bunch of Javascript to try to capture the path that an edit takes and then submit it alongside the new text to track inlines, like Docs/Word do, but without implementing WYSIWYG. I suspect this would still be very complicated.

I've taken a pass at this in the design on Phriction v3, and it's top level comments only. The comment pane by default is hidden, but expandable. You can see comments on previous versions, and pull them up separately. I think this is a reasonable place to start over inline commenting and trying to recreate Dropbox/Quip/Google Docs, etc.

Ok, I'll mock it out.

When you click the pencil icon next to the "Hierarchy" item, you get to a page like this one:

Where is that checkbox?

(I'm hoping there's no real use case for "show some other arbitrary page's navigation", although who knows.)

I'm hoping to get away with two options, e.g. a checkbox like this:

Can I select which page I pull my hierarchy from? I think that works for cases where you want the navigation to be persistent among the children, to just always pull from parent hierarchy.

Yeah -- the specific change I'd expect is basically that this:

So just to understand your point, instead of having pre-selectable layouts, we ship just 1 level by default and anything else is custom?

My intent was to basically port over a customizeable nav list like we already use in AphrontNav everywhere, label, item, spacer, and have that basically editable and re-usable. I want to take a pass at something similar for /home/ so we're looking at all the use cases before building anything.

These use the prose algorithm now, and I don't plan to try to implement syntax highlighting for prose diffs.