hiding assets from menus or lists - but giving view permissions

[Simon Opper]

Hi TQ crew

Is there a way to hide assets from the edg UI which are required imports, but maintain required view permissions so that any top level graph e.g. the top level taxonomy is shown in menus but not (some or all of ) its imports?

e.g. give view permissions for users (via roles and governance singleton) to imported graphs such as ontologies and shapes or customisations ontologies, (as far as I'm aware required to allow a user to view the top level asset) but hide these assets from:

1. the the main EDG home screen;

2. the "quick navigation to your collections" 

3. the table view of asset collections 

We are working on governance models for user and role permissions but haven't come across a method to hide assets.

Many thanks in advance

Simon

[Holger Knublauch]

I am afraid the short answer is no, we don't have such features. Other colleagues may have additional input.

There is dash:hidden which you can theoretically use to hide skos:Concepts from the Taxonomy tree, but that's about it.

Holger

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/86fe6c0c-eca9-4620-96ca-f78d01761861n%40googlegroups.com.

[Irene Polikoff]

It sounds like you are wanting to hide Asset Collections, not assets.

If a user has view privileges for an asset collection, it will appear in the list of collections, quick navigation/hamburger menu, etc.

On Sep 22, 2021, at 11:38 PM, Holger Knublauch <hol...@topquadrant.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/652215e6-4fc1-d546-2b52-c92f1ffef803%40topquadrant.com.

[Simon Opper]

Thanks for the info Holger and Irene

Yes, Irene, I am referring to hiding asset collections.

It seems to me that "view ( read) data access" should be able to be managed differently from "visibility" in asset collection menus and lists and indeed in a datagraphs "settings" menu import lists.  Could they be "hidden imports" for certain roles and governance models 1?

Our use case is that we have upwards of 10 or so ontologies and shapes ontologies that support downstream graphs in use by users, but they don't need to see them in menus or know that they are there at all. For a general subject matter expert user who may only need to look at and work in around 2 or 3 graphs, there is a growing set of data graphs and tagsets used by other layers of users that import into these, and so the import closure spreads across many collections.  Even after using role-based and subject area asset collection permission use the import net becomes very wide.

We have talked about using rules (sparql) to insert data into other graphs instead of using imports, to try and deal with this, but it takes that extra amount of work to achieve this, especially for every graph and so we've not committed to this.

Cheers

Simon

[Irene Polikoff]

On Sep 27, 2021, at 5:31 PM, Simon Opper <simon...@surroundaustralia.com> wrote:

Thanks for the info Holger and Irene

Yes, Irene, I am referring to hiding asset collections.

It seems to me that "view ( read) data access" should be able to be managed differently from "visibility" in asset collection menus and lists and indeed in a datagraphs "settings" menu import lists. 

Perhaps, but this is not a requirement we have heard nor implemented.

You can submit it through the support desk for future consideration. The more you could tell us about the overall use case and its context, the better. Such feature would need to be carefully considered and designed to work for different customers.

Could they be "hidden imports" for certain roles and governance models 1?

Our use case is that we have upwards of 10 or so ontologies and shapes ontologies that support downstream graphs in use by users, but they don't need to see them in menus or know that they are there at all.

One option available today is to implement such ontologies as files. Starting with 7.0, you can edit files with EDG. 

The downsides of this approach:

1. Only Administrators are able to edit Files.

2. It is one person editing at the time

3. There is no persistent audit trail across the edit sessions. Once the change is saved, the audit trail is gone. However, Git integration coming in 7.1 may help address this limitation. I have not looked at it deeply enough though.

This approach would be best for “system” ontologies that only a small group of pretty technical users would ever be changing.

For a general subject matter expert user who may only need to look at and work in around 2 or 3 graphs, there is a growing set of data graphs and tagsets used by other layers of users that import into these, and so the import closure spreads across many collections.  Even after using role-based and subject area asset collection permission use the import net becomes very wide.

Now you seem to be talking about hiding data graphs and tag sets. Or am I confused?

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/5683efeb-5f8e-4d4e-ae7e-82689ce456b6n%40googlegroups.com.