Various feature and config requests #605
Replies: 2 comments 2 replies
-
Hi @ty5e3a45, I will carefully read your comments and reply to each point. We want to release the version 3.0.0 soon (hopefully this month) and start collecting feedback for the roadmap. So it's the perfect timing for your suggestions. Most of them are very easy to implement and some have already been implemented like "remove email requirement for account creation". Some of them are similar to other feature requests like #542. |
Beta Was this translation helpful? Give feedback.
-
Hi @ty5e3a45, my full reply:
Can you give a list of the most important ones for you. I guess:
That option already exists. With this configuration, the email is not required: [registration.email]
required = false
verification_required = false If you totally remove the section
Yes, the user public profile and settings are essential. I will create an EPIC for that. We only allow users to change their passwords now.
Can I ask why? I guess it's fine to have an option to disable them.
In general, I prefer this type of choice to be an end-user choice. When we have a user's settings page, that could be a customization option. Or do you want to force it on all users for some reason?
Same as point 5.
I don't see any reason to not include a flag in the configuration for this. Maybe this should be a dynamic configuration, meaning you can change it without restarting the service from the admin panel. I would like to make the TOML config file to big or complex. I would prefer to have feature flags or a configuration panel for the admin. Anyway, I don't there is too much info yet. But I can't understand why there could be cases where you don't need/use it.
That was a controversial feature :-). I'm unsure if this should be a user or an admin choice. It's too low-level, maybe, to be a user setting.
I guess your problem is the critical info is at the bottom :-/.
It could be a user option. A user asked for quite the opposite.
Now, we are using both:
Can you have multiple aliases for the same resource, or would you like to enable/disable some of them? And why does it depend on the amount of torrents? Adding more aliases should be easier, although it requires rewriting URLs to something like:
We could also build a single URL with all values:
Why do you want this? I would prefer to keep it simple.
Yes, there are a lot of UI improvements to do. In general, I see these main topics:
I think you could create discussions for points 1 and 2. Even if they are sometimes related, it will make it easier to follow discussions. Regarding point 3, I would like a UX/UI expert to review the whole design, including how to add new potential features like more complex/flexible search filters. For minor fixes like the one you mentioned we can just create new issues (bugs). |
Beta Was this translation helpful? Give feedback.
-
Hey,
Opening a discussion to not clog up issues with requests that might already be implemented.
If worthy of opening an issue for any of the following, let me know.
torrent/{infohash}/torrent-name
. Option to have it betorrent/{infohash}
,torrent/torrent-name
,torrent/{incremental number}
,torrent/{custom-name}
, etc. depending on amount and type of torrents hosted on site.Preview:
Thanks,
Beta Was this translation helpful? Give feedback.
All reactions