Hey there @Tobias Johansson (mutze) - I think you actually fixed this issue. Could you confirm?

Could you outline the reasoning behind storing the watch progress in the user document instead of in the node docs?

Sounds good. We should discuss how to handle node_type properties overrides (for example predefined values, or allowed values).
Probably this makes "migrations" easier, and reduces complexity when validating nodes so it's really exciting!

Awesome! I add a comment here, to be discussed tomorrow.
Could you outline the reasoning behind storing the watch progress in the user document instead of in the node docs?
I think that storing such info in the node docs would allow for simpler/faster queries both when fetching an individual video and when fetching a series.

I'm working on this in the wip-video-progress branch. We're not storing progress in local storage, but actually in the database, so that it's independent of the machine you're viewing the video on. It's implemented as VideoJS plugin, so it should work in all supported browsers and be independent of the exact element IDs etc.

This is still an issue with Firefox 61.0.1 on Win10 :( Also on Google's own example though, so not sure we can fix this. I might dig into some other libraries for pano viewing.

I agree, Blender can easily save a file as JPEG in some temporary location before uploading.

The HTML was fine, but it was "converted" by JavaScript that expected MarkDown and stripped tags.

It's in master + live in production. Production database has also been migrated to the new schema and all nodes have had their empty attachments dicts removed.

Development is being developed in my shortcodes branch .

Addressed in e6edd00e468d.

Resolved in 12272750c302 (Pillar), 5f07c7ce17671 (Cloud) and some other commits in Attract, Flamenco, and SVNMan.

Looks good to me :)

Some additional info: when the user is not authenticated, the link shows up.

We can even pre-fill some parts of the description from that button. Check it out, https://developer.blender.org/maniphest/task/edit/form/6/?description=je+moeder totally works. That way we can already have the URL of the page they pressed the button on, browser make/version, OS/version, etc. in there.

Changing to low prio since we have a Celery task that actively refreshes expired links.

Fixed in 230b2c669c431c8521c2228193ede1a512e08148

This is probably due to Zencoder. Pillar uploads the file to GCS just fine, on this recent video with a Content-Disposition: attachment; filename="Spring rig feedback 3.mov" response header configured. However, the file that Zencoder produced for us doesn't have such a header.

Implemented in 01d8ad5ca296503ed315b45d027c67d258e59a63

Closing, works fine in production now.