Presumably resolved.

Nice, I like that.

I think invitees are complex enough that we probably don't want to use edges to store them. Edges are good for simple relationships (like a user subscribing to an object) but not as good for more complex relationships. Invitees are likely to have a lot of state eventually (required/optional, invited/attending/declined, maybe annotations like "Speaker" for a talk, "Co-Host" for a party, or "Bringing Salad" vs "Bringing Desert" for a potluck, maybe tracking who invited you, and so on).

From elsewhere, I think it's so that they're visible in dialogs (like "Edit Task" from a workboard with a custom date field).

Yeah, this should be fixed at HEAD for most workflows, see:

escalate from that to any other account

Are you at HEAD?

No -- you point Phabricator at the new LDAP server by using a compromised administrative account and going to Auth → LDAP and changing ldap.mycompany.com to ldap.evil.com.

Yep, thanks!

See T4213 for discussion of themes/skinning, and an explanation of why we don't expose CSS/HTML as an API.

I think our use cases are pretty much the same, the documents are just laid out a bit differently.

I do think the weight and blackness of the subheadings can overwhelm headings a bit, for instance on the Changelog:

Not sure this is fixed yet.

Example working hgrc:

I think hg branches just picks one head to show when there are multiple heads of a branch. For example, if you're on rev 9 and hg up 8, then make a commit (creating a second local branch head for default), the hg branches command still shows only one head, even though your working copy has multiple open heads of the branch.

I'm guessing hg heads -c will also show them.

Does hg log --rev 'head()' give you the other heads?

I think this is in mostly reasonable shape now, but let us know if there are still issues.

We can eventually add some sort of temporary preferences for logged-out users to make this sticky for them.

I made that explicit in T7955, although we probably need to let you name events (T7953) first or the stories are going to be pretty iffy.

ApplicationTransactions is the infrastructure component which creates edit logs, supports comments, and enables a lot of additional features for free or nearly-free. The major components are:

• Create a new autopatch similar to resources/sql/autopatches/20141104.almanac.3.edge.sql to add the edge tables to Calendar.
• Create a PhabricatorCalendarSchemaSpec similar to AlmanacSchemaSpec so Phabricator knows the table is supposed to exist.

Here are some pointers on approaching this:

Most of this is blocked by T5464, which is large and complex. A reasonable implementation path which might make sense overall while letting you ease into things without tackling T5464 right away is:

It should setDisabled() + setWorkflow(); the former will grey it out (T7507 already had that part). Overall behavior should be the same.

See T7447.

@asteinlein, this is the task for porting comments across diffs.