pin_read() on Connect fails if the owner changes

[nealrichardson]

When someone leaves the company, their content on Connect, including pins, gets transferred to someone else. But this breaks any consumers of pins who specify pins::pin_read("person-who-left/pin-name"), because it `Can't find pin named 'pin-name' with owner 'person-who-left' (code).

Reading the code, it looks like pin_read("pin-name") would work, as long as the user only has access to one pin named that. IMO, we should recommend that usage, and for cases where you're concerned that there could be multiple pins with the same name, recommend (and support in rsc_content_find()) referencing the pin by GUID, which is immutable. I don't think we should recommend the username/pinname way of referencing pins because that is not a convention that Connect knows about or enforces as a way to uniquely reference content.

[juliasilge]

This would require (well, sort of) work on the Python side to add all the looking up, guessing, etc for usernames. Currently the Python package requires you to always provide the username, for both writing and reading.

See for example:
https://github.com/rstudio/pins-python/blob/8a4faf12fee92687eb4d52b14006be1508948866/pins/boards.py#L1165

cc @isabelizimm

[dareneiri]

I am also interested in learning what would be the best approach for addressing the issue of pins that are owned by employees who no longer part of the company.

One idea back in 2020 was to use a shared service account to pin objects, but then it would be hard to determine who actually pinned something because the pins would be owned by the same shared account.
https://forum.posit.co/t/pins-rstudio-connect-usernames/51849/5

Are there downsides to using something like pin_read("pin-name") other than when there is duplicate content, it would error out? Is there any possibility of enforcement for R Pins that would require a username in future iterations, to match with what Python Pins is doing today?

Also, when transferring ownership of content to another user, unless you filter out pins content, the example code provided in Posit documentation for transferring content would break any code that references pins with the full name, because the names of the pins would consequently change. "old-employee/pin-name" would change to "current-employee/pin-name"
https://docs.posit.co/connect/cookbook/content-access-controls/transferring-content-ownership/

[juliasilge]

This is an area where the experience isn't quite where we want, @dareneiri, and I am sorry you are having to figure out what to do in a non-ideal situation here.

• Connect doesn't currently have support for true/real service accounts, but that is a longstanding feature request. It is true you can kind of fake it by treating a "normal" account as shared but there are definite downsides to that.
• There are not dramatic downsides today to using pin_read("pin-name"), unless you are wanting to read from Python, there really are duplicates, etc.
• Related, we definitely have considered making the R pins package stricter and requiring the username (like the Python package does) but that would be a breaking change and we haven't currently decided that it is worth the pain for users.
• You are entirely correct that the HTML landing page does not update to reflect current reality. That HTML content gets built and bundled when you publish the pin, and currently it cannot/does not change until you publish again. This is also a longstanding feature request, to have the HTML landing page generated on the fly by Connect (so it reflects the current reality) rather than coming in as part of the bundle. The workaround for now would be for the new owner to republish the pin.

I'll check in with a few folks internally about other advice we have on migration of pins, but it sounds like you are doing about the best you can under current circumstances.

[juliasilge]

@dareneiri Just as a heads up, we've linked your request here to our existing feature request about Connect generating the pin landing page on the fly. Thank you again for the feedback!

[lachlansimpson]

See on internal ticket #120179