Gentics Content.Node Changelogs

---

Documentation RT58295

Added missing documentation to the PermResource, the resource for reading and writing permissions in the REST Api. Previously it was unclear how to get the folder and role permissions and how to read the permission bit strings in the response. This has been fixed.

---

Bugfix RT58285

The handling of “internal” datasources datasources that belong to a specific tag that has a part of type "Datasource" during Import/Export has been fixed. They will no longer be treated as individual objects, but as tag content. The changes in detail are:

• Internal datasources will no longer be excluded, even if datasources are excluded generally. Internal datasources must always be exported within the tags that contain them.
• Internal datasources will no longer be shown in the export overview or detail list.
• Internal datasources will no longer be shown in the conflict view.
• Internal datasources will no longer be shown in the import overview or detail list.

---

Bugfix RT58243

In some cases, due to incorrect tagmap data, the content repository synchronization during the publish process would detect changes in the content repository structure every time. This caused “changing” the structure on every publish run, which did not actually change anything, but just took some unnecessary time. This has been fixed now, the content repository structure will now only be modified if really necessary.

---

Bugfix RT58328

If a content file has no file extension, then the meta attribute file.extension returned the file name instead of an empty string. This has been fixed.

---

Bugfix RT58324

Pages that were published into a multichannelling aware contentrepository during a regular publish process did not get the correct updatetimestamp set. As a result, caches were not cleared by syncchecking. This has been fixed now.

---

Bugfix RT58278

When a file was dirted and then deleted during the next publish run, the publish run possibly failed, when the file should be published into a Content Repository where the attribute binarycontent was a filesystem attribute. This has been fixed now, the behavior in such cases will now be the same as when the attribute binarycontent is no filesystem attribute.

---