[BUG] CategoryID not handled in ETQueryDefinition

[GDU-SF]

Describe the bug
When doing ETQueryDefinition.Get(), the CategoryID is always equal to 0, even when specified in the properties to retrieve.
When doing ETQueryDefinition.Post() and specifying a valid CategoryID, the Query is always created in the root folder ("Query")

To Reproduce
Get a Query definition specifying to retrieve the CategoryID.
Create Query definition in a specific folder/category.

Expected behavior
ETQueryDefinition.Get() : The CategoryID should be populate with the correct value when specified in the properties
ETQueryDefinition.Post() : The query should be created in the specified folder/category.

Code snippet
For ETQueryDefinition.Get()

var log=""
var SFMC_Client = new ETClient();

var QueryGet = new FuelSDK.ETQueryDefinition
{
   AuthStub = SFMC_Client,
   SearchFilter = new SimpleFilterPart { Property = "Name", SimpleOperator = SimpleOperators.equals, Value = new string[] { "MyQueryTest"} },
   Props = new string[] { "Name", "ObjectID", "CustomerKey","Description", "CategoryID", "QueryText", "DataExtensionTarget.Name", "DataExtensionTarget.CustomerKey", "TargetUpdateType" } 

};

/// To get the result 
ETQueryDefinition Query = new ETQueryDefinition();

try
{
   var response = QueryGet.Get();
   if (response.Results.Length > 0)
   {
       Query = (ETQueryDefinition)response.Results[0];
       /// Here Query.CategoryID is == 0 
       ...
   }
}
catch (Exception ex)
{
   /// log
}
...

Note: Because the developers need to copy and paste the code snippet, including a code snippet as a media file (e.g. gif) is not sufficient.

Environment

• SDK Version 1.2.1
• .NET Framework version 4.5

The bug has the severity

• Critical: The defect affects critical functionality or critical data. It does not have a workaround.
• Major: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult.
• [X] Minor: The defect affects minor functionality or non-critical data. It has an easy workaround. But no easy workaround
• Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience.

[barokzi]

Hi, like you noticed, I had this issue a while back. I did not really have a work around at retrieving the Category ID (folder id) for ETQueryDefinition objects, so my work-around was not needing it for the GET(). Instead in my app, I would know which folder I am retrieving ETQueryDefinition objects for (meaning, for searches, i had to traverse the folders and search each one).

Curious, though, and at the moment I can't recall if I tried it, have you tried doing a ETQueryDefinition retrieve request via PostMan and does it the request actuall return the Category_ID for ETQueryDefinitions? The point is I could not recall if this omission is just in the SDK or if its in the SOAP/REST API itself.

[GDU-SF]

Thanks for the follow up @barokzi. I did test direct API via Postman and the CategoryID is retrieved correctly there, so it just a SDK issue I think.
API call result:
<Results xsi:type="QueryDefinition"> <PartnerKey xsi:nil="true" /> <ObjectID>xxx</ObjectID> <CustomerKey>xxx</CustomerKey> <Name>MyQueryTest</Name> **<CategoryID>282230</CategoryID>** </Results>
I tried to explore a bit the classes but could not find the file with the definition for QueryDefinition (only ETQueryDefinition), so hit a dead-end here as well...