Regarding the expected behavior, do you mean it should not be possible for a task to be in both a milestone and subproject simultaneously?

I believe the expected behavior is that "milestone, subproject" kicks the task out of the milestone (leaving it in only the subproject) while "subproject, milestone" kicks it out of the subproject (leaving it in only the milestone).

high priority!

I think it would make a lot of sense to construct the two queries separately (and in parallel) with a short timeout, then handle the timeout gracefully allowing the user to refine their query further. This would avoid the denial of service situation which happened to Wikimedia more than once due to users repeatedly executing really expensive searches until mysql fell over from the load.

And also, there's no edit form below this kind of task:

Presuming this is either resolved by T9893/D17384 or no longer relevant. Follow up on T12450 or file a new task if you're still seeing issues.

I'm going to presume this is approximately resolved.

(In the longer term, the permissions here could probably be cleaned up, but I think that's the cleanest fix without upstream changes.)

You can edit the "Create Form" form and change "Visible To:" to "Members of Project: Doctorate in Form Theory". Then only members of that project will be able to create other forms or edit the form form, I believe.

Enabling that form seems to have done the trick -- thanks! Since it got renamed at some point from "Create form," its existence was almost certainly confusing to some previous admin, which is what got us into this.

I think there is also zero legitimate reason for the form-configuring-form to be editable and this entire workflow essentially represents a trap for the unwary.

If you can't enable that form, you might need to go hunt it down in the database and manually enable it (or tell me what you hit and we'll fix it if it's a bug).

Can you click that link, then "Enable Form"? Or do you get some kind of error?

Works perfectly. Thanks a lot!

I do now see that, but I'm unclear how to use its form to configure the form to configure the form to configure the form from.

A MARVEL OF ACADEMIC PURITY, EDITENGINE PUSHES THE BOUNDARIES OF ADVANCED FORM THEORY TO NEW DEPTHS

DO YOU HAVE ACCESS TO FORMS FOR CONFIGURING FORMS?!

Thanks for you help and I'm sorry the steps I provided are not enough to reproduce my problem. I will gather more information and post soon.

4f9bbb63ae9b was tested on this server. very scientific.

I am not able to reproduce the bug based on the steps you provided above. Do you have more steps or rules in place that I should be following?

Does your webserver error log have a more specific stack trace on the server? I can't reproduce this locally.

Yeah I can't seem to fix this ad hoc. My guess is it's never worked to allow you to skip the first tab. If I fix the error states, it then breaks existing tab panels. So we'd need to build a migration.

I just plan to fix the bug. That's the hard part of a 2-person team with thousands of open issues. Pick and choose the battles.

Actually, this is a little different from what I've been seeing locally. I'm just going to merge this into T11037, which discusses some general improvements to phd status output.

Thinking about this again, what about making this hard-coded numbered list instead a list of draggable items like it's used in Menu Configuration?

Based on like 10 seconds of looking at the code that's where I'd start. 💯

amazing what sleep will accomplish

I think i need to set the inputs with an actual key, not just [], so [$ii]

For me, I often need to click into the link to check if I am a reviewer or a subscriber. It would be nice if I could know who are the reviewers by looking at the email.

We should still be able to handle this case, but I can take a look at what's happening since this is a nonstandard element and the fix is probably easy once I understand what's going on with the logic.

See also T5853 (distinguish between "blocking" and "reviewing" in email) and T10574 (provide more guidance around the pathway toward a revision becoming accepted).

@epriestley as far as I can tell, empty tokenizers do not POST an input to evaluate.

Our users are also missing this, since they can't tell whether they're a blocking/lone reviewer from the e-mail.

Great! Thanks for the report, and for your help confirming the fix. Let us know if you run into anything else.

Checked out that commit and gave it a run. Profile images all generated without errors and I can now reach the front pages of Maniphest and People successfully.

Thanks! That's consistent with 32-bit and I suspect the & 0x7FFFFFFF part of rP9326b4d131ce will fix it.

In T12444#216565, @epriestley wrote:

@deathsyn Can you show me the output of this command on your system to help confirm that there's a 32-bit issue at play here?

$ php -r 'echo PHP_INT_MAX."\n";'

The other bugs I'm more certain are actual bugs, but I'm not totally sure about that one.

(Alternatively, upgrade to rP9326b4d131ce and run the bin/people ... command again and see if that just fixes it.)

@deathsyn Can you show me the output of this command on your system to help confirm that there's a 32-bit issue at play here?

Oh, sorry! I totally missed the bit with italics which described things quite precisely.

After updating the task a million times I did reduce the reproduction steps to just not having the user in the Default View Policy (presumably at time of creation the creator is not in the Subscribers policy group explaining the others' scenarios). I had updated the description to note that but I chould've made that much more clear. Spaces were totally a red herring.

@cspeckmim I think that patch fixes the issue, thanks for hunting down those reproduction steps!

I'm going to fix the bug with these reproduction instructions:

In T12369#216517, @rall0r wrote:

I even get the same error every time creating a new task.
It seems related to Maniphest Policies.
Our Maniphest Policies are:

What solves the problem is setting Default View Policy and Default Edit Policy to All Users.
Hope that helps.

I even get the same error every time creating a new task.
It seems related to Maniphest Policies.
Our Maniphest Policies are:

T12003 is also related to this (providing more explanatory, contextual help for users executing searches which may not be doing what they want for technical reasons).

There's some additional stuff in D17384, where Elastic has an internal hard limit of 10K results.

Thank you for such a quick turnaround! Highly appreciated.

@epriestley If you just add copy in the selection dialog, it will help a lot IMO:

And that's a really great profile image!

Thanks for the extremely thorough bug report. This should be fixed in HEAD of master, and promote to stable within about 72 hours.

I'd guess there is a ...->setContinueOnMissingFields(true)->... missing on an Editor somewhere.

Actually, that fix is completely bogus and there's no inverse edge type so this is perhaps somewhat more involved.

This is probably a one-line fix, but let me repro + get test coverage on it.

So root must always be visible to all?

This is expected:

The root is visible to users only.
We only marked certain docs for public, but they require login.

I can't reproduce this. Phriction is successfully public on this install: