republishing and collaborating

[aronatkins]

Revisit how the deployment target is selected.

Use 0.8.29 implementation when reviewing this work. In particular, that version of deploymentTarget() did not offer any separation between the "owning" account and the "deploying" account. Details recorded in the in-memory deployment record were not necessarily consistent with the on-disk deployment record. Additionally, resolving that deployment record to an actual remote application occurred much later, in applicationForTarget(). https://github.com/rstudio/rsconnect/blob/v0.8.29/R/deployApp.R

The implementation available in 1.0.0 until now did a good job consolidating this logic, but lost track of the fact that we may have a local user attempting to re-use deployment records created by some other user.

This change sees us use the following prioritized techniques to locate a deployment record:

1. When appId is provided, it must be used to locate the target content. A target (local) account is required to make this determination. When a local deployment record is not available, the application is loaded from the server. The target deployment record does not need to be owned by the local target account.
2. When appName is provided without appId, it must be used to locate the target content or create a new deployment target.
3. When neither appName nor appId is provided, the user is asked to choose from the available deployment records (which must correspond to a locally available account).
4. When there are no deployment records, a generated name is used along with a target account to remotely probe for that name (owned by the target account) before creating a new item.

Some collaboration instructions from the Connect user guide: https://docs.posit.co/connect/user/publishing/#publishing-collaboration

Related issues: #1019, #1013, #1007, #981 along with multiple internal reports.

This change may fix each of those issues, but they need more review to be sure.

[ChaitaC]

Verified the fix for https://github.com/rstudio/rsconnect/issues/1013

Before the fix, when using CRAN Version 1.1.1

── Preparing for deployment ────────────────────────────────────────────────────
✔ Deploying "shinyappsIO" to "server: shinyapps.io / username: chaitatest"
ℹ Creating application on server...
Error in `POST()`:
! <https://api.shinyapps.io/v1/applications/> failed with HTTP status
  409
Application exists with name: shinyappsIO
Backtrace:
    ▆
 1. └─rsconnect::deployApp(...)
 2.   └─client$createApplication(...)
 3.     └─rsconnect:::POST_JSON(service, authInfo, "/applications/", json)
 4.       └─rsconnect:::POST(...)
 5.         └─rsconnect:::httpRequestWithBody(...)
 6.           └─rsconnect:::handleResponse(httpResponse, error_call = error_call)
 7.             └─rsconnect (local) reportError(json$error)
 8.               └─cli::cli_abort(...)
 9.                 └─rlang::abort(...)
Execution halted

Using the development version from GitHub, the existing app can be redeployed and replaced without any issue.

── Deployment complete ─────────────────────────────────────────────────────────
✔ Successfully deployed to <https://chaitatest.shinyapps.io/SHinyappsIO/>
Deployment completed: https://chaitatest.shinyapps.io/SHinyappsIO/

[ChaitaC]

Verified https://github.com/rstudio/rsconnect/issues/981 Verified https://github.com/rstudio/rsconnect/issues/1007

Collaborator publishing works without any issues. A collaborator can update the content as long as he has an accurate rsconnect dir.

[ChaitaC]

⚠️ If a user lacks the necessary permissions to collaborate but possesses the required rsconnect directory, the following error message is displayed:

✅ When a user possesses the appropriate collaborative privileges, the interface appears as follows:

[ChaitaC]

@aronatkins the error message 39] in it does not make sense. See for image https://github.com/rstudio/rsconnect/pull/1021#issuecomment-1802691309

this is an edge case though

[aronatkins]

I have filed https://github.com/rstudio/rsconnect/issues/1026 to track the escape codes that are presented by the IDE when the target content has been deleted (or is not visible to the user).