Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content

Feature Requests

New ideas, Feature Requests

654 Topics 5.1k Posts
  • 1 Votes
    20 Posts
    734 Views
    girishG

    @robi @timconsidine good catch, I don't think it is. Will fix. Opened https://git.cloudron.io/cloudron/box/-/issues/832 to track internally

  • Security: restrict access to cloudron apps

    3
    3 Votes
    3 Posts
    204 Views
    potemkin_aiP

    @girish

    The footer is actually used in the login screen (in 7.5.1) . It's not a place to put some private information.

    Probably, it's worth to mention that at the customization page?

    I agree with restricting access to dashboard/apps though.

    Glad to hear that! Do you believe that could make it to the roadmap anytime soon?

  • Dashboard Organization

    15
    6 Votes
    15 Posts
    474 Views
    P

    I was going to suggest something similar: Drag and drop with folders/directories aka like a file system view

  • Make IPv6 optional per app / domain

    Moved
    3
    1 Votes
    3 Posts
    83 Views
    C

    No technical reason as far as I can tell, just apparently no interest on the part of the provider! It is probably a very infrequent need and in our case this only affects a subdomain of one domain that is currently hosted by the same provider of the DNS. Ultimately the website will be moved but I need the subdomain for staging.

  • Suggestion for prereleases

    Solved
    11
    12 Votes
    11 Posts
    381 Views
    d19dotcaD

    @girish said in Suggestion for prereleases:

    Some are updating to pre-release on production instances (despite the warnings about unstable) and expecting fixes quickly. To us, quickly even means 1 month.

    Just to clarify from my perspective a couple of things and add my two cents...

    Pre-releases in the past have nearly always gone very smoothly (which is awesome! 🙂 ) and I suspect this is why more and more people are open to running the pre-release builds even on production instances, because major issues are thankfully so rare. Combine that with long-awaited features or fixes users have been eager for, it's all a great incentive for more users to test out the pre-release. And personally I think that's a really good situation to have experienced users on the pre-release as we've been able to help the Cloudron team identify many issues that likely would not have been caught as soon otherwise. This helps improve then Cloudron product for everyone. I think there's perhaps a difference of opinion with different users and Cloudron team on what "quickly" means to them. In most of the software I use (and I suspect this applies to others too), software updates are often seen every 1-3 weeks especially soon after a major version release since they tend to be more buggy and need an initial bug fix patch released quickly rather than waiting for the next major release months later. On top of that, I think part of the "quick release" expectation by some users comes from seeing how quickly fixes are completed by the amazing Cloudron team here when we report issues, often fixed in 24-48 hours or less I find, so when we see that being so quick then waiting 1-2+ months for the fix just seems understandably unusual or unexpected.

    @girish said in Suggestion for prereleases:

    Cloudron is really like an OS, there are lots of packages, docker images and deps and is not a simple tarball on github and let the user figure it out. As a comparison, there is a reason distros are not pushing new releases every week or two.

    While I tend to agree, even on an OS distro there is usually an easy way to get later versions of various applications. This isn't something that's possible in Cloudron currently so we're more reliant on the "OS" (aka Cloudron) here for bug fixes.

    @girish said in Suggestion for prereleases:

    Providing a way to update to unstable easily (just click a button) and then not providing fixes quickly is bound to disappoint at some point and it seems that point is now given this is upvoted a bit.

    Maybe something to consider... two different branches. Pre-release and stable. Users can pick which one they want to run on their systems, and pre-releases get updates every 1-2 weeks perhaps, and stable every few months or whenever a new release is ready and considered stable. More and more software applications seem to be doing it this way, such as 1Password for example and nearly any browser, and more. This might satisfy those users who want to stick to stable releases and those who want quicker bug fixes and such and enjoy reporting issues on pre-release software to better help the Cloudron community. I see this also as an opportunity for Cloudron to grow better quicker by getting more rapid feedback from experienced users. 🙂

    @girish said in Suggestion for prereleases:

    As a lesson, we will become more conservative about pre-releases i.e we will release only after we have tested extensively ourselves and also completed the features. This is how we did it before and we actually didn't have many complaints. We only implemented pre-releases because people were enthusiastic to test early and seems like this is more trouble than it's worth.

    I tend to disagree on this one. In software - as you're well aware - beta testing is a critically important piece of the development cycle so that the final release is as least-buggy as possible. I know Cloudron used to beta test with only new deployments of Cloudron installs back in the day if I recall correctly, but the unfortunate part of that is that it isn't targeting the advanced users who want to test and report these types of issues encountered (I'm guessing most people installing Cloudron who would unknowingly get the new release would be newer users).

    I think the Cloudron team should really embrace the beta testing / pre-release process and embrace working with experienced users in the forum here who are actively testing and reporting issues and enjoy helping improve the software with the fantastic Cloudron team. Tightening the process up I fear will only make things worse / more buggy before the final release as more things may go uncaught. You've got a good amount of people willing to test the product for you for basically free, why not take advantage it? It may create more bug reports which in-turn may be more work, sure, but that's a good thing IMO because they may otherwise go unnoticed and will then be sure to improve it for those who are not willing to beta test.

    Side note: Maybe calling it a "beta" or even an "alpha" may be better because pre-release to some people implies it's close to a "release candidate" which in-turn implies it should be fairly stable. If the Cloudron team doesn't want so many people testing, then perhaps naming it as "beta" will give some users a bit more pause on installing it and only those experienced would be more willing to do it.

    I know that's a long write-up (I offer my typical Canadian apology, lol), but I hope you can tell that I've given this a lot of thought and I hope that some of the notes above will be considered for how to handle releases in the future. 🙂 I'm always happy to discuss further if any questions at all.

  • Notifications on success/failure/pending

    Solved
    9
    2 Votes
    9 Posts
    390 Views
    LanhildL

    +1 for dashboard webhook notifications

  • 1 Votes
    9 Posts
    525 Views
    H

    Ok, thanks for the update. Works for me as it is, but was curious if the ideas discussed above are still to be implemented.

  • 1 Votes
    1 Posts
    326 Views
    No one has replied
  • 0 Votes
    3 Posts
    100 Views
    D

    Thank you

  • 0 Votes
    9 Posts
    152 Views
    marcusquinnM

    Cloudron community teamwork wins again 🙂 🤜🤛 🙂

  • Backups block all other app actions

    3
    4 Votes
    3 Posts
    85 Views
    girishG

    IIRC, the reason for this is we had a global lock. This is not true anymore so there is probably no reason to block operations anymore. I have to investigate.

  • 3 Votes
    5 Posts
    139 Views
    W

    Looks good and prevents issues like looking wrong in a short sight. Thanks!

  • 0 Votes
    1 Posts
    58 Views
    No one has replied
  • 5 Votes
    6 Posts
    407 Views
    potemkin_aiP

    If anyone would be searching for that, unsend mail is stored at /home/yellowtent/boxdata/mail/haraka-queue - handy when your 25 port is firewalled.

  • File Browser column sorting

    Solved
    3
    5 Votes
    3 Posts
    92 Views
    nebulonN

    This is now implemented.

  • 1 Votes
    3 Posts
    141 Views
    KubernetesK

    @nebulon Amazing! Exactly what I was looking for. Thanks!

  • allow for onion domain support

    10
    5 Votes
    10 Posts
    240 Views
    adisonA

    however, i have tryed to follow the docs.
    however, when trying to get into a test application i made for this perpus, it didn't work and it kept telling me that it didn't exist, even when typing in the12diget ID. i couldn't bash into it. so yeah. and if i attempted to put this on the system itself, that could cause many problems, or potentially break cloudron.

  • Add BIMI support to Mailserver

    16
    3 Votes
    16 Posts
    478 Views
    robiR

    @girish
    Not looking good: https://community.letsencrypt.org/t/verified-mark-certificates/176835/9

  • 0 Votes
    6 Posts
    121 Views
    robiR

    @nebulon said in Filemanager Drag'n'drop folder trees does not work:

    Ah I guess you mean the github repo for drag'n'drop! So we use vuejs with the primevue components set in the new views, moving away from the now unsupported angularjs v1.

    Yes, https://github.com/jhiesey/drag-drop

  • don't let webserver respond

    9
    0 Votes
    9 Posts
    262 Views
    fbartelsF

    @adison it reads "You are seeing this page because the DNS record of $host is set to this server's IP but Cloudron has no app configured for this domain." But instead of $host its the ip or dns name you just requested.