Nested advanced tags groups not working with adv_tag_group.get_all_tag_groups

[davey242]

When using: adv_tag_group.get_all_tag_groups(server,"") this returns root groups.

adv_tag_group.get_all_tag_groups(server,".group1") this returns root groups.

adv_tag_group.get_all_tag_groups(server,".group1.") this returns group1 groups.

adv_tag_group.get_all_tag_groups(server,".group1.group2") this returns group1 groups

adv_tag_group.get_all_tag_groups(server,".group1.group2.") this returns group1 groups

Not way to get groups in group2 (eg group3) or link_tags in 'group1.group2.group3

[rlabbeptc]

Hi @davey242 , thanks for sharing. I'll have some time later this week to investigate. But could you verify something for me?

The group paths you are sharing above start with a "." and wouldn't be expected. This could be causing the parsing to fail (which isn't good). Could you just rerun the checks you were doing without the leading "."?

Thanks!

[davey242]

With the path as 'group1', it returns the root group. With the path as '.group1' it returns the groups in group1

If there are multiple groups like 'group1.group2', with leading '.', it get http error 404: not found

I have it working now with path '.group1.group2' to return the groups in group2 by changing isItem to false in adv_tag_group.py line 163 (path_obj = for def get_all_tag_groups)

[rlabbeptc]

Thanks. Clearly and issue going on and that isn't my expectation. I'll take a look this week and let you know what I find to resolve it.

[rlabbeptc]

Ok, now that I relooked at the documentation, the issue is that you need to lead with "_advancedtags" to mimic the full qualifies namespace path. Details here in the documentation.

Any path reference the SDK uses for a specific object typically mimics the reference that you would use as a "client". You can see below as a quick example.

So adding _advancedtags to the beginning of all the references is the expected input. I will look to add some additional validation handling to reduce the errors that could happen when not properly addressing the Advanced Tags path. Starting with a "." does work because it still prepopulates the _advancedtags during the path parsing routine.

Would it be easier to have the option to not need to use _advancedtags as the root of the paths? I would consider having separate handlers for either use case. Feedback about that would be great!

The lower nested folders were failing "group2" and "group3" use cases above. I found that issue and can release an update. But would love your feedback on the question above first.

Let me know your thoughts. Draft PR is #45 so you can take a look at it and test if you'd like.

[davey242]

changing isItem to false in adv_tag_group.py line 163 (path_obj = for def get_all_tag_groups) solved the issue for me.

To access any group, you can use with either '_advancedTags.group' or '.group'

At the end of the day, it does not matter to me if there was an option to use with or without _advancedTags as it already does.
If you choose to change the logic to force _advancedTags to be used, that is fine also. I will just update my logic

Thank you

[rlabbeptc]

Thanks @davey242 . I will plan to add validation to ensure that the '_advancedTags' is always included. That is the expected behavior and would stick with the paradigm that the rest of the package uses.

You'll receive a KepError exception indicating that the path isn't correctly formatted.

Appreciate the feedback.