Get current workspace without the need for token

Feature Requests
1

Description of the limitation and why it is relevant to address

As a developer I want to be able to access the current workspace (Workspace object) from within the workspace (for example by calling API().get_current_workspace()) so that I can use the workspace information (such as name, visibility, app version, …) in my app.

Current workarounds

Currently, one can access the “current” workspace by calling

# workspace_id is available via kwargs
API(token="TOKEN").get_workspace(workspace_id)

Notice that token needs to be provided, otherwise it does not work. However, I don’t think that accessing the workspace from within the workspace should require a token. I don’t feel comfortable having the token as an environment variable for the app, as it can potentially be misused.

Proposed design

This can be done by:

  • Adding a “get_current_workspace()” method to API;
  • Allowing the workspace id of the current workspace to be passed to API().get_workspace(workspace_id) without the need to provide the api token.
  • …
2

Hi @Sina,

Sorry for the late response.
Since SDK version v14.7.1, workspace_id is added to the signature of controller methods and callback functions. So this can be accessed without using the API the same way as enitity_id enz.

v14.7.1
Current workspace and entity

I hope this helped.

Maarten

3

Hi Maarten,

Thank you for your reaction!

It is true that workspace_id can be accessed, but the workspace itself, cannot be accessed without the API and a token.

So this works:

API(token="TOKEN").get_workspace(workspace_id)

But this doesn’t:

API().get_workspace(workspace_id)

And my “feature request” is that it works without the need for a token.

4

Sorry, I misunderstood your question.
Thanks for makeing the request. We will look into this.

1 Like
5

Hi @Sina ,

I’m curious to understand what you would like to retrieve from the workspace. Could you provide a small example/set of examples?

6

Hi @mslootweg,

This is the use-case that led to this question (which we still need btw :sweat_smile:) :

The TLDR version is that we need to include the app version in our storage keys. and the app version is an attribute of the Workspace instance.

Here’s the full story:

We have an app that porforms a heavy calculation that includes workers, thousands of API calls, etc.. This calculation takes 5 to 10 minutes. Almost always, the user wants to try out a couple of variants to see the differences and the effects of changing a certain input field. This means a lot of waiting time.

To avoid unnecessary wait time, we save the results for each set of input (params), so that when the user has a set of input that have been calculated before, the ressults are pulled from the storage.

Well so far so good!

The problem is, when we find a bug in the calculation and fix it, the saved calculation cannot be performed again, because the application pulls it our from the storage. Currently, we manually delete the storage on new app releases to fix this. That is not a sustainable solution.

But, if we can include the app version in the storage logic, the app does the calculations again in case of a new release / big fix.

Please let me know if you need more info.

7

Very valuable input! We should especially consider this when we go in the direction of version pinning:

But for now to simply have the info of the workspace, project and app would make total sense.

1 Like