[posit cloud] Outputs cannot be published from temp copies in others' personal workspaces

[mbaynton]

STR:

1. Create a project in your personal workspace capable of generating a publishing output. You may publish an output, but I don't think it's necessary.
2. Set visibility to all cloud users
3. Share link with your friend
4. Your friend accesses link and is given a temp copy of the project. 4.a) If the original author published the output already, the exact output will be tracked by rsconnect and publishing will fail since you don't have permission to redeploy it. This is not the primary focus of this report, however. You can work around this by clearing the list of published destinations.
5. Attempt to publish the output. Publishing fails fast with

   Error: HTTP 403
   GET https://api.shinyapps.io/v1/content/
   Unauthorized.

Cause: Applications that are temp copies have a null content_id Code in rsconnect tries to look up the content ID based on its application ID, which in this case produces a request to https://api.shinyapps.io/v1/content/

• ~Code ref 1~
• Code ref 2

[omar-rs]

Thanks @mbaynton for looking at the root cause. I'm not sure what's the best way to go from here, though, so maybe this goes back into the grooming column? A content/project is needed to create the output and to redirect correctly to it, but there isn't one (unless the temp copy project is forked).

We could:

1. message that one cannot publish from a temp copy
2. fork the project in rsconnect

Option 2 is a bit weird since re-publishing from the temp copy would create a fork each time.

[mbaynton]

A content/project is needed to create the output and to redirect correctly to it, but there isn't one (unless the temp copy project is forked).

I think I was too hasty in my linking to the cloudClient implementation of getApplication() in the issue description (Code ref 1). It does make a call to Posit Cloud to get the content object associated to the application, but I think callers of getApplication() are providing the output's application ID, not the source cloud project's application ID. That should always be fine.

So I think our only problem is in my link "Code ref 2." I think we can fix that by just avoiding attempting to set a space ID if the application has no content ID. This will result in the output showing up in the user's personal workspace, which seems okay since that's where the source project is.