oh man, at least in Safari they look way better.

I believe Firefox is adopting EmojiOne. If I could CSS style the emojis, it would help. I find them small and hard to identify in text. Basic ones like ❤️ are easy, but all the different emotions are somewhat harder. 😁 vis. 😂 really are hard for me to visually focus on (and on my laptop, which is smaller dpi, is even harder).

Emoji look terrible on nearly every platform / browser

phurl autocomplete might be nice too

All I've learned is:

I will use a completely clean build tonight and reproduce this but the code hasn't changed since 2015.

Offhand, these don't look like current / valid versions of Phabricator. They are out of date and installed from somewhere other than our source. Please see Contributing Bug Reports for what we require in a bug report.

No worries. I was like... weird there is a random task in "Phacility", so I removed one, then I saw like 50 more... and stopped.

I think it's useful to keep track of bugs which impact customers

I tagged this with Phacility because a Phacility customer was the original reporter. I think it's useful to keep track of bugs which impact customers, but maybe I should make a different tag?

I can't reproduce this. It's possible that you actually experienced T11165 and misremembered exactly what you'd done, or performed one edit in a tab with the other tab open.

This is by design, and explained in the documentation.

Good catch ! This is a disturbing behavior for the end user though.

This is documented in the userguide.

Weirdly, another server restart fixed this for me.

OK, it seems utcInstanceEpoch is only used in child event of recurring events according to the code. After I canceled the recurring event(E4), there is no more error in phd log.

I just created a simple test event and the utcInstanceEpoch column is still NULL. What does this column mean?

just FYI, I checked the database and found the utcInstanceEpoch is NULL for some old events, which maybe caused by bug in data migration during upgrade.

T11036 will probably be the next round of changes, but I don't think we have this stuff on any immediate roadmap.

I think it's not perfectly clear in the UI, but we do have it documented:

That's up to you and your team.

In T12144#208351, @chad wrote:

I'd rather fix the core problem if it's an unclear typeahead.

I'd rather fix the core problem if it's an unclear typeahead.

My understanding is that subprojects are basically just regular projects but with a parent relationship. We didn't want these projects to pollute the projects typeahead because no-one should be creating tasks within these subprojects (given that these subprojects dictate what we are working on). By choosing "milestone" instead of "subproject", it becomes clearer in the project typeahead that the subproject is internal to the parent project. That is, if we made #our_january_goal a subproject then it would show up in the projects typeahead as "Our January Goal" whereas as a milestone it is rendered as "Our Team (Our January Goal)".

If the milestones aren't strictly ordered, why did the user create milestones instead of subprojects?

Awesome guys. I can confirm that this resolved the issue.

I think you can unlock yourself using the cli

I deployed this to the Phacility production cluster.

I'm going to merge this into T12142 since that one has an earlier timestamp even though this one is more pure of heart.

In T12143#208308, @chad wrote:

This is fixed on master and stable but hasn't rolled out to Phacility yet.

For the record, this is like the best, clearest bug report I've seen in months. :D

Are you filing this as a Phacility customer?

This is fixed on master and stable but hasn't rolled out to Phacility yet.

Ok I cherry-picked it, way easier than I expected.

I pushed this out to master and @epriestley will probably cherry-pick it to stable today.

Bisects back to D17235

Confirmed, we'll have a fix here shortly and probably cherry-pick to stable.

Erm… I was just asking for time repository update on the repository you have already cloned, hence the 15 seconds. If I understand this correctly, you seem to indicate that it would still be too much. I'm having a hard time understanding, but if you're adamant about this, then there is nothing left to say :)

I can repro on an instance upgraded at 20d1bb8fdf too. And indeed PhabricatorProjectWorkboardProfileMenuItem or PhabricatorProfileMenuItem classes don't contain a validateTransactions method.

I added some log in src/applications/calendar/storage/PhabricatorCalendarEvent.php before line 728 like this:

if ($this->isChildEvent()) {
      $parent = $this->getParentEvent();
      error_log("utc string:".$this->getUTCInstanceEpoch(),3,"/tmp/phadebug.log");
      $instance_datetime = PhutilCalendarAbsoluteDateTime::newFromEpoch(
        $this->getUTCInstanceEpoch());
      $recurrence_id = $instance_datetime->getISO8601();
      $rrule = null;
    }

It indicates $this->getUTCInstanceEpoch() returns empty or null. Any help for this? And I guess it should be related to some recurring events.

If you do find a way to reproduce the bug, please reply back and we'll look into it.

We'd be happy to help you further under Phacility Consulting services. We unfortunately do not take bug reports without reproduction steps or against prototype applications (Calendar).

No idea, I guess this is something related to the Calendar events in my install as you mentioned. I'm wondering if there is some place in the code I can add some lines to log/debug the actual event and the date/time string which caused the error? I can edit the source and run it again.

Thanks! Do you know how we can reproduce the error locally?

I'm still seeing this in the latest code:
phabricator

c63ba8337ec7e7f021f17c972e9a2a751f6280e2 (Sat, Jan 21)

arcanist

9503b941cc02be637d967bb50cfb25f852e071e4 (Sat, Jan 7)

phutil

6d8f5a783ebe7993b78632091507f6d7d8cbc215 (Sat, Jan 21)

Maybe someday this will be easier; https://lists.w3.org/Archives/Public/www-style/2016Mar/0370.html

I'll get back to you

Well

I think the pros and cons are something like:

oh man these crack me up.

Haha, sorry I think this might be a good JS learning side project for me on the weekends if I have free time.

I think we should just use actual emoji for this, not sprite sheets?

In D17238#205025, @epriestley wrote:

Yep, go for it.

If this is a bug report, please see Contributing Bug Reports and fill out all required information. If this is a feature request, please see Contributing Feature Requests. If you need support for your account here on secure, please just use General Chat or contact@phacility.com.

I deployed that change here (secure.phabricator.com). I'll cherry-pick it and deploy it on admin in a little bit, if nothing catches on explosion fire.

Haha, no worries. Uninstalling Home is pretty unusual.

ugh. sorry

After purging dead instances, db003 and db004 are each <25% utilized on their data volumes.

Purging db001 brought primary volume down to 79.2%, which is technically below the 80% caution threshold. It doesn't need to be fixed immediately, but the pathway forward isn't terribly clear. Some options are:

Instance service windows on db003 and db004 have synchronized and the shards are now purging.

The temporary directory storage pressure on repo016 has an unclear root cause (it's related to importing an SVN repository, but I haven't been able to pinpoint where the issue started). The issue no longer appears to be occurring so I'm going to stop digging until it happens again.

The storage pressure on db001 is primarily because an instance imported a large SVN repository with approximately 60M paths. The instance is a free instance with one user.

The db001, db003 and db004 shards have also hit 80% full on their primary volumes. I'm purging dead instances from db001 now. db003 and db004 have never been purged and need to have instance out-of-service dates synchronized first. This is currently underway for db004.

I'm going to move forward with the deploy since this shouldn't impact actual instances, the stuff in this menu isn't super-critical, and workarounds (albeit inconvenient ones) exist to access the items.

And if I gave you a precise estimate you could be sneaky and just divide it by $1,500/hr to get the answer without paying for it!