DDoS stuff

This issue stems from a conversation I had with a PI of one of the projects on which we're using Phabricator, and we're about to open the instance to a wider audience (not necessarily general public, but a wider audience nonetheless). His comment was basically, "Disable the upload button for external users." Note, here, that 'external' are still logged-in users, not "public".

I've been slammed with other stuff, so I've not been able to follow up. I'm happy to abandon in favor of D10704.

I think this would satisfy T4226 for me.

I'm still working through my backlog after a long vacation to Iceland, but I'll nuke the cron job I had cleaning out the test directory and see if we still see the behavior.

I might investigate a bit more in a bit, I've just been slammed lately and haven't had much available time to put towards the care and feeding of my phab install.

That would certainly be a step in the right direction.

One advantage of being able to edit diviner documentation in a wiki-style interface/editor is making it much easier to, i guess, create and maintain. For D9100, I had to edit the documentation, generate diviner documentation on a private instance, notice a mistake I made with remark up, generate it again, note another mistake I made, generate it again, etc. That's a pretty high latency cycle, and basically requires that anyone editing diviner documentation either:

Thanks for the feedback - I'll slot some time this afternoon to address.

Is moving to ExternalLinter required to move this forward?

That seems to be the case; secure.phabricator seems a little behind the times.

Updated in light of D9100.

In D9084#22, @joshuaspence wrote:

In D9084#20, @wotte wrote:

I'm not sure that ExternalLinter is entirely apropos in this situation - it ultimately implies far too much structure in the final generated command that might not be appropriate for all script based linters.

What do you mean exactly? The parseLinterOutput method should be able to parse anything that you need to.

I'm not sure that ExternalLinter is entirely apropos in this situation - it ultimately implies far too much structure in the final generated command that might not be appropriate for all script based linters.

Let me figure out extending from ExternalLinter.

Addressed feedback.

Thanks for the feedback. I'll throw up an updated diff hopefully later tonight.

foreach (id(new LiskMigrationIterator(new ManiphestTask())) as $task) {

$id = $task->getID();
echo "Updating task {$id}...\n";

Gracias!

In D8677, @epriestley mentioned a 5 line script to bulk adjust policies - any chance of this being made available and/or made part of the command line tools? I'm planning on making my phab install a bit more public, but would like to make most of the old tasks/revisions only visible within the core team.

How long do you think it will be before we get a feature request to automatically fold/collapse quoted text?

In T4119#38, @chad wrote:

In T4119#37, @chad wrote:

In T4119#36, @chad wrote:

In T4119#35, @chad wrote:

It's worth noting that Phabricator is designed to be very modular, and you can disable any future Harbormaster/Drydock if you so choose. I, for one, rather like @epriestley's eye for design and implementation and look forward to seeing his vision for a CI tool.

Or at least a comment view that captured threading.

@chad being "dum and hating doges" isn't so bad, it is easily falsifiable.

4. I may want to be able to link to, for example, a table (which is not a section title)

The proposed #anchor# syntax might not be ideal, since it rubs up against a lot of similar syntax: #anchor is "project Anchor", ##anchor## is "monospaced text", # anchor is "ordered list item", and # anchor # may be "markdown-style header" at some point.

I haven't looked at the code, but I'd imagine that Phriction itself doesn't currently do a whole lot of parsing of the page content (beyond a diff of the previous content). I'd guess that a much cleaner solution would be to have Phriction parse the page after an update, storing the canonical title in the database for any new pages created. You could also do a couple other nice things, like letting the user know that they have linked to nonexistent pages - perhaps I made a typo in one of my links; there's currently no way to tell this now. It would also be nice to render links to nonexistent pages in a different color (red) so I can tell at a glance which links don't yet exist.

We could produce a link like /test_page/?title=TEST%20PAGE and use the GET title to prefill the title if it's present, but that's a bit funky. A case where it gets messy is if you write [[ TEST PAGE | Some Title ]] -- should we preserve the title, or the link case? What if the user types [[ TEST PAGE | click here ]]?

Aha. Missed that one; I figured I was being dense.

D7842 seems to be an entirely reasonable first step.

Of course, as a counterexample to my previous comment, when you are editing/creating a task/revision/whatever, it might be nice to be able to associate which "unimportant changes" happen as a result of each "important change", in which case @chad has a pretty good point.

It might be useful to create a taxonomy of things that can logically be part of a single transaction, and start the discussion from there.

Ordering events within a single transaction by importance might be a decent compromise, with the comment always being the "least" important.

I'll add that 'importance' in some cases can be somewhat context dependent; having a single "most important" change in each transaction identify the icon for that transaction deprives me of important visual cues for when I'm quickly scrolling through a task looking for certain kinds of changes: instead of looking for instances of a particular icon, I've now got to parse text, which is a lot of mental overhead.

I see what you mean. I think something that would go a long way to fixing the way that last one looks is to align all text that doesn't have an icon with everything that does; text jumping between two different alignments is pretty jarring.

Closed by commit rPff13bb8538a2.

You can build external documentation through Harbormaster, but we probably won't serve it through Phabricator anytime soon. Serving arbitrary HTML content via Phabricator creates a lot of security issues that we'd need to work through.

I'd like to at the very least be able to point to doxygen/other externally generated documentation generated from my own projects. That is, have a Harbormaster (for example) build plan that would run doxygen (or other external tool) on my project and dump the result in some place that Phabricator can serve it up.

The diagnostic reported for Subversion and Git is is far preferable to that which is reported by mercurial.

I've edited the issue based on your feedback. I think T2543 would address 1. If the outcome if T2543 would either a) not match against Herald rules, or b) a new Herald rule was added to match against the status of a revision, T2543 would also solve most of 2.

Aha, yes - this is a confusion issue - I don't recall setting that particular attribute, but may have whilst digging around in the settings. Sorry for the trouble.

It might be nice to be able to specify a canonical "anything.git" that appears in the URL that is presented for the clone.

Ahh, just saw '--plan-changes'. I'll have to play with this to see if it meets my needs.