This would also be useful for the Audit dashboard, e.g. to build the query "what audits am I responsible for that I didn't author?" (given that the viewer belongs to a project which is responsible for auditing the commit).

From downstream, MariaDB has a fairly severe bug when indexing tokens with length greater than 127 bytes:

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.

I don't think we'd conflict? Nothing I'm doing is in MenuItem (all that stuff is wired). I'm just deleting code.

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?

Oh, I guess you could pre-patch me with projects then

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/).

proooobably projects too

I hadn't considered building dashboard routes into /home/ but that seems pretty simple.

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.

Yeah, this is just polish to me, though it makes dashboards I think way more useful (and likely what I'll want to fix the UX of next).

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.

On here I've added a personal dashboard called "home", if I click it I go to dashboard/view/1/, and I don't stay on home. Maybe I implemented the dashboard menu item wrong?

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.

Do we actually need this? Dashboards already load nothing since all the individual panels are ajaxed -- and even less with Quicksand -- and there's no state to preserve? What's the goal?

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?

I probably did something dumb when changing over from master to stable (I'm the only one that administers this instance and I know we've never modified phab's source). I should be good to go on the version front now?

I think I have most of this working, but there will be some follow ups needed I'll need help with:

🐈

I'm cleaning up Project/Profile UI with the nav changes, I'll just pop a tag in for Roles.

For anyone who discovers this task, the issue appears to be related to the SimpleXML PHP library. This must be installed and enabled for the system PHP. Ubuntu 16.04LTS includes PHP7.0, so if you do any magic to run PHP7.1 or PHP5.6, your system php will not match what is running on phabricator.

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.

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.

I'd probably want to fix this at the source, not the Profile Page. I think if you have to get this information from the Profile Page, we've let you down in the UI elsewhere.

I'm now running on the following after performing last week's upgrade.

Yeah, I think I screwed something up when I switched from master to stable. After following the merge commits all the way down I ran into this commit:

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

Ah woops, looks like I searched for the wrong variable for InnoDB fulltext support:

Thanks for looking further into this @epriestley and sorry for the less than ideal bug report. Please feel free to re-title/merge/close as you see fit.

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.

When I ran into this issue, I was attempting to automatically file tasks when my application encountered some unknown exception/error. I didn't want to file duplicate tasks for the same errors, so I was first going to look up the task name that followed some standard format like Error: <file> <line> .... I was testing with the string This is a test and was confused whythe conduit maniphest.search endpoint was not returning any results, but I could lookup other task names fine.

What for is "audit.can-author-close-audit" then?

You may be able to use Projects or Owners to create groups. Any member of a Project or Package auditor can accept on behalf of the project or package.

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

Standard workflow is:

• Herald adds a group of people responsible for the audit to every commit.
• An Auditor picks several commits (he has to remove the group and add himself as Auditor, so no other auditors pick the same commit at the same time)
• Then Auditor accepts a commit or raises a concern.
• When the concern is raised, the Author prepares a new commit fixing this concern with commit message "Depends on ..."
• Then the Author has to go to the Phabricator and change the state to "Needs Verification"; also he should assign this fixing commit to the same Auditor (unfortunately, I don't know how to do this automatically, via commit message or Herald).
• Now the Auditor can see both commits and can accept them.

Can you describe how audit works in your organization and why you want authors to be able to close audits after T2393?

It also sounds like the problem is caused - at least partly - by an external product: GitHub listing all tags as Releases. Have you tried solving this from that end?

I think the problem you are describing has been already reported here. The users who reported it use a script to remove old tags. So you can do that.

I just tried using a different repo as a staging area (as suggested in the User Guide), and now my CircleCI builds are linked to the wrong repo (ci-staging-area instead of material-motion-js).

If you just have question as to why Phabricator works a certain way, see Support Resources, specifically Ponder and Conpherence General Chat are better places to ask these questions.

Maybe I missing something, but you mention reading the documentation but not heading its advice? If that's the case, I don't understand what this feature request is actually for.

I did read that: I thought I'd stated a root problem.

Please read Contributing Feature Requests and be sure to follow the guidelines there. Unfortunately we're not able to take feature requests that don't state a root problem.

Do you have reproduction steps that are not hypothetical? I assume you actually ran into this as a bug, so knowing the specifics is important here.

@epriestley you don't want to know what schools teach/accept now-adays... is very scary.

My first internship I was tasked with working on an application as sole developer. It started at 8.6k lines in a Main.cs file and at the end of the summer I left with it at about 15.5k. Luckily we didn't do code reviews.

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.

Yes, your email explains the real behavior under the hood. I filed this task from the perspective of what it looks to the user, not from the engineering implementation perspective. Feel free to change title / description of course.

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?

A short comment now. Thank you for the very detailed reply.

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.

In T5000#176440, @epriestley wrote:

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

Okay, we will try to upgrade phabricator in our next weekly maintenance window tomorrow, I'll update you with our result later

hmm everything seems in order