[Proposed Feature] Add copy URL functionality to all objects

[jedsundwall]

Description of Feature:

Every object or folder in a Source repository should be accompanied by an affordance to copy the URL of the object or folder into the user's clipboard. I'm open to different approaches to the design, but perhaps something like the "link" icons above could be appended to each row. Upon hovering over a link icon, a tooltip saying "Copy URL" will appear. If a user clicks on the icon, the tooltip will change to say "URL has been copied to the clipboard."

What value is this feature adding to Source Cooperative?

This will allow users to quickly get URLs for objects which will allow them to copy them into other applications or share them with other people.

[cholmes]

One twist is that different users may want the link for the 'folder' to be different things. My use case is more to have it be the s3 link, to be able to use a CLI or python to interact with the s3 endpoint. But if it looks like a link I'll probably think it's just the url for the source.coop view.

[jedsundwall]

We won’t expose S3 endpoints publicly due to bandwidth constraints, but there’s something we can work out here. Why are you using that requires s3:// endpoints that couldn’t be done via https://?We’ll give people S3 access if they’re authenticated, in which case we can generate presigned s3:// endpoints that would work with the CLI. On Jun 26, 2023, at 6:15 PM, Chris Holmes ***@***.***> wrote: One twist is that different users may want the link for the 'folder' to be different things. My use case is more to have it be the s3 link, to be able to use a CLI or python to interact with the s3 endpoint. But if it looks like a link I'll probably think it's just the url for the source.coop view. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[cholmes]

We won’t expose S3 endpoints publicly due to bandwidth constraints, but there’s something we can work out here. Why are you using that requires s3:// endpoints that couldn’t be done via https://

Mostly just to use with cli's to sync with it. Also DuckDB let's you 'glob' against S3, like just do 's3://bucket/path/*.parquet', while with https you have to name each file, see https://duckdb.org/docs/extensions/httpfs.html

We’ll give people S3 access if they’re authenticated, in which case we can generate presigned s3:// endpoints that would work with the CLI.

That does work for my syncing use case. For DuckDB it'd be nice to let people do it with anonymous access. Like this section of my tutorial wouldn't work.

[jedsundwall]

Got it. For datasets that are hosted by the AWS Open Data program, there's no reason why we wouldn't highlight the fact that you don't need credentials to access the data.

Right now, you can see the bucket URL if you click generate credentials at https://beta.source.coop/repositories/cholmes/overture/download, but I think we should be able to let people skip that step and just see the bucket address.