dm4-webclient: throws type cache error for topic of type user should have an implicit read permission

[Malte]

I just experienced an error where the type cache of dm4-webclient has thrown the following exception. The page panel of my (the one who is currently logged in) username topic could not be rendered because of the following exception:

uncaught exception: TypeCacheError: topic type "de.mikromedia.site" not found

The same error is thrown if i click on the username topic of e.g "admin", which als has a (public) instance of such a topic type related.

The website topic in question in the first example (my own) resides in my private workspace (as which i am logged in) but it was not created via webclient. Subsequently it is not present in an topicmap and so isn't any instance of such a topic present in any topicmap from other user (as far i can oversee that).

The website topic in question in the second example (page panel fo username "admin") logged in was "walther" throws the same error despite the instance of that topic type (named "Standard Website", related to "admin") resides in a "Public" workspace.

4.8.2 is the DM Version i am experiencing this.

Probably this is related to #899 but i am not sure.

[Malte]

When i manually arrange the webclients type cache so that this error appears the same exception is thrown when the page panel tries to render the desired topic but for the first child topic type.

uncaught exception: TypeCacheError: topic type "de.mikromedia.site.name" not found

The user has read to that very instance of a "Website Name" topic (as it is public, residing in the "DeepaMehta") but the info of that topic cannot be shown.

BTW: All this happens also if the website topic is created with a proper workspace cookie.

[Malte]

To advance with the first dm4-webpages release i worked around this issue through introducing a dedicated and public "Webpages" workspace for all types of my plugin.

This isuse makes me think about if we should drop the implicit READ typedef solution as it makes things more complex for the moment and just bring a generic public "Types" workspace (just members could edit those and types should be public anyway).

Maybe its just a bit of nostalgics but this issue makes me want to bring the old "Type Builder" Workspace back, at best with some smart default greedily assigning new types created in a migration (as this would free me up lots of code to assign all assoc and topic and child types manually, bringing me to associates this with #371).