Are custom_fields on posts/topics available via the API?

AI-generated summary

The discussion revolves around the availability of custom fields on posts and topics via the Discourse API. Initially, cappslock and jgujgu asked if custom fields can be accessed, set, and queried through the API. Falco clarified that custom fields are possible for topics, categories, users, and posts, and can be handled in plugins.

Later, bletch resurrected the thread, stating that custom fields are not available via the API, based on their experience with the Ruby API gem. However, angus provided an example of posting events plugin events via the API, which led to a solution for bletch. The solution involved using the raw client’s post method to create a topic with custom fields, rather than the create_topic method.

In summary, custom fields can be accessed and set through the API, but it requires using the raw client’s post method and passing the custom fields as part of the request arguments.

I see from some digging that a custom_fields property exists on posts/topics and plugins make extensive use of it.

Is this field available through the API? Can it be set? Can it be queried against? Could a search be made for a topic with a certain value for a custom field?

I have this exact same question. All the dialogue I see is about custom fields for users, not a general discussion :confused:

Custom Fields are possible for topics, categories, users and posts.

Users are the common case, and can be created from the Admin UI and filled in user preferences.

All types can be handled in plugins, created, modified and read.

Using a custom field would be:

  • Creating the field in the plugin.rb
  • Adding it to some serializer so it’s avaliable for the front-end code
  • Using it in a handlebars template

Many plugins use this fields like:

@Falco thank you for the clarification. I will look to these plugins as examples.

I finally found what I was looking for… register_custom_field_type(). Prior to seeing this, I was rather confused on how the database handled the type information. Well, now I know :smiley:

@Falco a belated thanks for the link to the Signatures plugin. Not only do I wholeheartedly approve of old-style forum signatures, but it’s a great example of putting user custom fields to work for this new Discourse developer.

Sorry for resurrecting an old thread, but I haven’t been able to answer this question by searching meta.

Are custom_fields available on post/topics via the API?

In the answer above, @Falco talks about how custom_fields are available to the plugin developer, but I see no definitive answer to the question in the topic title. My own experience suggests that they are NOT available via the API.

I’m developing in Ruby with the Ruby API gem but can’t seem to pass a custom_field value like others. My Ruby code is standalone so I can’t just use the Rails infrastructure to access custom_fields.

From memory, when I developed my migration script from MVCF, the custom_fields have to be added to an already existing parent. i.e. the parent is re-found, custom_fields added and the parent re-saved. I can see why that might not be straightforward with the API.

I need to pass custom_fields to categories and to topics (for the Events plugin) is it impossible or am I missing a trick?

Any help gratefully received.

You can post events plugin events via the API. There’s an example here:

You, sir, are a gent of the highest order!

It’s working now.

For fellow travellers, it seems that you can’t use the Ruby API gem’s create_topic method…

client.create_topic(...)

…as it looks like the API only passes known fields through.

Instead, I had to use the raw client’s post method, like so:

args = {
  title: title,
  raw: content,
  category: child_category["id"],
  event: {
    "start" => event_start.to_s,
    "end" => event_end.to_s
  }
}
new_topic = client.post("/posts", args.to_h)

EDIT: I can live with not being able to set the settings for the event plugin at the category level as that is pretty much a one-time thing.

PS, @angus, why did it take you 24 minutes to respond - I expect better service that than! *

* for the avoidance of doubt, this is dripping with British sarcasm and irony.

:slight_smile: