sections in the article
inriver is moving towards more incremental, smaller releases to be able to accommodate our customers in a better and faster way. With smaller, more frequent releases, inriver will be able to increase the quality and transparency into the releases and be able to identify and mitigate any erroneous behavior that may be caused by the release much faster. Please note that larger features and/or changes that deem to have a strong impact on customers and partners will of course be communicated in advance.
On March 18th - March 19th, the following patches were deployed to all stacks:
Improvements and/or enhancements for Remoting:
-
Correction for when user has many/large CVL values in the system and call "GetAllCVLValues" with the RemoteManager (Remoting API), the operation will be abrupted the exception: Unexpected end of file has occurred.
-
Correction for when a user attempts to import items and user receives the error "Exception thrown adding entity. Message: An unexpected error occurred when adding entities"
-
Correction for RemoteManager and null reference exception when calling on UpdateFieldsForEntity with null as input
-
Correction for call to GetSpecificationField (DataService) with an entity or specification field type id that doesn't exist you return object reference exception wheras null should be returned
-
Correction for error message "An error occurred when notifying Connect" to add information about extensionid and event
-
Correction for when creating a new resource entity and MainPictureId and MainPictureUrl and both MainPictureId and MainPictureUrl is null in the returned object
-
Correction for validating data and url when adding a resource file that doesn't have any data
-
Correction for null reference exception when getting server setting with null (Remoting API)
-
Correction for call to GetConnector (UtilityService) with input null
-
Correction for proper null handling for GetServerSettings (UtilityService)
-
Correction for call to AddPersonalWorkAreaFolder (UtilityService) with "new WorkAreaFolder { Name = "My Test work area" }", It should add it to "My work areas and queries" and not added as a top node.
-
Correction for call to AddSharedWorkAreaFolder (UtilityService) with "new WorkAreaFolder { Name = "My Test work area" }" where it should be added to the shared work areas folder and not as a top node
-
Correction for adding a shared work area folder with the name equal to null through the Remoting API
-
Correction for changing the localized name for an HTML template when using Remoting API
-
Correction for the user not being able to delete a field type if you have created a new entity version with it (in the Remoting API) and result in "An unknown server error has occurred"
-
Correction for the user not being able to delete an entity type if you have created a new entity version with it (in the Remoting API) and result in "An unknown server error has occurred"
-
Correction for when you call the method GetSpecificationField over Remoting API to retrieve a specific specification field from a specification the "id" is always 0. The id should be a unique integer id created internally by the system when you add a specification field.
-
Correction for call to GetAllChannelStructureEntitiesFromPath where it can time out if the channels are very large.
-
Correction for creating new entity window in Portal does not update if you change DEFAULT_CREATE_ENTITIES from the Remoting API. The value change is visible in Control Center but not in the Portal.
-
Correction for call to DataService.Search with a query consisting of 2 or more criteria that apply for FieldTypes on different EntityTypes which results in an "Internal Server Error".
-
Correction for call to DeleteConnectorSetting (UtilityService) with connectorId = null or key = null it will throw "An unexpected error occurred when getting connector" - should have a null check.
-
Correction for input validation for CVLs in ExtensionManager, RemotingManager and Controlcenter as inriver PIM only accept String/LocaleString according to this community page: https://community.inriver.com/hc/en-us/articles/360015674754-CVL
-
Correction for capitalization check on ModelService.AddFieldTypeToFieldSet
-
Correction for SetServerSetting (UtilityService) to handle null as input
-
Correction for GetAllPlannerViewsForUser to handle null as input
-
Correction for AddImageServiceConfiguration if Extension or OutputExtension when input is longer than 16 characters - a proper error message should be provided
-
Correction for call to UpdateSharedWorkAreaFolderIndex (UtilityService) if the shared work area folder doesn't exist - call should return null if the work area does not exist
-
Correction for when user sets id and newParentId to the same value with MoveSharedWorkAreaFolder where an error should be returned as id and newParentId can't be the same.
-
Correction for call to UpdateSpecificationFieldCategory (DataService) to handle null as input
-
Correction for call to GetAttributeSet to handle null as input if the attribute definition doesn't exist
-
Correction for call to AddAttributeSet (PrintService) where the input group (object attributes name, type, and group) is returned as null
-
Correction for call to GetPlannerViewByCalendarUrl(UtilityService) with calendarUrl to handle null as input
-
Correction for input validation when a user writes a connector event in the Remoting API (WriteConnectorEvent, UtilityService)
-
Correction for ErrorMessage in AddFieldTypeToFieldSet which is not properly shown when the user try to add a FieldType to a FieldSet (with the Remoting API) that already has that particular FieldType in it
-
Correction when Newtonsoft error "Self referencing loop detected for property 'Source' with type 'inRiver.Remoting.Objects.Entity'. Path 'Source.Links[0]'" when targeting LoadLevel.DataAndLinks
Breaking changes in nuget 8.6.5
- Removed endpoint AddAssetConfigurationInputModel
- Removed endpoint AssetConfiguration
- Removed endpoint GetAllAssetConfigurationsAsync
- Removed endpoint DeleteAssetConfigurationAsync
Comments
8 comments
Correction for call to AddPersonalWorkAreaFolder (UtilityService) with "new WorkAreaFolder { Name = "My Test work area" }", It should add it to "My work areas and queries" and not added as a top node.
Correction for call to AddSharedWorkAreaFolder (UtilityService) with "new WorkAreaFolder { Name = "My Test work area" }" where it should be added to the shared work areas folder and not as a top node
Does the above mean that we cannot add new "top nodes" (image below)?
What will happen to existing top nodes?
Should I create a feature request to add custom top nodes?
Hi Roy Eriksson,
Thanks for reaching out about this! Yes, the hidden "feature" to create additional "top nodes" for work areas has been removed as this was seen as an unwanted behavior. We are discussing if this was a hasty decision and if there is any harm in allowing this. There are some limitations in that you cannot access these "top nodes" from the dashboard and there is also a limitation/inconsistency in that its only possible to create these "top nodes" from the API and not from the UI. What are your thoughts around these limitations?
On your question about already created top nodes I have verified that these will still be available in the UI and can be worked with as before. What has changed is that you are currently not able to create new "top nodes".
Hope to hear back from you!
Kind regards,
Karin Björnbäck, Product Owner
I see this as a breaking change you introduced and this is not attached at all to the Remoting 8.6.5 since you already changed it on the server side.
Above: Workarea created with Remoting 8.2.4
Below is how it can look in one of our customer environments.
Please put it back!
Karin Björnbäck
Yes, the hidden "feature" to create additional "top nodes" for work areas has been removed as this was seen as an unwanted behavior. We are discussing if this was a hasty decision and if there is any harm in allowing this.
I would say yes, and agree with Tobias Månsson that it might even be regarded as a breaking change (which we would have liked to be informed about in advance). Instead of removing I would have linked for it to instead be added and improved upon since it's actually a great feature, read more below.
There are some limitations in that you cannot access these "top nodes" i.e. when configuring channel nodes or from the dashboard. There is also a limitation/inconsistency in that its only possible to create these "top nodes" from the API and not from the UI. What are your thoughts around these limitations?
We've come to accept the limitations that might exist (no availability in channel nodes, etc.) and only use this internally as navigation, divisions, etc. I actually like that it's only available using the API because it cannot be "abused" by users that might create their own "top nodes", so we partners can guide regarding "best-practices" (hehe, weird to say for unofficial "features" 😉) and alike for "top nodes".
Of course the best scenario would be if we could create these in the Control Center. Access from all places just like regular personal and shared workarea nodes, from the API, etc. Icing on the cake would be if the visibility could be tied to user roles, segments or similar to control visibility (feature request material).
On your question about already created top nodes I have verified that these will still be available in the UI and can be worked with as before. What has changed is that you are currently not able to create new "top nodes".
Great that existing once are kept as it's being used in live environments. Please keep it that way if possible.
There are some limitations in that you cannot access these "top nodes" i.e. when configuring channel nodes or from the dashboard.
I don't agree with that. In my example below you see the Root node "LinkRule Queries". We found that queries used in LinkRules should often never be altered. By placing them in their own tree structure, the risk of users manipulating them is lower. You can both Save new queries and find existing queries in the LinkRule Configuration if you store them as Shared.
Hi Roy Eriksson & Tobias Månsson,
We have now decided that we will revert this change and keep this functionality as it used to work with the possibility to create "top nodes" from the Remoting API.
Thanks again for reaching out!
It's now a feature request: https://community.inriver.com/hc/en-us/community/posts/8201842580636-Add-custom-work-area-top-nodes-besides-personal-and-shared-
Hi Roy Eriksson & Tobias Månsson,
It's now possible to create "top nodes" via the Remoting API again and we have reverted the change that prevented this. For the future we will investigate if this capability should be extended so I think the feature request that was created is still valid. Keep adding more comments if you have other ideas on how to work with this!
Thanks,
Karin
Please sign in to leave a comment.