This task was filed via the "New Bug Report" form.
And also, there's no edit form below this kind of task:
Sat, Mar 25
I'm going to presume this is approximately resolved.
Fri, Mar 24
(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.
@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.
Thu, Mar 23
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.
(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?