cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Document Client environment share Question

gilgi
DynaMight Champion
DynaMight Champion

Hi, 

I've created a document share for read access only:

{documentId: "f981b962-f98c-491f-bcef-8329388b7660", access: "read"}

and getting back a correct response showing I have a read share. However, when another user logs in to see the document, its meta data shows he can also write and delete.

Shouldn't the current user access permissions (listed in the metadata) reflect the current user permissions? Could it be that because this user is an admin he is not limited?

 

8 REPLIES 8

sinisa_zubic
Dynatrace Champion
Dynatrace Champion

Hi @gilgi 

 

I am not able to reproduce your problem. Not sure which way you tried to share documents. via sharable link or via direct share.

this is the way how you do it via sharable link

  const onDocumentCopyLinkButtonClick = (document: DocumentMetaData) => {
    environmentSharesClient.createEnvironmentShare({
      body: {
        documentId: document.id,
        access: 'read',
      }
    }).then((response) => {
      console.log(`claim link: ${getEnvironmentUrl()}/ui/document/v0/#share=${response.id}`);
    });
  }

 

and this is the way to do a direct share:

  const onDocumentDirectShareButtonClick = (document: DocumentMetaData) => {
    directSharesClient.createDirectShare({
      body: {
        documentId: document.id,
        access: 'read',
        recipients: [
          {
            id: "<uid>",
            type: "user"
          }
        ]
      }
    }).then((response) => {
      setActionStatus('Direct share created\n' + response.id);
      console.log(response);
    });

  };

 

The other user who either claims the share, or has access to the document because direct sharing, has only read permissions.

access: ['read'], id: "0a22eca3-82fd-4df7-bae4-7b25a38ce2a6"

 

If a user can delete a document, it means that the user must be the owner since only owners can delete documents. Is it possible that you have logged in with the same user?

 

I have tried to reproduce the issue with the latest SDK versions of the client-document SDK (1.5.1). 

 

Best,
Sini

gilgi
DynaMight Champion
DynaMight Champion

Hi @sinisa_zubic 

I'm using shareable link with the exact code as yours. Will send my code later.

Gil.

sinisa_zubic
Dynatrace Champion
Dynatrace Champion

Another way you can try to reproduce it is to share documents just via the API in swagger. The SDK is anyway a wrapper for the APIs.

 

Sini

educampver
Dynatrace Advisor
Dynatrace Advisor

Hi @gilgi, is this still an issue? Please share your code and whatever else information you consider useful for us to investigate.

 

Edu.

gilgi
DynaMight Champion
DynaMight Champion

I've figured out why I see this data and it's a completely different Issue I'm trying to understand the reason for.

The Grail Document is created using the documentclient create document hook. I'm currently running this NOT as a deployed app, but as an npm start application on my local dev environment. ALL of mydocuments, regardless of the saas tenant user i've used are created by the same user guid.

That being the case its obvious I see the documents on all places...

Is that how this should work on development?

educampver
Dynatrace Advisor
Dynatrace Advisor

It should work in the same way as in a deployed app. The documents are created with the authenticated user's ID; I've tried it and can confirm that this works as expected.

I don't see an obvious reason why this might be happening. Can you please try something? Create a new notebook with each user you've created documents with. Every notebook creates a document under the hood, then you can list the user documents, and check if the notebook's document owner is the same as the documents you've created in your app. Maybe we can draw some conclusions from it.

gilgi
DynaMight Champion
DynaMight Champion

Tested your idea. Notebooks are not shared. I'm now bothered with the question of why do the documents created under the same owner...

sinisa_zubic
Dynatrace Champion
Dynatrace Champion

yes this is the way how it should work when you develop it locally. once you start with the dynatrace app toolkit the local dev server, you are required to authenticate to the environment which you have specified in the app configuration file. The local dev server acts then as a proxy to all requests from your app to dynatrace - so you are not doing any requests directly.

 

when you then open in incognito mode a browser and access the local app, you requests will be still made as the user who started the dev-served and logged in.

Does this make sense?

Featured Posts