I filed T13687 as a followup for preventing this particular sort of error (where a Phobject is incorrectly serialized directly).

That's very likely the same problem, and I think it should be fixed by updating to the current stable (rPf2a7db1 or newer).

I believe we may be hitting either the problem one of the above commit fixes, or suffering from a similar caused as side-effect from it.

...ideally this sort of thing should fail loudly at serialization time...

the (Show Details) would be a great first step for us - and cover our needs. Much like the logs for Herald Rules and other areas.

There are a few pieces here, since we have to thread the needle through many layers to get where we want to go.

Since this is at least a little bit of actual work, I'm just going to punt until we see an actual user request.

These have existed for a while and recently got support for customizing sub-object behaviors in 2018 Week 50 (Mid December) and are being extended to Projects in 2019 Week 5, so it looks like they're here to stay.

@amckinley, for general context on where I'm headed here:

It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.

I also can't reproduce the original report in the general case: when I type text into the "Create Task" form, click a notification to navigate away, then press "Back", my text is recovered. This is true whether Quicksand is enabled or not.

That wouldn't actually address the original problem here (accidentally setting your computer on fire and losing work) but would address the issue in T12731.

A possible attack on this is via whatever future abuse system we ultimately might build (T10215).

Changing the type is going to run into the issue of what to do about the fields which differ between the two types. Fields which are present in the old type will continue to be displayed unless you clear them when changing types.

Easy changing of a subtype of an existing task would be on my wishlist too. In our worklow it happens fast, that a bug report or a task is tranformed to a story in the next sprint. To edit the subtype in some simple way would greatly help.

How can I change the subtype of an existing task? This only allows me to load tasks into a form specific to their existing subtype. (i.e. I have an animal, I want to edit it and change it into a plant.)

It was a little unclear in the walkthrough you gave on how to use it. Are the field types (animal.type plant.habitat) suppose to be hidden by default on when using a specific subtype (animal.type on plant subtype)?

ok, that was the problem - default values will cause a field to show up in the 'details' section, thanks!

@cos: probably should not have a default value.

ok, so the intent is that any initialized field shows up in details, but no others? If so, then do fields with default values show-up? I have a software version field for example has a default of 0.0.0 and it shows up for subtypes for which it's hidden. Here are some screenshots to show you:

@cos, which specific types of fields are you seeing issues with?

In T12314#217334, @shandor wrote:

The interaction between subtypes and "required" flag was mentioned briefly in the weaknesses section, but it's a little unclear how this new feature will work with them. With Custom Forms, we are currently unable to use Required custom fields properly because they are still required fields even when hidden in some particular forms. Do Task Subtypes solve this issue naturally, or is it something that still needs to be implemented?

The interaction between subtypes and "required" flag was mentioned briefly in the weaknesses section, but it's a little unclear how this new feature will work with them. With Custom Forms, we are currently unable to use Required custom fields properly because they are still required fields even when hidden in some particular forms. Do Task Subtypes solve this issue naturally, or is it something that still needs to be implemented?

I'm now using this and it works well! I've noticed one wrinkle that I don't understand, namely, the 'Details' section when viewing a task includes some custom fields and not others? In particular, it includes custom fields that are hidden for the current task subtype. Is there anyway of controlling what appears 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:

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.

Thanks @chad for the help and motivation~

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)

I only approve "code" from @epriestley

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

should send it to the log

phlog($var);

i have hosed it?

sosneaky

phlog

itsasecret

shh

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.

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

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

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

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.

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.

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