RStudio Connect - Feature Request - Lead Contact Display Field

Posit Professional & Hosted Products Posit Connect
1

Hi there,

I have a small (hopefully!) feature request I wonder if you could consider?

It would be nice if it were possible to display a different app 'owner' to the official owner on the front end of RStudio Connect.

My use case is that most of our content is deployed through a continuous deployment process which uses a service account, so most of the apps/reports are listed as owned by the service account.

It would be great to be able to add a 'Lead Contact' or similar, which would be purely for display purposes (and perhaps defaults to the publishing account). This would help users browsing the content page to know who was responsible for each app, even if they didn't personally deploy it.

Thanks as always for the excellent products!
Chris

Edit: should say we're running v1.7.2 - if this is a thing in later versions, apologies and we'll update!

1 Like
2

Thanks, Chris! This is great feedback, so thank you so much for sharing!!

Is it ever a "problem" that the content is "owned" by the original user? Would changing the owner itself be helpful or problematic? The only caveat about changing the owner is that you would have to be sure that the service account is still a "collaborator" or future deployments would fail.

A few options in the short term:

More customized content view

Are you familiar with the "Description" field and the "Expanded" view of content? You can add an arbitrary text description to content and then change the server view to "Expanded," which will show users this text description. You could, for instance, set some conventional behavior inside your organization that specifies, for instance, descriptions of the format:

Owner: Cole
Description: My fun project

Again, this is only arbitrary text and would give users the information without any Connect UI affordances.

To explore this more, click the image button in the top right corner of the content list.

image
image2398×832 94.1 KB

You can set this to be the default view on the server by setting the following in the RStudio Connect configuration file.

NOTE: You may need to update for this. I forget when this option became available. Also, you do have to upload the images yourself.

/etc/rstudio-connect/rstudio-connect.gcfg

[Server]
DefaultContentListView = expanded

Git-backed deployment

Are you currently using programmatic deployment with a custom webhook or CI pipeline? I'm curious if you have any feedback to share around how that process went, what pain points you experienced, or how Connect might be able to simplify that workflow.

One feature that landed recently (in the 1.7.6 release) is Git-backed deployment. The blog post linked below discusses in more detail, but basically this could allow a "service-account approach" and being the owner too :slight_smile:

Basically, a user clicks on the "New Content" button shown in my screen shot above, selects a git repository, branch, and sub-directory, and then Connect will "watch" that branch / sub-directory and pull / deploy updates as necessary. Essentially, this is a "pull-based" CI that makes the user who originally created the "watcher" the owner of the content. I'm curious to hear your thoughts about this and how it relates to your current workflow!

EDIT: If you find these features useful and were unaware, I definitely recommend subscribing to our blog at https://blog.rstudio.com so you can stay up-to-date on the latest releases and features that we are adding :smile:

We also just made some changes to the blastula package (which should simplify email generation) and added pins as a new content type:

1 Like
3

Thanks for this Cole!

On your first point, no it isn't really a "problem" - it would just be a nice to have addition. I think changing the owner using the CLI would probably be more effort than it was worth for us - it's more important that the deployments continue to succeed smoothly.

I think the more customised content view is likely to be the best bet for us - thanks for sharing that tip. Is it just administrators who can edit the Description field?

On the git-backed deployment front, I like this idea very much but I think it might play havoc with our current governance process - we have the following setup:

  • code hosted on Microsoft Azure DevOps, and released through a deployment script run by an agent
  • 2 RStudio Connect servers - a staging server and a production one

We mandate that content must be deployed and checked on the staging server before it goes to production, for each release, and I'm not sure it would be possible to enforce that if both servers are watching the same repo? (Possibly could workaround with different branches/pull requests)

As part of the deployment script, a log is written to a SQL database with details of the origin repo, the person requesting the release, the destination content ID and whether it succeeded or not - I don't think it would be possible to build that extra logging into the the git-backed deployment route?

Thanks very much - I will subscribe to the blog!
Chris

4

Awesome! That's great feedback, thanks! I will definitely pass this along to the product team!

  • Content collaborators and administrators can edit the Description field for content. Only content collaborators can upload an image to the content. Hopefully I have that right :smile: Definitely let me know if you see otherwise!

  • It's worth noting that the Description can also be set programmatically via the "Create Content" API request. So if you have some of this information available in Azure DevOps, then you could definitely pass it along to "enforce" the default for this convention at least!

https://docs.rstudio.com/connect/api/#createContent

  • That makes a lot of sense. Yes, the "enforcing" you are discussing would probably make more sense either in the different branches approach (where typically the Prod system would be more locked down and only allow certain users to create watchers) or in some approach where content is deployed from staging to production instead of from git. If the approach you are using works well, these seem like sufficiently painful losses to justify avoiding features that are not helpful :smile:

You are correct that the extra logging would not be built into the git-backed deployment route. You would ultimately need to scrape the Connect audit logs (or maybe even the server & content logs too :scream: ) to get a picture of that information, which would be a sizable amount of work.

In any case, that is definitely good feedback! Custom use cases is exactly why we created the RStudio Connect Server API and I am glad to hear that it is working for you!

(One other note. Though the headline features may or may not be useful for you, there are a handful of bug fixes, security patches, and improvements to logging / debugging / error handling in the newer versions of the product, so I would definitely recommend updating when you get the chance!)