Custom fields used to be sent into the review as a dictionary with a string key and a string value. Now we instead update the schema and you send in your custom field data as you would any core field data. This change was needed to support field types that consist of multiple subfields. We also get the added benefit of having the GraphQL layer help with data integrity.
The old custom fields format is still supported for backward compatibility over a transition period.
We already had the automatic translation of text in Tycka, but it was limited to a few core fields. This has been a great way to get end customers to get value out of reviews that they wouldn't otherwise have understood the content from. Now this translation can be applied to custom fields in form of the Translated text field type. The text that reviewers leave in these fields, will be translated to the languages configured on the account following the normal translation flow.
We realized that by having a rating, title, and content as core fields, we were unnecessarily limiting you from having it your way. Nowhere in the review collection rule book is it stated that all reviews need to have all of these fields. Therefore we turned rating into a field like any other and the rating on a review that gets published is the average of all the rating fields that existing on that review. This also enabled us to have sub ratings
The rating field type consists of a value (a decimal number, between 0.0 and 1.0) and an optional comment (string, up to 5000 chars).
Reviews that want to have a title, should add it as a custom field of type translated text.
This replaces the use of the Rating and Content fields on reviews. We still support the legacy rating, title, and body.
Before this change, we only had one search field for reviews. We quickly identified contrasting use cases, one where being able to do large amounts of reads was more important than up-to-date data, and one where up-to-date data was more important than support for large amounts of reads.
After trying to figure out how to cover both these requirements in a reviews search, we came to the realization that it would be better to have two separate search endpoints. One that is public and optimized for huge amounts of reads. And another private one (authentication needed) and optimization for having the updated data as soon as it happened. Having the private search also gave us the benefit of being able to store more data in that index (data that should be private and data for reviews not published are examples of that type of data).
The plan is to have the preexisting endpoint "reviews" be the private search endpoint and publicReviews be the public endpoint. As the "reviews" endpoint is being used by current accounts to fetch public reviews, we also added a privateReviews, which can be used until we have fully transitioned. The transition will happen in three steps, where we ensure that all accounts have applied the change before moving on to the next (by looking at usage).
Transition step 1: <-- We are here, recommended use (publicReviews, privateReviews).
Transition step 2: