You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Help Center articles have a (mutable & optional) 'content_tag_ids' field
The documentation says that the field contains 'The list of content tags attached to the article'
This field is not currently exposed in the Article model & so cannot be read/written
Feature request is to add it to the model.
Additional context
N.B. a potential risk of adding a new field to the model seems to be that any existing code using the client that was doing a overwrite of an existing article (by calling Zendesk.updateArticle(article) (without having recently read the article in question from the API, or where the Article instance has been created by copying a known set of fields from another Article instance) would have been preserving any pre-existing content_tags_id value on the article.
But if we add the field to the model, then any code like this will now be updating the content_tags_id field to be empty
This edge-case change in behaviour seems worthwhile, but may be worth documenting in release notes.
I'm building a PR for this issue & will submit it shortly
The text was updated successfully, but these errors were encountered:
andy-may-at
changed the title
Support getting/setting of Help Center article's content_type_ids field
Support getting/setting of Help Center article's content_tag_ids field
Mar 8, 2023
Help Center articles have a (mutable & optional) 'content_tag_ids' field
The documentation says that the field contains 'The list of content tags attached to the article'
This field is not currently exposed in the Article model & so cannot be read/written
Feature request is to add it to the model.
Additional context
N.B. a potential risk of adding a new field to the model seems to be that any existing code using the client that was doing a overwrite of an existing article (by calling
Zendesk.updateArticle(article)
(without having recently read the article in question from the API, or where the Article instance has been created by copying a known set of fields from another Article instance) would have been preserving any pre-existing content_tags_id value on the article.But if we add the field to the model, then any code like this will now be updating the content_tags_id field to be empty
This edge-case change in behaviour seems worthwhile, but may be worth documenting in release notes.
I'm building a PR for this issue & will submit it shortly
The text was updated successfully, but these errors were encountered: