Version: 2024.1.2

🏴‍ Known Issues

Client freeze, when switching between mysite and globalsite if doclist is sorted and paging is used​

Description​

Internal: see TFS [#40038]

If an folder is selected, which have paging enabled and is sorted by any column, and then the user switches to the mysite or the globalsite it can happend that the client freezes and stops working!

Workaround​

Internal: see TFS [#40038]
If the Client was freezed, restart it!
Try to avoid switching between my and global site when paging is enabled on the currently selected folder. Select a different folder first (which does not have paging enabled) and then change the site.

inPoint.SetupCommon: installation is not working if "service pw" contains special characters​

Internal: see OTRS [2020081301000038]

Description​

Internal: see TFS [#42012]
The characters ";" and ":" cannot be used for the service password.

Workaround​

Internal: see TFS [#42012]
Please install the setup with an empty service user-password and change the password manually after the installation has finished successful.

Unpin inPoint folders from windows explorer "Quick access" is not possible​

Internal: see OTRS [2019102901000033]

Description​

Internal: see TFS [#49496]
If any inPoint folder is D&D into the windows "Quick access", it is automatically pinned.
Then this folder cannot be unpinned, because the contextmenu entry for "Unpin from Quick access" is missing on all virtual inPoint folders. 
This is a Windows Bug, because this happens also for some other applications!

Workaround​

Internal: see TFS [#49496]
  1. Add any windows explorer folder to the pinned "Quick access".
  2. Select "Quick access"
  3. On the right side: "Frequent folders", hold down CTRL and select all inPoint folders and this one additionally added windows folder
  4. Right click on the windows folder and select "Unpin from Quick access"
All selected inPoint folders are "unpinned"

AD sync: Inconsistency may occur between the inPoint user name and the AD user name, because of local security authority (LSA) cache update delay in Windows​

Description​

Internal: see TFS [#53804]
When the user name has been changed on a domain controller, the AD synchronization is not recognizing this change immediately.
In this scenario, the AD synchronization may return the old user name instead of the new user name.

The local security authority (LSA) caches the mapping between the SID and the user name in a local cache on the domain member computer. The cached user name isn't synchronized with domain controllers. The LSA on the domain member computer first queries the local SID cache. If an existing mapping is already in the local SID cache, the LSA returns the cached user name information instead of querying the domain controllers. This behavior is by design and is intended to improve performance.

The cache entries do time out, however chances are that recurring queries by applications keep the existing cache entry alive for the maximum lifetime of the cache entry.

Workaround​

Internal: see TFS [#53804]

Fresh install/inPoint.Admin: inPoint.CoreAlive check fails​

Description​

Internal: see TFS [#59674]
On a fresh install with the wizard inPoint.Admin is installed but not working because it requires also inPoint.Identity and inPoint.Core.

So you have to install inPoint.Core inPoint.Identity.Server (and maybe also inPoint.Client) as well.

When you execute inPoint.Admin after installing you get an error that AdminAPI is not working.

This is because the services (Admin/Core/Identity) have to be restarted after re-configuring for identity. To solve this a new wizard wich has Core and Identity also included is needed (and starts up the services after the configuration in the correct order)

Workaround​

Internal: see TFS [#59674]
Restart the inPoint.Admin, inPoint.Core and inPoint.Identiy services after all of them has been installed and configured before starting the inPoint.Admin application.

Upgrade from 2023.1.1: Kibana URL is not working​

Description​

Internal: see TFS [#66430]
After an upgrade from 2023.1.1 it can be that the Kibana URL is not working because of the following error message:

Action failed with 'security_exception: [security_exception] Reason: current license is non-compliant for [security]'

Workaround​

Internal: see TFS [#66430]
Add "xpack.security.enabled: false" manually to "C:\Program Files\Elastic\ElasticSearch\7.17.8\config\elasticsearch.yml" and restart the Elastic/Elastic-Kibana services

Some document links might be in a wrong order in the document list in case the document link count exceed the page size​

Description​

Internal: see TFS [#72060]
Prerequisite: the paging virtualization is turned on on the folder.

Some document links might be in a wrong order in the document list in case the document link count exceed the page size. 
The page size is 200 in inPoint.Web and 110 in inPoint.Client.

Workaround​

Internal: see TFS [#72060]
Scroll to the next page to find the document link.

inPoint.Core: Swagger ignores fields in CreateDocument​

Description​

Internal: see TFS [#79759]
The swagger page using "POST /api/v2/docs upload a new Document" sends the "fields" parameter so that it's not recognized on the server side. All the parameters must be in one "multipart/form-data" content called fields.

Workaround​

Internal: see TFS [#79759]
As a workaround it's possible to add a comment into the json body which will force "swagger" to use one "multipart-/form-data" content without splitting it.

Example:
Creating a document and setting two properties, "Type" and "State".
Image

The resulting request will have a body similar to this, the body contains all properties in "fields".
Image

Without the workaround, the request will look like this. The properties are added as own form-data entry.
(and not inside a property called "fields")
Image