Mooooooo

This is vague and may not actually identify a problem; I don't plan to pursue it.

We've closed registration on this install, mooting this.

Dropping these doesn't seem to have caused any major pushback.

This presumably counts as "not much interest" or should move to Discourse now or something, maybe.

This seems to mostly be a matter of taste, and we already have behavior similar to the behavior of git, which seems reasonable.

We don't have reproduction steps for this and thus can't move forward.

This doesn't affect us, but more fuel on the fire -- XSS in example code which ships with PHPMailer (we don't distribute this code):

We appear to have survived this.

Per above, this is not a bug.

No one but me cares.

We kinda did some of this, it can live on in subtasks.

This appears to lack reproduction steps, so we can't move forward.

We aren't going to implement a bin/phd start-missing-daemon command.

What is the network speed of transferring a similar file (e.g., a 400MB file from /dev/urandom) via ssh cat <file>?

Per above, the decision to color the default state is explicit so this is likely just a design tradeoff in the short term. I can test things locally if you want to keep fishing.

There's probably no reason for us to have color: ... on the <select />

While checking again I noticed:

1. Explicitly setting the color: to #000 changes Last-Monday → Mid-April
2. Removing/unchecking the color: in the web inspector doesn't have any effect, it looks like because <select /> elements are inheriting that style in two ways. Removing/unchecking from both definitions/rules will change it Last-Monday → Mid-April

Is this the current status here?

I'm just going to merge this into T10448.

This almost certainly has nothing to do with being invited via a project. I'm just going to merge this into T10448, which will moot it.

I suspect this is actually more like: actions on Ponder answers are not covered by the "Ponder Questions" email preferences, because a "Ponder Answer" is not the same type of object as a "Ponder Question".

A possibly exceptional case here is users who unsubscribe themselves. We could wait for complaints or special case that.

This would be great. For example, in a Xcode project I could create packages for translators/localizers for any path containing *.lproj/

Seems better to pursue this as an CustomField extension. https://secure.phabricator.com/book/phabricator/article/custom_fields/

I think it should be possible to backfill this from the transaction record, but definitely a bit involved. Holding it until we do history (and major/minor versions) makes sense.

Per T12933, we never correctly implemented versioning, which is fix, but not backfilled. If we present a "history" view like Phriction, we'll need to do this.

Closing for now, it's reasonable to post populate the table if we do decide we need the information. I'll note it on T5505

No worries, and appreciate the help.

Fair enough; I'll stop bothering you now. D18280 looks good to me.

I don't know and I've spent way too much time here already.

In T12933#230136, @chad wrote:

I see no way of reconstructing the rows.

I see no way of reconstructing the rows. It appears versioning never worked (and nor do we surface it anywhere). We can add a migration to fix the current times though.

I may be mistaken, but it seems to me that D18280 will fix the problem only for new edits, made after that revision is applied. Is that right?

Seems a reasonable place to start. I'll look at this soon.

In T12933#230063, @epriestley wrote:

The creation date and modification date of a body should always be the same, like they are for a Phriction document body.

There's also bin/mail receive-test but that only accepts mail --to an existing object, not a random email address, right now. We could make that more flexible to make testing a little easier (raw_mail.txt must be a full piece of mail with proper headers and encoding, but bin/mail receive-test accepts just the plain text of a body and simulates all the headers/encoding/envelope stuff).

Something like:

I think I have a fix but can't find the command line trick you showed me to test it.

@hach-que, did you end up implementing a solution for this?

In case it helps: I think D13982 introduced the code being edited by D18253. But it sounds like some other code isn't behaving the way you were expecting it would.

I think you're innocent and that it never worked but I only looked at it for like 2 minutes.

I should be able to bisect this if I brokened it.

There may be a bug with the body versioning (maybe it got broken by accident when we swapped to ModularTransactions, or maybe it never worked), but if there is we should fix that bug. The creation date and modification date of a body should always be the same, like they are for a Phriction document body.

ok, that explains the Versions field - it appears only to increase when updating the Body and not the Preamble.

The create and modified dates are supposed to be identical, since each edit creates a new copy.

Maybe I'll put it on A, I guess ("Toggle All"), so it's sort of near q, which is similar (collapse/expand).

Toggle each individual comment's visibility to the opposite but only if it's not for the current diff~

If it's a toggle, what do you expect us to do if you press it with some inlines hidden and others visible?

Is there opportunity for a hotkey to hide/show all inline comments? Or since it's accessible from the topbar is the intent not to add hotkeys?