Sections in the article
Inriver is moving towards more incremental, smaller releases to better and faster accommodate our customers. With smaller, more frequent releases, Inriver can improve release quality and transparency and identify and mitigate erroneous behavior much faster.
NB! To receive notifications when new release notes are published, please ensure you follow this page by clicking the "follow" button above.
Please see below for the deployed features and improvements:
General
-
The Table View Filters panel now includes a language selector, enabling users to locate and filter columns in large, multilingual data models with numerous languages and LocaleString fields. This enhancement ensures that filtering remains accessible and efficient regardless of the number of columns generated by the model's language and localization configurations. Each LocaleString field adds one column per language, so large models grow fast:
- 100 languages and one LocaleString field gives 100 columns.
- 100 languages and five LocaleString fields give 500 columns.
-
100 languages and 64 LocaleString fields give 6,400 columns.
How it works
When your Table View has more than 200 columns, the Filters panel shows one language at a time. Pick a language in the selector at the top of the panel and filter its columns right away. The selector appears when the Table View contains at least two languages.
Starts in your language: The panel opens in your Data Language. If that isn't available, it uses your Interface language. Check your preferences under User Settings.
Stays where you left it: "Reset columns" keeps your selected language, so you can carry on without picking it again.
What stays the same
The Columns panel still shows all columns. The table itself is unchanged. All your columns remain visible and available. Table Views with 200 columns or fewer don't show the language selector. The Filters panel works as usual.
Why we made this change
Large models shouldn't limit how you work in Table View. A single list of every language column is too long to use, so the Filters panel now shows the language you're working in. It stays easy to use, whatever the size of your model."
- It has been implemented that the inriver MCP Server (Query Manager) can now recursively retrieve all entities of a specified type from any channel node and its descendants. This enhancement facilitates comprehensive channel content validation, complete business-unit exports, identification of missing products, and integration with downstream reporting processes.
- It has been implemented that the Query Manager MCP get_entity_data tool now supports retrieving entity data as of a specific snapshot version by supplying a snapshot tag. When no tag is supplied, current entity data is returned unchanged. Please note! This improvement is only visible if snapshot tags have been created for the instance.
- It has been implemented that requests to inbound extensions are now limited to a configurable number of concurrent requests per environment, consistent with existing REST API behavior. Requests that exceed this limit will receive an HTTP 429 (Too Many Requests) response instead of being processed immediately.
- It has been implemented that creating multiple entities at the same time is now more reliable and no longer occasionally fails due to temporary database lock conflicts during high-concurrency operations such as parallel imports.
Please see below for the deployed bug fixes:
General
- We have applied a solution to ensure that entities can be added or updated through integrations and extensions even when a CVL key is provided with different letter casing than how it is stored. Keys are now matched regardless of casing, while keys that genuinely do not exist are still rejected.
- We have applied a solution to ensure that specification fields formatted with HTML now return complete and valid HTML even when one or more specification entries are left empty. Previously, the generated HTML could be missing closing tags, which caused broken or inconsistent formatting. The output now remains correctly structured regardless of whether all entries contain values.
- We have applied a solution to ensure that when you update a single language of a multilingual (LocaleString) field through the Remoting API, only the language you actually changed is recorded in the field's history. Previously, unchanged languages could be incorrectly logged as modified when the value contained a line break.
- We have applied a solution to ensure that specification fields formatted with HTML now return complete and valid HTML even when one or more specification entries are left empty. Previously, the generated HTML could be missing closing tags, which caused broken or inconsistent formatting. The output now remains correctly structured regardless of whether all entries contain values.
- We have applied a solution to ensure that specification fields formatted with HTML now return complete and valid HTML even when one or more specification entries are left empty. Previously, the generated HTML could be missing closing tags, which caused broken or inconsistent formatting. The output now remains correctly structured regardless of whether all entries contain values.
- We have applied a solution to ensure that complex queries run through the ExtensionManager return correct, consistent results - matching RemoteManager - when the same SystemQuery is reused across multiple queries.
- We have applied a solution to ensure that server extensions are no longer re-instantiated on every event. The extension instance is now reused across events, restoring the previous behaviour where initialization runs once instead of on each event execution.
Inriver Implementation Standards
Inriver's ambition is to collaborate with our partners in providing our customers with the safest and most secure PIM system possible. With that in mind, Inriver is improving the information on our Community to help implementation partners ensure quality, optimize implementations, and avoid pitfalls.
Read more about Inriver Implementation Standards
Comments
2 comments
I like the language selector a lot as it eases the search for a certain attribute in a certain locale.
However, it would even be greater if it could be used in the main window as well.
See my INSE-I-758 idea; it would partially solve it by making it available in the main area/window as well :-)
Henk-Jan
Thank you Henk-Jan van Pesch (Solenis) , glad you like the improvement, I will review your suggestion and see what a next step can be. Anyone else agreeing with Henk I would love to hear your use case. Please vote and share your use case in the comments to the idea. INSE-I-758 .
Please sign in to leave a comment.