funkwhale merge requestshttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests2019-03-26T09:45:30Zhttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/690WIP: WIP2019-03-26T09:45:30ZAgateWIP: WIPhttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/432WIP: Unprivileged docker build in CI2018-10-01T21:21:29ZAgateWIP: Unprivileged docker build in CIhttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/475WIP: Test review app2018-11-24T23:19:48ZAgateWIP: Test review apphttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/256WIP: Resolve "Use a proper json-ld parser for federation"2018-09-12T10:02:31ZAgateWIP: Resolve "Use a proper json-ld parser for federation"Closes #303Closes #303https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/639WIP: Resolve "The library view doesn't like long titles names"2019-03-04T22:41:49ZjovuitWIP: Resolve "The library view doesn't like long titles names"Closes #735Closes #735https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/368WIP: Resolve "Per-user libraries"2018-10-03T17:20:21ZAgateWIP: Resolve "Per-user libraries"Closes #463, #160, #147, #133
Relates to: #252, #453, #467, #472
Makes obsoletes: #441, #442, #394 #349, #269, #203, #92, #78, #221, #250,
This PR is rather huge, and aims at solving quite a lot of issues of the platform in its curren...Closes #463, #160, #147, #133
Relates to: #252, #453, #467, #472
Makes obsoletes: #441, #442, #394 #349, #269, #203, #92, #78, #221, #250,
This PR is rather huge, and aims at solving quite a lot of issues of the platform in its current state. It's quite opiniated, and I feel like it's important to discuss the how and why here.
## A few goals of Funkwhale
Among other things, I started Funkwhale to satisfy these main use cases:
1. Have my personal music library available on the web
2. Interact with other people around music, in a "social network"-y way (discover new artists, access music I would not have listened by myself, etc.)
I consider 1. to be basically fulfilled in the current state of the system. As an instance owner you can boot an instance, import your music and you're good to go. Of course, there are bugs and improvements and features to add around that, but the core itself is here. However, it's only fulfilled for users who have the upload permission on an instance otherwise, you are only in a consuming position, you cannot add new content.
For 2., well, it's not really the case yet. Most of the features you would expect for social discovery, such as following people, access other people activity to discover stuff, direct interaction between users, all of that is either WIP or not implemented at all.
Other the past few months, a third, equally important (at least for me) use case emerged: make Funkwhale a creator-friendly platform to broadcast music (and possibly other types of audio) and build a community around that, in a way similar to SoundCloud.
While it's theoretically possible to have open instances where creators can upload their work, the way Funkwhale is currently designed makes it harder, difficult or dangerous for instance owners to satisfy this use case. The same thing goes for use case 2., and we'll discuss why in the next part.
To sum it up, this is how Funkwhale is used or should be usable:
1. As a user, to stream music you like
2. As a user, to discover interesting content and interact around it
3. As a creator, to make your work available to other people
## The copyrighted federation paradox
Funkwhale was designed, from start, with copyrighted content in mind, and in an instance-centric fashion:
- There is one library per-instance
- All users of an instance have access to the library
Because content may be copyrighted, everything was very (too much) cautious:
- Instances are closed by default (both for signup and music streaming)
- Uploading to the instance library require special permissions
This worked in the context of small, familial or friend-based, instances but it became obvious we would have problems when we implemented federation of library contents between instances, in April 2018: this simply does not scale.
Because everything is instance-centric, as an instance owner, your are basically responsible of your instance library and it's content: who has the permission to manage it, what instances can access it. On the contrary, as a user, you have no control on anything at all: you cannot access another library if it's not federated with your instance. You cannot upload your own music if you don't have the permission.
All of this lead to the current situation:
1. Instance owners have no incentive to open their instance to new users (as Mastodon, Peertube or Pleroma instance owners could do), because it's dangerous for them if they end up streaming copyrighted content to anyone
2. Federating instances is a dangerous, all-or-nothing act of faith during which you put your trust on other instances not to be too big
3. As a result of 1. and 2., it's impossible for new users to find instances they can join, and for creators to find instances where they can upload content without hassle
This has been a huge source of frustration and incomprehension about how the project work, slowing the growth of the network, and I think it is the time to tackle these issues.
## A solution?
What if we shifted the responsibilities and power from instance owners to users, and moved (at least partially) from an instance-centric design to a user-centric design?
My proposal is quite simple, but have a lot of impact on a lot of aspects of the project (both technically and functionally). To sum it up: **let's kill the instance library, and split it in users libraries.**
As a user:
1. You have an upload quota, e.g. 500MB. You can upload files on your instance up to this quota
2. Uploaded files are stored in one of your libraries. You can create one or many libraries, that are bound to your account, and you have full control of them. During upload, you choose in which library you want to upload your files.
3. Libraries have a visibility setting:
- Private: your library is private and nobody except you can access it (metadata + streaming)
- Instance: only people on your instance can access the library content.
- Public: everybody can access the library contents, including people from other instances
4. In addition to this visibility setting, you can explicitly share a library with other people (both on your instance and other instances).
## How does it help with the mentioned issues?
User managing their own libraries has a lot of positive repercussions and unlock new use cases.
As an instance owner:
- you spend less time managing permissions and worrying about streaming copyrighted content, because you're not managing a library at all. Of course, you are still responsible to answer to take down requests if one or your users is sharing copyrighted content publicly, but this is expected when you're hosting this kind of services.
This makes it safer and easier for instance admins to open their instance completely.
As a user:
- you can upload your own music library to your instance and enjoy it without having to ask for specific permissions
- you can share your music library with friends/family or even have public libraries of open content
As a creator:
- you can upload your own work and share it publicly on the network without having to ask for specific permissions
## What are the possible issues with this proposal?
- Performance issues: introducing user libraries will necessarily have impact on the application, as we'll have more work to do to check if a user can listen to a track or not
- User experience: the current workflow is easy: every track you see is playable. This would not be the case anymore because there could be activity (listenings, favorites, comments, etc.) on tracks that are not in any library you have access to.
- Storage issues: it is not easy to deduplicate upload content in this context, and could lead to increased storage costs. This is at least partially mitigated by the quota system though.
- Feature removal/possible breakages:
- YouTube import: this feature is quite problematic because of the whole "piracy" connotation stuff. I think it is safer to remove it completely, as expose it to each and every user would only increase its visibility
- The federation, in its current state: it's not possible to offer a clean migration path for the federation between instance libraries and user libraries. This is not such a big issue since the federation is still rather small, but we have to keep that in mind.
- Music requests: since everybody can upload and nobody is responsible for a single library, there is not much sense to keep those
## Things to think about if you're still here
- Are there any current use case that will be impossible to fulfill if this proposal is implemented?
- Is there any possible issue we overlooked?
- Anything else?
## Tasks
Once all of those are checked, the work is complete:
- [x] User libraries:
- [x] Library management / deletion
- [x] File management / deletion
- [x] Improved imports:
- [x] Per user quotas
- [x] Default quota for new users
- [x] Upload to a user library
- [x] Advanced error management during import: what wen wrong, how can I fix it
- [x] Handle file replacement
- [x] Skip track (or inform) that a track is present in another library
- [x] Rework CLI with new system
- [x] Permission logic:
- [x] Library access data available in API for artists, tracks, etc.
- [x] Interface (play buttons, playlists, filters, etc.)
- [x] Handle library access in radios
- [x] Library sharing:
- [x] Request access to another library
- [x] Grant access to an owned library
- [x] Scan / import of remote libraries:
- [x] Scanning reporting
- [x] Scanning management (pause/cancel/restart)
- [x] Automatic scanning
- [x] Federation:
- [x] More generic API logic (routers, etc.)
- [x] Use AS duration field on audio
- [x] Follow/Unfollow/AP Notifications
- [x] Broadcast libraries update (deleted/visibility changed) to followers
- [x] Broadcast files update (added/deleted) to followers
- [x] Ensure cache is cleaning properly
- [x] Ensure federation preferences are honored for outbox / inbox
- [ ] Admin tools:
- [x] Modify user quota
- [ ] Disable
- [x] Cleanup:
- [x] Youtube Import
- [x] System actors, old/unused AP code
- [x] Import requests
- [ ] Documentation:
- [ ] Federation
- [ ] User libraries
- [ ] Import
- [ ] Changelog
- [x] Migration script to convert instance library to per-user libraries (and populate missing federation data such as followers url for actors, federation ids for all music entities, etc.)
- [x] Final check that things work: subsonic, federation, migration script, playlists not playable, etc.https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/285WIP: Resolve "Industrialize the i18n workflow"2018-06-30T09:35:48ZAgateWIP: Resolve "Industrialize the i18n workflow"Closes #161Closes #161https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/487WIP: Instance level moderation2019-01-10T11:00:14ZAgateWIP: Instance level moderationCf #580
(Don't mind the branch name, a lot is going on here ;)Cf #580
(Don't mind the branch name, a lot is going on here ;)https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/492WIP: In place import wont change library quota2019-07-29T08:51:17ZFloréal ToumikianWIP: In place import wont change library quotaRelated issue: #570 <!-- it's okay to have no issue for small changes -->
This Merge Request includes:
- [x] Tests
- [ ] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)Related issue: #570 <!-- it's okay to have no issue for small changes -->
This Merge Request includes:
- [x] Tests
- [ ] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1284WIP: Increase update frequency of track progress bar2021-09-27T05:01:33ZTony WasserkaWIP: Increase update frequency of track progress bar(Not too) naive attempt at addressing #1381.
Currently when playing back common audio tracks (length ~3 minutes) at a monitor resolution of 1920x1080 at 60 Hz, the progress bar will jump in steps of 10 pixels. Shorter tracks will jump e...(Not too) naive attempt at addressing #1381.
Currently when playing back common audio tracks (length ~3 minutes) at a monitor resolution of 1920x1080 at 60 Hz, the progress bar will jump in steps of 10 pixels. Shorter tracks will jump even further, since the update frequency is fixed to 1 second.
This MR changes the track progress bar to update at the display frequency, and less often only when it'd move forward by less than a pixel. The expression `Math.min(60, 1920 / this.duration)` gives us this behavior, but is hardcoded against 1080p@60Hz displays, hence updating too rarely on high end displays (4K/120Hz) and too often on phones.
Suggestions for making this resolution-independent are welcome :)
Further to the increased update frequency, player.js was rounding the track progress to 0.1% duration steps, which caused further jumpiness.
TODO:
- [ ] Make frequency updates resolution-agnostic
This Merge Request includes:
- [ ] Tests
- [x] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)1.2.0Georg KrauseGeorg Krausehttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/14WIP: Fixed #25: artist / album / track requests2018-02-24T11:10:13ZAgateWIP: Fixed #25: artist / album / track requestsAgateAgatehttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1217WIP: Compose for multi-container installation refactorized2021-05-13T04:03:48ZMeliurwenWIP: Compose for multi-container installation refactorizedRelated issue: `None`
This Merge Request includes:
- [ ] Tests
- [ ] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)
## Why
The official docker-compose works, but is written in some very...Related issue: `None`
This Merge Request includes:
- [ ] Tests
- [ ] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)
## Why
The official docker-compose works, but is written in some very questionable way;
creating serious issues in security, portability, modularity, readability and
maintenability of the entire stack. The installation is also not automated, but
requires extra steps (excluding configuration that doesn't count) to initialize
for the first time the instance.
## What changed
There has been a **_lot_** of changes, I will list the most notable ones:
### Network
+ **Before:** _(see [the appendix](###Network-Before))_
+ the containers were all under the same network which gave them internet access;
+ the `api` and `nginx` (the reverse-proxy) services were exposing to the public (using the `port` directive), respectively the `5000/tcp` and `80/tcp` ports;
+ the ports of `postgres` and `redis` were not documented (no `expose` directive used).
+ **Now:** _(see [the appendix](###Network-Now))_
+ There are _three_ distinct networks with precise purposes:
1. An internal network (no Internet access) containing all the services;
2. A network with Internet access with only the services that _really_ need it, namely: `api` and `celeryworker`;
if you want the whole app without internet access (but still reachable via web browser) set `NO_INTERNET_ACC` to `true`;
3. An optional external network to hook the `nginx` service only (in case you have a main reverse-proxy on your server).
+ the `api` and `nginx` (the reverse-proxy) services no longer expose their ports to the public, they are only documented with the `expose` directive;
+ the ports of `postgres` and `redis` services are now documented with the `expose` directive.
### Environment variables
> **Info:** read [this](https://docs.docker.com/compose/env-file/) and [this](https://docs.docker.com/compose/compose-file/#env_file) on the official Docker docs to understand the difference between `.env` file and env files imported with `env_file`.
+ **Before:**
+ All the environment variables for all services were mixed together inside the same `*.env` file (`.env`);
+ The `.env` file (which is automatically loaded by Docker Compose to be used within the `.yml` file), is also directly injected in all serivices with the `env_file` directive, exposing information to services that doesn't (and shouldn't) need it.
+ **Now:**
+ The environment variables are now separated in different files depending on the service or set of services that does need them; the `.env` file now has only variables concerning the configuration at the _stack level_, not service, except for the `FUNKWHALE_HOSTNAME` variable which is passed inside the containers via the `environment` directive.
+ The `env_file` is now used only when needed and import `*.env` files containing variables only needed for the target service.
### Other
+ Configurable paths for the volumes mounting point **_inside_** the containers has been removed, it's something that has no sense to exist and unnecessarily complicate things.
+ Has been added the possibility to configure the `restart` and `container_name` directive on all the containers.
+ Has been added the possibility to configure the **_tag_** on all services and **_image_** on some (`nginx`, `postgres`, `redis`).
+ In the `funkwhale.template` has been removed all the unnecessary variables and replaced with static paths which reflects the static volume mountpoints I set for the service.
+ The `funkwhale_proxy.conf` and `funkwhale.template` has been moved to a dedicated subfolder called `nginx`.
+ In case the system administrator has intention to hook the `nginx` service to the network of its _main_ reverse-proxy which happens to have a companion (for example [docker-gen](https://github.com/jwilder/docker-gen)) I've set some variables with dummy values already in the `nginx.env` file.
+ The directives in the `docker-compose.yml` file now are no longer sorted randomly; the order is the same for all and follows a criteria that (arguably) makes more sense.
+ Except for `DJANGO_SECRET_KEY`, `FUNKWHALE_HOSTNAME` and `REVERSE_PROXY_NETWORK` which are mandatory variables to manually set, all the optional variables are left empty in the `*.var` files by default and has a correspondent default value defined in the `docker-compose.yml` file (except for `funkwhale.env`).
+ `postgres` service image tag has been upgraded from `11` to `12.4` and `redis` from to `5` to `6`.
## What Didn't Change
+ The overall stack structure remained the same, with the same container images.
+ The name of the services (but they should be changed to a more generic ones,
like: `web`, `api`, `db`, `cache`, etc...).
+ The extra manual steps necessary to initialize for the first time the app
+ The extra manual steps necessary to partially initialize the database in case
to upgrade to a new version (tables or columns has been added/removed)
+ The extra manual steps in case of bump to a new version of the service that is
not backward compatible (for example posgres likes to break compatibility at every
major release).
## Appendix
### Network Before
![network-before](/uploads/717be8a4b7f6856fd630ab55e91282dd/network-before.png)
### Network Now
![network-now](/uploads/493d866281e9dcbf876cfb721d408f7e/network-now.png)https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/515WIP: Begin work on "Multiple track artists"2019-06-17T07:53:33ZAuriWIP: Begin work on "Multiple track artists"Related issue: #646 <!-- it's okay to have no issue for small changes -->
## To-Do
- [X] Write TrackCredit model and serializer
- [X] Write migrations for TrackCredit
- [ ] Reimplement majority of `funkwhale_api.music.metadata` t...Related issue: #646 <!-- it's okay to have no issue for small changes -->
## To-Do
- [X] Write TrackCredit model and serializer
- [X] Write migrations for TrackCredit
- [ ] Reimplement majority of `funkwhale_api.music.metadata` to account for
- [ ] Tags with multiple fields and values
- [ ] Tags with multiple list delimiters and preprocessors (i.e. `feat. Artist` -> `TrackCredit(type=FEATURED, artist=Artist)`)
- [ ] Refactor code using `class Metadata` to be in line with changes
- [ ] `api/tests/music/test_{metadata,tasks}.py`
- [ ] `api/funkwhale_api/music/{tasks,models}.py`
- [ ] Test importer on decently big library
- [ ] Resolve linter errors
This Merge Request includes:
- [ ] Tests
- [ ] Model, serializer
- [ ] New tasks
- [ ] Metadata scanner
- [ ] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/990WIP: Add Electron support2020-07-08T15:35:37ZCreakWIP: Add Electron support_Disclaimer: I am discovering both Electron and the Funkwhale code base at the same time, any help would be greatly appreciated! :wink:_
This MR is based on !853.
Closes #896
### ToDo
- [ ] Add media keys for Linux
- [ ] Add..._Disclaimer: I am discovering both Electron and the Funkwhale code base at the same time, any help would be greatly appreciated! :wink:_
This MR is based on !853.
Closes #896
### ToDo
- [ ] Add media keys for Linux
- [ ] Add app name (currently it's "front")
- [ ] Add the app to the systray
- [ ] Add notifications
- [ ] Add functionality to choose your remote server through the front end
- [ ] Tests
### Done
- [x] Decouple the Electron dependencies and code from the web app
- [x] Add Funkwhale icon
- [x] Add Electron
- [x] A changelog fragment
## Setup
From [CONTRIBUTING.rst](https://dev.funkwhale.audio/creak/funkwhale/-/blob/896-add-electron-support/CONTRIBUTING.rst):
> Install Electron-related dependencies:
>
> yarn electron:install
>
> Run the app in development mode:
>
> yarn electron:serve
>
> Build a production version of the app:
>
> yarn electron:build
>
> Run the app built with ``yarn electron:build``:
>
> ./dist_electron/front-0.1.0.AppImage
### Connect to a specific server
In order to test the Electron application with your server, you need to set the `WEBPACK_DEV_SERVER_URL` environment variable. Like this:
WEBPACK_DEV_SERVER_URL=https://funkwhale.yourdomain.com yarn electron:serve
Or
WEBPACK_DEV_SERVER_URL=https://funkwhale.yourdomain.com ./dist_electron/front-0.1.0.AppImage
https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/947WIP: Added Snyk dependency testing to API2019-11-06T09:15:04ZAgateWIP: Added Snyk dependency testing to API- [ ] Scan an report security vulnerabilities in Python dependencies
- [ ] Scan an report security vulnerabilities in javascript dependencies- [ ] Scan an report security vulnerabilities in Python dependencies
- [ ] Scan an report security vulnerabilities in javascript dependencieshttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/583WIP: Add contexts to translatable strings (OVERVIEW)2019-02-09T15:11:37ZjovuitWIP: Add contexts to translatable strings (OVERVIEW)This MR is to keep an eye on the work on the contextualisation of all strings on the front-end. Related to #662 and !581
The formatting of the context strings has to follow !581. One MR for each .vue file will be created to avoid hav...This MR is to keep an eye on the work on the contextualisation of all strings on the front-end. Related to #662 and !581
The formatting of the context strings has to follow !581. One MR for each .vue file will be created to avoid having a huge MR with lots of conflicts...
Tracking of the contextualisation work (MR will be added appended to each file when it is created):
* [ ] ./views/playlists/Detail.vue
* [ ] ./views/playlists/List.vue
* [ ] ./views/admin/users/Base.vue
* [ ] ./views/admin/users/InvitationsList.vue
* [ ] ./views/admin/users/UsersList.vue
* [ ] ./views/admin/library/Base.vue
* [ ] ./views/admin/library/FilesList.vue
* [ ] ./views/admin/Settings.vue
* [ ] ./views/admin/moderation/AccountsDetail.vue
* [ ] ./views/admin/moderation/Base.vue
* [ ] ./views/admin/moderation/DomainsList.vue
* [ ] ./views/admin/moderation/AccountsList.vue
* [ ] ./views/admin/moderation/DomainsDetail.vue
* [ ] ./views/Notifications.vue
* [ ] ./views/auth/EmailConfirm.vue
* [ ] ./views/auth/PasswordReset.vue
* [ ] ./views/auth/PasswordResetConfirm.vue
* [ ] ./views/content/remote/ScanForm.vue
* [ ] ./views/content/remote/Card.vue
* [ ] ./views/content/remote/Home.vue
* [ ] ./views/content/Base.vue
* [ ] ./views/content/Home.vue
* [ ] ./views/content/libraries/FilesTable.vue
* [ ] ./views/content/libraries/Detail.vue
* [ ] ./views/content/libraries/DetailArea.vue
* [ ] ./views/content/libraries/Files.vue
* [ ] ./views/content/libraries/Card.vue
* [ ] ./views/content/libraries/DetailMixin.vue
* [ ] ./views/content/libraries/Home.vue
* [ ] ./views/content/libraries/Quota.vue
* [ ] ./views/content/libraries/Upload.vue
* [ ] ./views/content/libraries/Form.vue
* [ ] ./views/radios/Detail.vue
* [ ] ./components/playlists/Editor.vue
* [ ] ./components/playlists/TrackPlaylistIcon.vue
* [ ] ./components/playlists/Card.vue
* [ ] ./components/playlists/Widget.vue
* [ ] ./components/playlists/PlaylistModal.vue
* [ ] ./components/playlists/CardList.vue
* [ ] ./components/playlists/Form.vue
* [ ] ./components/audio/artist/Card.vue
* [x] ./components/audio/PlayButton.vue (!581)
* [ ] ./components/audio/SearchBar.vue
* [ ] ./components/audio/EmbedWizard.vue
* [ ] ./components/audio/album/Card.vue
* [ ] ./components/audio/album/Widget.vue
* [ ] ./components/audio/track/Table.vue
* [ ] ./components/audio/track/Row.vue
* [ ] ./components/audio/track/Widget.vue
* [ ] ./components/audio/Search.vue
* [ ] ./components/audio/Track.vue
* [ ] ./components/audio/Player.vue
* [ ] ./components/utils/global-events.vue
* [ ] ./components/admin/SettingsGroup.vue
* [ ] ./components/manage/users/InvitationsTable.vue
* [ ] ./components/manage/users/InvitationForm.vue
* [ ] ./components/manage/users/UsersTable.vue
* [ ] ./components/manage/library/FilesTable.vue
* [ ] ./components/manage/moderation/AccountsTable.vue
* [ ] ./components/manage/moderation/InstancePolicyForm.vue
* [ ] ./components/manage/moderation/DomainsTable.vue
* [ ] ./components/manage/moderation/InstancePolicyCard.vue
* [ ] ./components/library/FileUpload.vue
* [ ] ./components/library/FileUploadWidget.vue
* [ ] ./components/library/Artist.vue
* [ ] ./components/library/Radios.vue
* [ ] ./components/library/Artists.vue
* [ ] ./components/library/Home.vue
* [ ] ./components/library/Track.vue
* [ ] ./components/library/radios/Builder.vue
* [ ] ./components/library/radios/Filter.vue
* [ ] ./components/library/Album.vue
* [ ] ./components/library/Library.vue
* [ ] ./components/notifications/NotificationRow.vue
* [ ] ./components/auth/Settings.vue
* [ ] ./components/auth/Logout.vue
* [x] ./components/auth/Signup.vue (!581)
* [ ] ./components/auth/SubsonicTokenForm.vue
* [ ] ./components/auth/Profile.vue
* [ ] ./components/auth/Login.vue
* [ ] ./components/mixins/Ordering.vue
* [ ] ./components/mixins/SmartSearch.vue
* [ ] ./components/mixins/Translations.vue
* [ ] ./components/mixins/Pagination.vue
* [ ] ./components/About.vue
* [ ] ./components/Logo.vue
* [ ] ./components/Footer.vue
* [ ] ./components/forms/PasswordInput.vue
* [ ] ./components/metadata/CardMixin.vue
* [ ] ./components/metadata/ReleaseCard.vue
* [ ] ./components/metadata/ArtistCard.vue
* [ ] ./components/metadata/Search.vue
* [ ] ./components/Pagination.vue
* [ ] ./components/instance/Stats.vue
* [ ] ./components/ServiceMessages.vue
* [ ] ./components/Home.vue
* [ ] ./components/favorites/List.vue
* [ ] ./components/favorites/TrackFavoriteIcon.vue
* [ ] ./components/common/UserLink.vue
* [ ] ./components/common/Duration.vue
* [ ] ./components/common/Message.vue
* [ ] ./components/common/ActorAvatar.vue
* [ ] ./components/common/Tooltip.vue
* [ ] ./components/common/AjaxButton.vue
* [ ] ./components/common/DangerousButton.vue
* [ ] ./components/common/CopyInput.vue
* [ ] ./components/common/Username.vue
* [ ] ./components/common/HumanDate.vue
* [ ] ./components/common/ActionTable.vue
* [ ] ./components/common/ActorLink.vue
* [ ] ./components/Sidebar.vue
* [ ] ./components/semantic/Modal.vue
* [ ] ./components/radios/Button.vue
* [ ] ./components/radios/Card.vue
* [ ] ./components/ShortcutsModal.vue
* [ ] ./components/federation/LibraryWidget.vue
* [ ] ./components/PageNotFound.vue
* [ ] ./Embed.vue
* [ ] ./App.vuehttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1143WIP: #1097 LDAP Group Type Support fix typo2021-01-09T04:19:35ZZwordiWIP: #1097 LDAP Group Type Support fix typoRelated issue: #1097
This Merge Request includes:
- [ ] Tests
- [X] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)
As it’s default options from Django i didn’t make a test, but i can if...Related issue: #1097
This Merge Request includes:
- [ ] Tests
- [X] A changelog fragment (cf https://docs.funkwhale.audio/contributing.html#changelog-management)
As it’s default options from Django i didn’t make a test, but i can if requested.https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/96WIP2018-03-20T14:08:10ZAgateWIPhttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1359Version bump and changelog for 1.1.4 on develop2021-08-10T20:19:39ZJuniorJPDJVersion bump and changelog for 1.1.4 on develop@georgkrause forgot to bump on develop after doing bugfix releae@georgkrause forgot to bump on develop after doing bugfix releaehttps://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/1223Use higher-resolution variant of album covers in track queue2020-09-14T11:31:16ZTony WasserkaUse higher-resolution variant of album covers in track queueDisclaimer: This is UNTESTED, and I had to make an educated guess about which file to edit since I don't have a FW dev setup on this machine right now.
I noticed that when expanding the play queue, the current album cover would be shown...Disclaimer: This is UNTESTED, and I had to make an educated guess about which file to edit since I don't have a FW dev setup on this machine right now.
I noticed that when expanding the play queue, the current album cover would be shown at about 450x450, yet only the 200x200 version of it would be fetched from the server. This of course causes ugly artifacts, hence let's use the higher-resolution image instead.