Skip to content

Fix 'ownAttrib' not always returned with 'own_attributes' - #370

Open
iLLiCiTiT wants to merge 1 commit into
developfrom
bugfix/own-attributes
Open

iLLiCiTiT wants to merge 1 commit into
developfrom
bugfix/own-attributes

Conversation

@iLLiCiTiT

Copy link
Copy Markdown
Member

Changelog Description

Entities queried with own_attributes=True always contain ownAttrib as a dictionary with attribute values.

Additional info

ownAttrib was missing, or was a list of attribute names instead of a dictionary, in these cases:

Call with own_attributes=True Before After
get_tasks(project_name) (default fields) missing dict
get_tasks_by_folder_paths(...) missing dict
get_tasks_by_folder_paths(..., fields=...) list dict
get_folders(project_name, fields={"id"}) list dict
get_projects(fields={"name"}) missing dict

Causes:

  • get_tasks called _prepare_fields with own_attributes only when fields were passed.
  • get_tasks_by_folder_paths did not pass own_attributes to get_tasks.
  • For folders and tasks, ownAttrib was queried without attribute values, so it could not be converted.
  • Projects with only REST list fields used the REST projects list, which has no attributes.
  • fill_own_attribs skipped entities with empty attrib.

Testing notes:

  1. Call the functions from the table above with own_attributes=True.
  2. ownAttrib is a dictionary with all attribute names, with None for values that are not set on the entity.
  3. Calls without own_attributes don't return ownAttrib, as before.

- 'get_tasks' and 'get_folders' prepare fields also when default fields
  are used, so 'ownAttrib' is queried.
- 'get_tasks_by_folder_paths' passes 'own_attributes' to 'get_tasks'.
- Attribute values are queried for folders and tasks when own attributes
  are requested, otherwise 'ownAttrib' stayed a list of names.
- 'get_project' and 'get_projects' query attributes when own attributes
  are requested, so the REST projects list is not used.
- 'fill_own_attribs' handles empty 'attrib'.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@iLLiCiTiT iLLiCiTiT self-assigned this Oct 20, 2026
@iLLiCiTiT iLLiCiTiT added the type: bug Something isn't working label Oct 20, 2026
@kalisp

kalisp commented Oct 20, 2026 •

Copy link
Copy Markdown
Member

I am not sure that ownAttrib should be dictionary of all keys with None for unset, ie. inherited attributes.

We already have dictionary of attrib, which contain resolved values.

At least it is not too similar with graphQL

image

If I would be expecting dict, I would expect to contain only 'real' entity attribute overrides.

@kalisp

kalisp commented Oct 20, 2026 •

Copy link
Copy Markdown
Member

I don't understand this:

image

(I am getting some weird exploded dict for get_tasks_by_folder_paths {'/': [], '0': [], '2': [], 'h': [], 'o': [], 's': [], 't': []})

@iLLiCiTiT

Copy link
Copy Markdown
Member Author

I don't understand this:

You're passing str as argument which expect Iterable[str].

@kalisp

kalisp commented Oct 20, 2026

Copy link
Copy Markdown
Member

I don't understand this:

You're passing str as argument which expect Iterable[str].

God damn it, skill issue. Stupid IDE. Srry.

@iLLiCiTiT

iLLiCiTiT commented Oct 20, 2026 •

Copy link
Copy Markdown
Member Author

If I would be expecting dict, I would expect to contain only 'real' entity attribute overrides.

That's been there since beginning, not a new thing. The idea is that you'll get exactly what attrib contains but the values are None if are not explicitly set on the entity, which is more practical for real world usage (but pointless for graphql).

entity = ....
own_attrib = entity["ownAttrib"]
if own_attrib["frameStart"] is None:
    ... do some stuff

The reality is that you do care about own attrib when you are handling hierarchy, and in that case it is better to have already in place dictionary with "real entity values" instead of dictionary and list of strings you have to combine to get it.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants