OData structural properties configuration bug

[ChrisB]

Hello,

Windchill version:

Release: 11.1 M020-CPS22
windchill 2.2.2 REST Services

There seems t.b. a bug that makes properties in OData non-filterable when adding a separate configuration for them. Below are the steps to reproduce this issue:

1. We added a random string property to the `Parts` type called `RESTTEST`

   (The property is filterable)

2. We added a custom parts extension configuration as described on p.84 of the Windchill REST

     Services  2.5 User’s Guide having the following content:

Path:

[ROOT]\Windchill_11.1\Windchill\codebase\rest\custom\domain\ProdMgmt\v5\entity\PartsExt.json

Content of config file:

{
    "extends": "Part",
    "attributes":
    [
        {
            "name": "RESTTEST",
            "internalName": "RESTTEST",
            "type": "String",
            "readOnly": false,
            "nonFilterable": false
        }
    ]
}

As can be seen above, both `readOnly` and `nonFilterable` are set to `false`.

3. After having done this, the property becomes non-filterable, despite the configuration stating otherwise. This can be seen when querying the $metadata of the ProdMgmt domain:

<Annotation Term="Org.OData.Capabilities.V1.FilterRestrictions">
    <Record>
        <PropertyValue Property="NonFilterableProperties">
            <Collection>
                <PropertyPath>VersionID</PropertyPath>
                <PropertyPath>ChangeStatus</PropertyPath>
                <PropertyPath>ShareStatus</PropertyPath>
                <PropertyPath>CheckoutState</PropertyPath>
                <PropertyPath>View</PropertyPath>
                ....
                ..
                .
                <PropertyPath>RESTTEST</PropertyPath>
                ....
                ..
                .
                <PropertyPath>CLASSBINDING</PropertyPath>
            </Collection>
        </PropertyValue>
    </Record>
</Annotation>

This seems to be a bug which we haven't found a workaround for, unfortunately. However, we need to add such a mapping for a different porperty to make them writable via the API (since they are attributes stemming from the PartMaster).

Is there a fix for this or some sort of configuration that can circumvent the problem?

Because right now we have the option for attributes from the PartMaster to be

- either searchable

- or writable

but not both.

This is quite a serious issue for us so for ONCE I am asking some PTC folk for an answer, since hardly anyone seems to be able to answer any questions regarding the OData interfaces.

Cheers & thanks a lot in advance

Chris

PS: Why is there no "OData" label for Posts??

[HelesicPetr]

Hi, 

what about to separate the domain. One for filtering one for writing ? 

So you would have just one config for one domain. 

PetrH

[ChrisB]

Hello Petr,

Thank you for taking the time to answer.

While this might be a possibility, the company I work for currently discourages any further customization of the OData configuration. Furthermore, this could have a negative impact on or existing software that uses the OData API.

Anyway, this doesn't change the fact that adding a property to `PartsExt.json` creates an entry in the `NonFilterable` properties. This smells kind of buggy to me.

Cheers,

Chris