Add better control for users of comments displayed on their videos:
* Do not forward comments from muted remote accounts/servers (muted by the current server or by the video owner)
* Do not list threads and hide replies (with their children) of accounts/servers muted by the video owner
* Hide from RSS comments of muted accounts/servers by video owners
Use case:
* Try to limit spam propagation in the federation
* Add ability for users to automatically hide comments on their videos from undesirable accounts/servers (the comment section belongs to videomakers, so they choose what's posted there)
* Add thumbnails generation on the fly to URL import
* Display generated preview to import first edit
* Use ternary to get type inference
* Move preview/thumbnail test just after import
Co-authored-by: kimsible <kimsible@users.noreply.github.com>
* Add video file metadata via ffprobe
* Federate video file metadata
* Add tests for file metadata generation
* Complete tests for videoFile metadata federation
* Lint migration and video-file for metadata
* Objectify metadata from getter in ffmpeg-utils
* Add metadataUrl to all videoFiles
* Simplify metadata API middleware
* Load playlist in videoFile when requesting metadata
* Creating a user with an empty password will send an email to let him set his password
* Consideration of Chocobozzz's comments
* Tips for optional password
* API documentation
* Fix circular imports
* Tests
This patch adds an audio-only option to PeerTube by means of a new transcoding configuration which creates mp4 files which only contain an audio stream. This new transcoder has a resolution of '0' and is presented in the preferences and in the player resolution menu as 'Audio-only' (localised). When playing such streams the player shows the file thumbnail as background and disables controls autohide.
Audio-only files can be shared and streamed just like any other file. They can be downloaded as well, the resulting file will be an mp4 container with a single audio stream.
This patch is a proof of concept to show the feasibility of 'true' audio-only support. There are better ways of doing this which also enable multiple audio streams for a given video stream (e.g. DASH) but as this would entail a fundamental change in the way PeerTube works it is a bridge too far for a simple proof of concept.
* Start working on autoplay of next video
* Ignore changes made by gitpod
* Apply changes from PR#1370
* Correct the spelling of recommendations
* Fix linting errors
* Move boolean check to existing onEnded handler
* Pick a random video until the recommendations are improved
* Add simple tests for autoPlayNextVideo
* Fix lint
...again
* #1915 Add a subject to contact form and add it to email sent
* #1915 Add subject to contact form tests
* #1915 Contact form test corrected && tslint correction
* Add ability to set the user display name
* Use display name to guess the username/channel name
* Add explanations about what is the purpose of a username/channel name
* Add a loader at the "done" step
* Add /users/me/videos/ratings endpoint
* Move ratings endpoint from users to accounts
* /accounts/:name/ratings: add support for rating= and sort=
* Restrict ratings list to owner
* Wording and better way to ensure current account
* add quarantine videos feature
* increase Notification settings test timeout
to 20000ms. was completing 7000 locally but timing out
after 10000 on travis
* fix quarantine video test issues
-propagate misspelling
-remove skip from server/tests/client.ts
* WIP use blacklist for moderator video approval
instead of video.quarantine boolean
* finish auto-blacklist feature
* Get the INTERVAL_DAYS const in the video-trending component
* Change Trending section title
* Add a tooltip to explain how trending section works
* Minor CSS fix for the my-feed popover next to the titlepage
* enable email verification by admin
* rename/label to set email as verified
to be more explicit that admin is not sending
another email to confirm
* add update user emailVerified check-params test
* make user.model emailVerified property required
* [#510] Create a new route to get the list of user names
To be able to transfer ownership to a user,
we need to be able to select him from the list of users.
Because the list could be too big, we add a autocomplete feature.
This commit does the following:
* Add a API endpoint to get a list of user names by searching its name
* [#510] The user can choose the next owner of the video
To be able to transfer ownership to a user,
we need the owner to be able to select the user.
The server can autocomplete the name of the user to give the ownership.
We add a dialog for the user to actually select it.
This commit does the following:
* Create a modal for the owner to select the next one
* Opens this modal with a button into the menu *more*
* Make the dependency injection
* [#510] When the user choose the next owner, create a request in database
For the change of ownership to happen, we need to store the temporary requests.
When the user make the request, save it to database.
This commit does the following:
* Create the model to persist change ownership requests
* Add an API to manage ownership operations
* Add a route to persist an ownership request
* [#510] A user can fetch its ownership requests sent to him
To be able to accept or refuse a change of ownership,
the user must be able to fetch them.
This commit does the following:
* Add an API to list ownership for a user
* Add the query to database model
* [#510] A user can validate an ownership requests sent to him - server
The user can accept or refuse any ownership request that was sent to him.
This commit focus only on the server part.
This commit does the following:
* Add an API for the user to accept or refuse a video ownership
* Add validators to ensure security access
* Add a query to load a specific video change ownership request
* [#510] A user can validate an ownership requests sent to him - web
The user can accept or refuse any ownership request that was sent to him.
This commit focus only on the web part.
This commit does the following:
* Add a page to list user ownership changes
* Add actions to accept or refuse them
* When accepting, show a modal requiring the channel to send the video
* Correct lint - to squash
* [#510] PR reviews - to squash
This commit does the following:
* Search parameter for user autocompletion is required from middleware directly
* [#510] PR reviews - to squash with creation in database commit
This commit does the following:
* Add the status attribute in model
* Set this attribute on instance creation
* Use AccountModel method `loadLocalByName`
* [#510] PR reviews - to squash with fetch ownership
This commit does the following:
* Add the scope `FULL` for database queries with includes
* Add classic pagination middlewares
* [#510] PR reviews - to squash with ownership validation - server
This commit does the following:
* Add a middleware to validate whether a user can validate an ownership
* Change the ownership status instead of deleting the row
* [#510] PR reviews - to squash with ownership validation - client
This commit does the following:
* Correct indentation of html files with two-spaces indentation
* Use event emitter instead of function for accept event
* Update the sort of ownership change table for a decreasing order by creation date
* Add the status in ownership change table
* Use classic method syntax
* code style - to squash
* Add new user right - to squash
* Move the change to my-account instead of video-watch - to squash
As requested in pull-request, move the action to change ownership into my videos page.
The rest of the logic was not really changed.
This commit does the following:
- Move the modal into my video page
- Create the generic component `button` to keep some styles and logic
* [#510] Add tests for the new feature
To avoid regression, we add tests for all api of ownership change.
This commit does the following:
- Create an end-to-end test for ownership change
- Divide it to one test per request
* [#510] Do not send twice the same request to avoid spam
We can send several time the same request to change ownership.
However, it will spam the user.
To avoid this, we do not save a request already existing in database.
This commit does the following:
- Check whether the request exist in database
- Add tests to verify this new condition
* [#510] Change icons
Change icons so they remains logic with the rest of the application.
This commit does the following:
- Add svg for missing icons
- Add icons in `my-button` component
- Use these new icons
* [#510] Add control about the user quota
The user should be able to accept a new video only if his quota allows it.
This commit does the following:
- Update the middleware to control the quota
- Add tests verifying the control
* Correct merge
- Use new modal system
- Move button to new directory `buttons`
* PR reviews - to squash
* add user account email verificiation
includes server and client code to:
* enable verificationRequired via custom config
* send verification email with registration
* ask for verification email
* verify via email
* prevent login if not verified and required
* conditional client links to ask for new verification email
* allow login for verified=null
these are users created when verification not required
should still be able to login when verification is enabled
* refactor email verifcation pr
* change naming from verified to emailVerified
* change naming from askVerifyEmail to askSendVerifyEmail
* undo unrelated automatic prettier formatting on api/config
* use redirectService for home
* remove redundant success notification on email verified
* revert test.yaml smpt host
Chocobozzz
Rigel Kent
Kim
kimsible
John Livingston
Julien Maulny
frankdelange
LoveIsGrief
Frank Sträter
Nassim Bounouas
LiPeK
Yohan Boniface
Josh Morel
Andrés Maldonado
Aurélien Béranger
clementbrizard
Lucas Declercq
Gaëtan Rizio