From downstream, MariaDB has a fairly severe bug when indexing tokens with length greater than 127 bytes:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 26 2017
I have discovered that we already have PhabricatorDashboardProfileMenuItem.
Yeah, you should be good now. I'll look into the JS thing since we like money.
Oh! I thought that mock was a screenshot and that "Home" was a new DashboardMenuItem. No conflicts, I'll shoot you a diff in a bit.
Yeah, but since you already wrote DashboardMenuItem we'd conflict -- do you want to just diff that separately now, then I'll fancy-it-up and it should integrate cleanly?
We shouldn't need to build a route into the applications separately -- getProfileMenuRouting() already adds a route (from the code, I guess the actual route is /home/item/view/123/).
Yeah, fully agreed that we should stay in Home in terms of the nav menu, crumbs (none on Home, but relevant for Projects), checking application permissions, etc. I just got scared off by "AJAX", since I think the non-ajax thing will take me 20 minutes and an Ajax version would take me 20000 minutes.
If you just want to diff that when it's ready I can implement the fancier version to get the dashboard rendering on the same page. Looking at the code, it's not quite as simple as I remembered -- I thought we had some similar panels already, but all the stuff we have is more hard-coded than I thought.
I mean if you're on home, and you have 3 dashboards, that you don't leave home. I think we talked about this before and you said that was simple.
That is, the rule the menu already uses is already "show the item the user has explicitly selected as the default item, or the first item which they could select as a default, if they haven't selected one yet". This is what lets you pick projects to default to the workboard or project profile, but causes them to default to the project profile.
Selecting first dashboard as homepage. I think I can just query the menu itself in MainController and pull it out? Use built in home if nothing returned?
🐈
Downstream, @20after4 calls out that mentioning disabled users in comments still subscribes them, as though they were normal users. This behavior would be easy to change, but I could sort of go either way on it.
# git show 2dad469 commit 2dad469eca22e344e6e35d7560e822a107aa318e Author: epriestley <git@epriestley.com> Date: Mon Jun 22 11:47:58 2015 -0700
I think we have some discussion of this somewhere, although I don't immediately recall where and it's not in the obvious places. I might be conflating discussion of the recently-reworked "Available" status.
Ah, that's probably from an earlier git pull. Each of those merges have two parents, like this in the most recent output:
I'm not entirely sure what I did here to screw that up.
According to that test, your server does not support InnoDB fulltext, so what you're seeing is expected: we keep the tables with FULLTEXT indexes on MyISAM if innodb_ft_max_token_size is not a defined system variable.
It looks like my server supports InnoDB fulltext search
I don't think this is a stemming problem. Note that we MATCH(corpus, stemmedCorpus) against the query, so we're actually searching in the text "this is a test thi test". I wrote stemming so that it should never match fewer documents than an unstemmed query would -- definitely possible I got something wrong, but that's the intent, at least: stemming only gives you more hits.
I can get around this by just hashing some unique string that makes up the error and dumping that into the task description and search off of that since full-text searching for single strings works as expected.
What for is "audit.can-author-close-audit" then?
You could also add a condition like this to your rules which trigger audits:
he has to remove the group and add himself as Auditor
Can you describe how audit works in your organization and why you want authors to be able to close audits after T2393?
Jan 25 2017
After D17252, audits now have a "Request Verification" action and a "Needs Verification" state. These states prompt auditors to verify the remedies the author has offered have addressed their concerns. Intended usage is along these lines:
I'm going to merge this into T2393, where I'll discuss this shortly.
I filed this task from the perspective of what it looks to the user, not from the engineering implementation perspective.
Does my email about refs/pull/68/head explain this behavior?
Is there some scenario which can trigger both bindings in a host group to be brought online?
What possible use case could anyone ever have for putting a THOUSAND lines of source code in a single file?!!
Without actually reproducing this or looking at the code, I believe this isn't a bug. You're expecting Drydock to choose particular allocation strategies:
No easy way to apply a policy to a group of repos.
He's so little. :)
Poor 🐈.
I guess I don't even have a glyph for :lion_face: anyway.
Also while you're in there maybe replace _ with (space) in the strings? I can't find :lion_face: by typing :fac... right now, but I think if you swap the underscores for spaces it will work. Then :cat should be able to find crying_cat_face and stuff, too.
not memorizing emoji collation order in 2017 pfft
The list is sorted by emoji. 🐈 is "alphabetically" earlier than 🐱 in the list of emoji.
Jan 24 2017
D17242 should fix this, thanks for the report!
There's now a grayed out page
your phutil is 3 weeks older than the rest
Should I open a new bug?
Jan 23 2017
Phrequent is a prototype. We do not accept feature requests for prototypes, see User Guide: Prototype Applications.
This is exceptionally rare, strictly user error (i.e., avoidable by entering your email address correctly), and administrators can force-verify email addresses with bin/accountadmin which offers one way out of this state.
This is what I see on my Macbook in Safari:
Emoji look terrible on nearly every platform / browser
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.
Jan 22 2017
If the milestones aren't strictly ordered, why did the user create milestones instead of subprojects?
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.
Jan 21 2017
I think the pros and cons are something like:
I think we should just use actual emoji for this, not sprite sheets?
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.
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.