Both 'video-encoder' and 'admin' roles get 'encode-video' capability,
which allows users to upload video that gets encoded & displayed as a
video. For users without this capability videos are handled as regular
downloads.
Added this button in the /u/ user/embed view, so that admins can easily force a re-check from Blender ID without requiring the user themselves to perform any actions.
Instead of performing a call to the Blender Store, call to Blender ID to
get the user's subscription status.
Currently this is performed as a second HTTP call after logging in; in the
future we may want to include the roles in the login response from Blender
ID, so that we can do this in one call instead of two.
Before this, authentication tokens were kept in the database, even when
someone logged out. This is unwanted behaviour, as logging in will create
yet another token anyway there is no reason to keep the token around.
This allows us to remove the require_roles kwarg at some point, ensuring
that it doesn't fall back to assigning to require_cap instead when that
happens. It's also more explicit everywhere, so it's clearer when we check
for roles or caps.
- Optimize JPEGs and increase quality from 75 to 95
- Don't always convert to RGB, first check if RGBA and save as PNG optimized
Thanks to Dr. Sybren and Francesco for review and feedback
There can be a KeyError accessing permission['methods'], but our current
logging doesn't provide enough information as to determine when this
happens. Rather than bluntly fixing the issue, I added logging to try and
find out how we get a 'methods'-less permission dict in the first place.
This makes it easier to see what the Celery worker is actually working on
when refreshing a large number of links.
It'll report on every N refreshed links, where N = link_count/25 but
clamped to N ∈ [5, 100]
This should be hidden in the UI as well, but the backend should support this too.
We also want to set initial rating of 1 for contents that need it.
This commit includes a new unittest for this case.
Reviewers: sybren
Differential Revision: https://developer.blender.org/D2825
This mimicks the behaviour of flask_login. In our case, it only redirects
when redirect_to_login=True and the user is anonymous. Otheriwse it still
results in a 403 Forbidden response.
Setting flask_login.current_user ourselves was a bad idea, and messed up
flask_login's internal administration. Our code now just manages
g.current_user in these specific instances, which works fine.
- No more direct access to g.current_user, unless unavoidable.
- Using pillar.auth.current_user instead of g.current_user or
flask_login.current_user.
- p.a.current_user is never checked against None.
- p.a.current_user.is_authenticated or is_anonymous is used, and never
together with a negation (instead of 'not is_anon' use 'is_auth').
- No more accessing current_user a a dict.
- No more checks for admin role, use capability check instead.
