Fix regression: Use Photos preview API for that webdav collection

[pulsejet]

Fixes a regression where the viewer cannot show any photos from collaborative albums, since these previews are not accessible over the core API.

I unfortunately introduced this while fixing another regression in #1409 😩
Any better ideas to do this? Using the source image directly isn't right because it might be huge (plus no support for HEIC/TIFF), so this seems like the better option.

[pulsejet]

Filename is the full dav path btw, including the collection. So for a normal file it looks like /files/user/... and /photos/user/... for collaborative albums.

[skjnldsv]

@pulsejet don't ping random devs please :)
I'll review it later

[pulsejet]

Apologies. He authored the commit that got broken (a05dbf3) so I thought he might know better.

[jkellerer]

Would it make sense to address this problem in a way that callers can decide how to provide preview urls for special cases instead of hard-coding the logic?

E.g.:

OCA.Viewer.open({
    ...
    previewUrl: ({ fileid, public, width, height }) => {
        return !public && generateUrl(`/apps/photos/api/v1/preview/${fileid}?x=${width}&y=${height}`)
    },
    ...
})

---

getPreviewIfAny({ fileid, filename, hasPreview, davPath }) {
    const width = Math.floor(screen.width * devicePixelRatio)
    const height = Math.floor(screen.height * devicePixelRatio)
    const searchParams = `fileId=${fileid}`
        + `&x=${width}`
        + `&y=${height}`
        + '&a=true'

    if (hasPreview) {
        const args = { fileid, filename, width, height, public: isPublic(), token: getToken() }
        const url = typeof this.previewUrl == 'function' && this.previewUrl(args)
        if (typeof url == 'string') {
            return url
        }

        // TODO: find a nicer standard way of doing this?
        if (isPublic()) {
            return generateUrl(`/apps/files_sharing/publicpreview/${getToken()}?file=${encodeFilePath(filename)}&${searchParams}`)
        }
...

[skjnldsv]

Just an update here.
Currently nothing is broken, it's just not idea as we load bigger pictures in photos.

I'm still not ok with adding custom app-oriented conditions in Viewer.
I'm still thinking about how to better approach this.

[pulsejet]

Currently nothing is broken

Do you mean nextcloud/photos#1440 is fixed? That's what this PR was meant to address.

I'm still not ok with adding custom app-oriented conditions in Viewer. I'm still thinking about how to better approach this.

Yeah it's not ideal at all. I just submitted this patch as a quick fix.

[skjnldsv]

@pulsejet if the source is provided, it should be rendered.
We fixed that in photos I think?

@artonge are we providing a source property for collaborative albums?

[pulsejet]

Currently nothing is broken, it's just not idea as we load bigger pictures in photos.

@skjnldsv @artonge I just want to point out that things are broken (this is latest stable25). Everyone doesn't use JPEG :)

Also closely related, with a lot of upvotes: nextcloud/photos#1452
There's no clean way to fix that one in viewer at all (had a go at it), since the token isn't exposed globally as a variable. So I agree this isn't the correct solution to the problem 👍🏻

[skjnldsv]

Closing for #1525