* 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
* add Content Security Policy
* remove reflect-metadata on production builds to get rid of unsafe-eval
* fix baseCSP usage
* add SRI to CSP
* add blob: to media-src
* remove SRI
* CSP set to reportOnly
* adding data: to connect-src CSP
* remove block-all-mixed-content
* add report-uri support
* Remove hard-coded 8GB upload limit in client
Ideally we'd know what the specific server's configured upload limit
is before starting, but this 8GB limit is not useful if an administrator
has changed the nginx post limit on the server.
* Better docs for admins about client_max_body_size
Seems like some admins already tweak this value up or down to allow
for different maximum video upload sizes. The current codebase has no
other server-side limits that I'm aware of, and I've been routinely
uploading quite large videos to my instance.
This patch replaces the somewhat incorrect (or outdated?) 'hard limit'
comment with some advice about allocating enough space for nginx and
communicating the limit with your users.
Of course it would be better if this configuration could be unified with
PeerTube's config somehow. I'm not sure whether the best option there is
to turn off nginx's buffering here and let PeerTube handle the entire upload
(can we do this only for the video upload API endpoint?) or whether we want
PeerTube to generate nginx configs in a more automated way layer. In any case,
this patch is intended as an incremental improvement.
* make username, display_name and video_channel_name min length 1 and max length 50; (fixes#1263);
! still some bug on the frontend complains but if you remove the disabled property it creates the account just fine;
allow for usernames to start with a number;
fix test, since username can be 1 char now make test check empty;
fix test, Should fail with a too long username;
fix test, Should fail with a too small username;
fix regular expression for username and videoChannel;
change username, videoChannel to be lowercase and fix message;
* change 1 characters to 1 character
* 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
* fix migrations to not use config constant values as it can introduce bugs later when they change; (fixes#1259)
remove constant fields imports from migrations
* add migrations to update description and support fields to 1000 (fixes#1258)
* fix client/server account and video_channel description/support fields to be max len 1000 (fixes#1258);
fix test Should fail with a too long description;
fix test Should fail with a long description;
fix test Should fail with a long description;
Remove USER.SUPPORT from constants since that field no longer exists;
null not false, in migrations/0280-description-support.ts;
video support field 1000, oops;
* rename migration 0280-description-support.ts -> 0285-description-support.ts;
update video support maxlength text
this enables the `noImplicitAny` flag in the Typescript compiler
> When the noImplicitAny flag is true and the TypeScript compiler cannot infer the type, it still generates the JavaScript files, but it also reports an error. Many seasoned developers prefer this stricter setting because type checking catches more unintentional errors at compile time.
closes: #1131
replaces #1137
* Add explicit error message that changing video ownership only works with local accounts
* Remove superfluous logger
* Remove unneeded end() to error responses
* Add a message on client side to prevent transfering ownership to a remote account
If you leave the form but the 2 password is different a big red
boxappears to warn you (no need to click on the button).The submit
buttonis desactivated if the 2 password isn't the same.
* [#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
* Separated "Other Videos" section into a dedicated component/service
I'm currently working on some proof-of-concepts for recommendation
providers that could work with PeerTube to provide useful video
suggestions to the user.
As a first step, I want to have great clarity about how PeerTube,
itself, will surface these videos to the user.
With this branch, I'm refactoring the "recommendations" to make it
easier to swap out different recommender implementations quickly.
Stop recommender from including the video that's being watched.
Ensure always 5 recommendations
* Treat recommendations as a stream of values, rather than a single async value.
* Prioritize readability over HTTP response size early-optimization.
* Simplify pipe