I've followed the steps you listed above but am not able to reproduce the issue. Do you have more information you can give us on how to reproduce the bug? Without reproduction steps the upstream cannot move forward.

Usual "here in my machine works fine".
Hereby is screenrecord to convince you
http://srecorder.com/s/3huk
Or just give a joker where to look after for raised flag of locked task or like that.

Thanks, but we really just need the steps to reproduce the issue locally. I don't know them, I have no guesses as to how to get an installation to do that. Without knowing how to reproduce your bug specifically, we have no idea what to look for or if we're fixing the correct bug. This is a huge time burden for us, and is outside what we cover under "free support". We require every bug report to provide these steps for us, since Phabricator is a free product.

You can use a Phacility instance if you want a clean test environment to build a reproduction case. Or we can keep this open a while and see if other installs run into the same bug with more information.

I'll wait Friday stable.... today I've switched from stable to master branch. The install is if I can say untouched and every Friday updated.
Just git pull in 3 dirs and that's all. Use well known bash script for that. All customization and setups are stored in SQL database.
What else steps to report - just pressing New task and appears that.
Is it an option to clean up folder and make clean git clone ?
If tomorrow stable don't resolve that nasty problem will proceed with clean install.

There is definitely a bug here, I just have no idea what configuration of forms leads to it. @epriestley might have other guesses.

I have no idea either. We need reproduction steps. Reinstalling will not resolve this.

Ok, so I have several custom fields in forms such Task or New bug. Could that lead to that de-effect ?

Brand new install on another VM, same Database server - same error. So can assume that the bug comes from data stored in database.

Still facing the problem with Locked task in any new task created. Even on new install. It's database/app config. Please guide where to check about that "locked task" flag BEFORE is created object.

I am seeing this too. I've not confirmed 100% but I think it has to do with Spaces:

1. Create a Space (not the default Space) visible to Project Contractors
2. Create a Maniphest Task Form (/transactions/editengine/maniphest.task/) that is visible to Contractors, set as being Edit Form
3. Create a User that is only a member of Contractors and which does not have access to the default space
4. Log in as the new user and attempt to create a new task using that task form. You will be presented with the "Edit Locked Task" form.

It looks like users can proceed past this by just clicking "Override Task Lock". I've confirmed that adding the user to the default space will also resolve this (but not desired as a workaround).

I'm also running last week's install
libphutil: 24ede7a5dbfd38079c87fc61de64012551965837
arcanist: 822bc53ca306e06314560d8a76f68771d732e8e0
phabricator: 56dd1b297c3e5cdbb477acc7435d6aa5749f33f2

barf

I tried reproducing this on my phacility instance but I couldn't. Additional steps I took to mimic my setup were:

1. Make the Default Space only accessible to a specific group (say, Employees)
2. Make the default Maniphest Task Form visible only to Employees
3. Make the new Contractors task form default to being in the {Contractors} Space, and only visible/editable by Contractors

With this behavior the new user I created could not see the default Create Task form and when I manually navigated to it I got a policy error (expected). I added the Contractor Create Task to the new user's Favorites, and clicking it from there would send me to the proper form.

FWIW I do truly believe we have a bug here, just no idea where. Might be worth adding some logging?

What is the best way to log something to the web server logs? I've been mostly using exceptions but that's proving to be more and more cumbersome.

shh

itsasecret

phlog

sosneaky

i have hosed it?

phlog($var);

should send it to the log

what's your policy on supporting "random" PHP snippets from "sources" into Phabricator code

I only approve "code" from @epriestley

BINGO

The key ingredient is to next set the default View/Edit policy of Maniphest to the Employees group (for Default Space which user is not accessible to)

Thanks @chad for the help and motivation~

Yes, we have several Spaces. But 90% of users are member to default space arranged by Custom policy if understand right report of reproduction bug coming from @cspeckmim.
I'm a user part of all spaces and I'm facing again that Locked task error.
The form for Create Task is common for all Spaces ( Default Create Form·Edit Form ). Default edit policy is only for subscribers.

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.

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.

Nice mate, that's workaround !

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

• In Applications → Maniphest → Configure, set "Default View Policy" to "No One".
• Try to create a task.

I think that's the only bug here.

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

I'm reasonably confident that all the Spaces stuff was a bit of a red herring and only "Default View Policy" actually mattered, but could be mistaken -- let me know if you're still running into problems after upgrading through D17541.

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.

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