I am trying out the pins package with RStudio Connect and have noticed that if I pin an object like say, my_tbl, the resource name that has to be used with pin_get is prepended by my username requiring it for subsequent pin_get calls. for example:
pins::board_register_rsconnect(name = "myServer", server = "https://myserver.com")
myCars <- mtcars
pin(myCars), name = "myCars", board = "myServer")
pins::pin_get("schuffr/myCars", board = "myServer")
So my issues are:
I want to publish a variety of resources to our RSConnect server for others to use long-term
I am concerned that if I leave my employer (not planning to) and my account on RS Connect is deactivated/deleted, will the resources still be available for others to use?
Is there a way to pin resources without any dependencies on my account (including the content of the pin's name?)
There are two different notions of deactivating an account on RStudio Connect.
If the account is locked, content stays and is available to other users just as before, but the person has no ability to login.
If the user is actually removed, then it is possible to transfer all their content to another user prior to deletion using the usermanager tool.
We generally recommend just locking users to deactivate them and only deleting as a last resort. Details are in the RStudio Connect admin guide (12.5 and 12.9).
Pin Names
The username is prepended to the pin name to ensure uniqueness across the server. If you pin something to RStudio Connect and someone else retrieves it, they can just use the name you used to pin it.
For example, if you run pin(mtcars, "cars", board = "rsconnect"), anyone else will be able to get the content by just running pin_get("cars", board = "rsconnect"), with the caveat that they'll be forced to disambiguate if someone else creates a "cars" pin and gives them access as well.
Thanks Alex! For an organization that may be wanting to use pins functionality as a long-term and durable repository for archiving data pertinent to a subset of individuals, it would be fantastic to have a way of pinning content to an "account" that is independent of a real person and does not consume a user license.
Sounds like there is no way to do that today, but maybe this should be a feature request? Maybe arbitrary groups could be created that enable the creation of "group repository" and pinning of resources to such repositories.
Creating a service account just for uploading long-running content is already possible, though it does consume a user license.
We've heard interest in something like what you're describing -- would love to hear a little more about what would work for you.
Few questions I'm thinking about:
What would make this "group repository" different than just granting access to your content to individuals or a group?
What would you need to see in the repository?
Would this repository be just for pins? Or for any kind of content?
Right, re:service account. This just came up for us as I was beginning to explore a use case for pins that involves publishing/archiving data for long-term read-only use by a group of people in our organization.
The difference for the group repository is that ownership could be by the "system" rather than a user who may or may not stay with the organization, and we would prefer not to have as our only option, to lock their accounts.
We would need to see whatever content we put in the repository and have some way for authorized users to manage the repository.
I think it would be useful to have it be for any kind of content, but my immediate use case is data/pins
One idea would be to create a shared account on RStudio Connect. You wouldn't actually give people access to the account, but would just give them an API key from that account.
Then they could deploy pins as that user with the API key, and you could delete that API key if they left.
They would be able to use all of the pins functionality in the IDE, including pins_find and the connections pane to search through pins deployed on RStudio Connect, but they wouldn't be able to see the pins on RStudio Connect by default (they deploy as user-only). You could use the RStudio Connect content API to change that, again using the shared user's API key. Could even wrap it in an R function to make it easy.
Yes correct. All of this could be done with a service account that consumes a user license. Just not wanting to have to use a named user license to do it, if possible.
We'll do that for now and await a built-in "system" account that accomplishes this.