Thanks @nebulon for the quick answer. It does look like you are shipping a more recent version than the internal version number suggests. We'll have another go at it tomorrow to try to figure out why the Cloudron version reports an earlier version number than
CustomContentBundle-2.2.0 and
CustomContentBundle-2.3.0 allow.
foliovision
Posts
-
Custom Content plugin requires build Kimai 20100 or 20500 -
Custom Content plugin requires build Kimai 20100 or 20500@girish I hope you are keeping well.
We use Kimai in production and would like to add the Custom Content plugin to improve some js quickly. We thought it would be an easy job and were delighted to pay for the plugin.
Imagine our disappointment when we managed to take down our Kimai server. It turns out that
CustomContentBundle-2.2.0 requires Kimai build 20100, while
CustomContentBundle-2.3.0 requires Kimai build 20500.The Cloudron Kimai build is back at 20031 (a.k.a. 2.0.33). We have autoupdates enabled and manually updated to make sure we have the very latest Cloudron version installed. Strangely the package version is org.kimai.cloudronapp@2.1.3 which sounds like 20130 which would be enough to allow us to install
CustomContentBundle-2.2.0.Could you look into the Kimai package and see if we can't get the latest version down the pipe? I know there were some breaking changes with v2 but these are not major version updates (that's behind us) but just improvements to Kimai 2.x.
Thanks, Alec
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@nebulon said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
In an ideal world, we would probably hide that UI to avoid all this, but we are not the developers of those apps and contributing upstream
This is a backwards approach. It would be completely in Cloudron's control to check the .env variables for every app. If those variables change, Cloudron should:
- notify the admin user with a screen on first startup alerting the user that key variables have changed (which ones)
- send an email to the admin user alerting the user that key variables have been changed
I don't think local admins should have control over database settings but we should certainly be alerted if they are being changed back and forth.
It would also be very simple to allow users to enable or disable centralised email rewritten in each app. It's just one checkmark in the admin interface for the particular install.
That you have not spent the time to think about these issues and/or fix them is deeply disappointing. Your insouciance about how awful the situation is now is a deep indictment of the open source model (and this is from someone who has spent most of his adult life both creating open source and funding it).
Cloudron is sinking under too many apps and not enough care and housekeeping around the key ones you do support. I know the too-much-to-support issue first-hand. Due to WordPress making it ever more painful to keep our FOSS plugins both up to date and active in the directory (there were code change barriers, but even more administrative barriers), we had to retire about ten of them. Users can't find them or use them.
@girish does a great job running around to help us all and give us tips. It's outstanding. Systemic issues like this need to be addressed in a deeper way and not waved away with one blithe hand, or swept under the carpet.
Don't let the yes-men flatter you into complaisance. Unmerited pats-on-the-back is not how one improves a system or makes progress.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@necrevistonnezr said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
OneDrive or Dropbox would not require admin hours in a large organization - at a totally different price point
Dropbox requires almost no admin hours. If Condoleeza Rice had not been appointed to the Dropbox board in something like 2012 and if the Patriot Act had been repealed, Dropbox would definitely be the far better solution for filesharing between multiple computers. It's cheaper, easier and more reliable. NextCloud is fairly easily hacked (or backdoored through DigitalOcean) but it's not a systematic hack which gives the NSA and CIA direct access to all one's files, as if they are on Google Drive or Facebook or IMAP email.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@robi said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
@foliovision is there a setting for nextcloud to not save trash data? Or only keep it for a short time?
Yes, but it looks like Cloudron defaults to keeping data forever, requiring those of us running NextCloud to dig very deep to figure out how to get rid of deleted files. Intelligent defaults here would be useful. NextCloud is such a bear that I don't blame Cloudron admins for throwing up their arms and telling users, "You want to run NextCloud? Learn how to admin it properly." InvoiceNinja is in another category. It's relatively easy to setup and easy to use.
Yes, users should not be changing database settings, that's too tied into the automation as @girish suggested. Totally understand. Email configuration can be set to default on first launch but then should not be tinkered with if the user changes email settings, particularly for apps where email is core to their functionality.
@nebulon already recognised this issue, which is why there are custom settings for email programs. nebulon should realise that email deliverability has changed in a cardinal way since he set up Cloudron. Email has gone from most email gets through unless there was a previous major spam issue from a given account to email does not get through unless the major ISP has been paid off (partnership relationships) or there is a full SPF/DKIM/DMARC setup, which is not entirely possible with Cloudron from what I can remember (we have setup what we can) AND you are not hosted on DigitalOcean (the recommended provider of Cloudron).
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@jdaviescoates You are welcome to your 2¢. I disagree with you and have enumerated exactly why. I have not said NextCloud is not viable. I've said running NextCloud is a huge waste of development/admin resources without a userbase of at least 20.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@nebulon said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
Question now is why you have the need for having a custom setting for this one app, which in my view does not send out mass email?
I've answered that question above. Deliverability. I don't care about deliverability on the other apps, as they go to internal addresses and internal servers which are set up to accept Cloudron email (we have control). But that's not the essence of the question. The essence is Cloudron management sabotaging its users.
Stop tampering with our email settings @nebulon please. Your high-level view of how we should run our email is annoying and totally out of place. If the preferences are there don't overwrite them.
We do not want our email overwritten. On spinup, feel free to put some defaults in. On reinstall (if an app has been erased), feel free to put the defaults back in of course.
If I have changed settings within an app, do not touch them please.
I'd like to see change here, as the structure as it is now is simply wrong-headed.
I know you don't want to ruin your users lives @nebulon. But that is what you are doing by overwriting key settings without explicit warnings.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@necrevistonnezr said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
The uuid is unique, don‘t copy and paste the commands
That's not our uuid. 230be9ee-72d6-4c54-8218-b08f8d217666 is a random character string. And I really don't need to talk more about NextCloud on this thread. This thread is about InvoiceNinja and how Cloudron overwrites our custom settings with no notification.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@necrevistonnezr said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
@foliovision This is not a general problem but must be specific to your setup. We have more than 100 GB on Nextcloud with various users and our admin folder is less than 16 MB (BTW for others: the uuid is unique, don‘t copy and paste the commands).
Okay, I'm annoyed now with myself for agreeing to answer an off-topic question in the conversation about email settings, which is critical. Our NextCloud setup is a test setup, somehow NextCloud managed to tie me into an admin user ID to be able to sync with WebDAV for iPhones to share address books. With individual user it wouldn't work and barely works with admin user. I've wasted days of my life on WebDAV sync for Apple Contacts but that's not the issue here, nor is our NextCloud. The point I was making about NextCloud is that it's a really complex application, whose vagaries are not the Cloudron team's fault. @girish and @nebulon do what they can to make NextCloud viable software (it's not, without serious server admin hours and a fair amount of study).
InvoiceNinja does work out of the box, and that it didn't work for us is mostly the Cloudron admin's team fault with this absolutely ludicrous zero the email setting on every restart.
Every day I think about how absolutely misguided this setup is, the more annoyed I become.
@nebulon, if you are going to zero your users' email settings on every restart, you certainly owe it to them to serve notice every time you do it. But mostly you shouldn't do it.
In fact, this situation is so easy to fix. If email settings have been changed in app, Cloudron has no business at all modifying those settings again. It's so brain-stunned an approach to providing open-source applications, I'm surprised no one has taken Cloudron to task for it before.
I'm not a server admin. I'm an expert on user interface and workflow, who is daily in contact with code and direct development. If Cloudron hopes to make any progress, you will have to improve your workflows and safety rails for people like me to be able to use your systems.
Another weak spot is the backups which always fail even when carefully configured. I had to get help within our office to solve the backups and the programmer in charge had to spend a fair amount of time to make them work with Linode object storage instead of fail and fail and fail again. At least we received notifications about the failed backups. We never got any notifications about how you were screwing with our InvoiceNinja settings and the how and why of it.
Go ahead @nebulon stick your head in the sand and blame user error again. This is a systemic failure, however clever it seems to you to zero people's email settings and/or force us to keep all apps on the same second-rate undeliverable SMTP, or upgrade all of our apps to external high end SMTP which requires a considerable management for subaccounts.
You're not running Microsoft or Apple where you can get away with ruining people's lives (deliberately breaking WebDAV every second OS release which worked fine and according to spec on 10.6.8) and continue to expand your business. This email settings fiasco should come to an active resolution and not just get swept under the carpet again, with "it worked for some people, it's how we've always done it".
It doesn't work and it's extremely user-hostile to erase people's custom settings. One more time, it's extremely user-hostile to erase people's custom settings. Don't do it.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restartFirst one has to delete the files, then one has to make NextCloud delete the files (NextCloud only hides files), then one has to clean the database.
Here's our own notes:
We wanted to check what's taking so much space on the server and found the trashed items in NextCloud never seem to disappear. There does not seem to be any setting of NextCloud to do that. So you found a workaround:
First I removed content of /home/yellowtent/appsdata/230be9ee-72d6-4c54-8218-b08f8d217666/data/admin/files_trashbin on server
Then I run the command on NextCloud console on Cloudron to re-check files for the "admin" user:sudo -u www-data php occ files:scan admin
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restartTo follow up, some applications are just a pain-in-the-neck and are difficult to make work. For instance managing file space on NextCloud. NextCloud never wants to release files and delete them and it's very easy to run out of space and very hard to clear free space. These are complex issues and there are no simple solutions (apart from not running NextCloud which looks like it's probably our next step as the amount of time which goes into admin of NextCloud makes it a losing proposition). @girish was incredibly helpful and at least got us back to the starting line.
But in the case of InvoiceNinja, the application works, the preferences work. What was breaking InvoiceNinja was the Cloudron setup, not InvoiceNinja. Cloudron is effectively sabotaging effective work with an important app which does have its act together.
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@nebulon Yes, simplification (I'm a fan) is always in conflict with customisation. But come on, the email preferences in InvoiceNinja are so clear and inviting. Billing is exactly the case where one might have special SMTP. Either lock these settings in InvoiceNinja (and show an error message when trying to save with information on where to change the information) or stop overwriting these preferences.
My vote in this case would be to stop overwriting the InvoiceNinja email preferences.
You have literally made my life much, much worse for two years with these decisions. There's been unnecessary friction with our most important clients due to missing invoices and deliverability issues. Cloudron became as much a source of frustration as joy due to this one issue.
Cloudron is not just a toybox at this point. People depend on it for work. Overlooking core issues like overwriting email preferences is no longer the right thing to do if it ever was. Cloudron is not proof-of-concept, it's production software.
-
Perhaps it is time to think about alternativesPersonally I'm not a fan of the Matrix conception.
- set up a Matrix server.
- now set up a front end for it.
It's very extra admin-y for what is already enough of a headache. Would like something simple, like RocketChat looked to be four or five years ago before federation, problems with push notifications, Omnichat (we did use the livechat feature for awhile, it didn't work all that smoothly we probably would have been better served to use a dedicated livechat app).
Sad to hear RocketChat is more or less end of line (the 20 users or less restriction has turned official RocketChat into demoware).
-
Perhaps it is time to think about alternatives@LoudLemur said in Perhaps it is time to think about alternatives:
Element isn't a dependency
You have reversed what I asked. My question is whether Matrix is a dependency for Element. I.e. is Element self-sufficient or does it require a Matrix server (which we probably don't need). I am against additional levels of complexity. Commercial software these days (even and especially the OS underneath) are ridiculously overcomplicated and open source is slowly following in its footsteps down what looks like the wrong path. I'm looking for simplicity in our chat application. Ideally it would be written in PHP/JS/CSS so we could improve it where we find rough edges.
-
Perhaps it is time to think about alternativesThanks for the info @LoudLemur. You said in Perhaps it is time to think about alternatives:
On Cloudron, one would install matrix as the server and then element as a client which users could interface with using their web-browser.
There's nothing on the Cloudron Element info page to indicate dependency on an external Matrix server. It looks like Element would run freestanding. If this is not the case, the Cloudron info page for Element should probably show that dependency.
-
Perhaps it is time to think about alternativesFor anyone who is reading along, Zulip pricing (
if one decides to host with them and not on Cloudron– oops there is no Cloudron version) is per user at about $7/month. We strongly dislike per user pricing (even if it would often be in our favour these days) as it discourages employing people part-time or giving the full team access to tools. We are not looking for another package to manage ourselves (we do manage our own FreeScout and use it intensively enough to make doing so worthwhile, plus it gets FreeScout on the our .com domain rather than the .org) so we are really looking at what chat applications is in the Cloudron repository.- RocketChat is great but gradually squeezing out open source and has privacy issues.
- Mastodon is overkill (we're not trying to build an international open communication platform or federate)
- Matrix seems too complicated
- TeamSpeak seems intriguing but more focused on VOIP than we need
- Element could work but we are unfamiliar with it
- The Lounge – IRC (we happily used vanilla XMPP for years) seems like a step backwards (poor file handling) but is a barebones option which could suit us
- Mattermost – the category of application for which we are looking, lost out the sweepstakes to RocketChat years ago as perhaps Mattermost was not on Cloudron back then and there were some severe limitations to the open source version.
This post is not advocating for Zulip or adding yet more chat applications to the already overburdened Cloudron team. It's just exploring what the best option might be out of what is there already. Element looks a lot like RocketChat/Zulip. Does anybody out there have feedback on how it is to run Element on Cloudron and/or in production?
We'd be giving up the option of livechat on our website but the RocketChat livechat is not great and we're not using it much this year. (RocketChat calls live chat Omnichannel).
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@nebulon said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
I am still not quite sure why you can't configure a Cloudron global email relay which will ensure deliverability across the whole system.
- Yes, we can. But it's a bit finicky with SendGrid. Moreover we only want InvoiceNinja on SendGrid at this point.
- You still shouldn't be erasing people's email settings. This is just wrong. Particularly without actively notifying the user.
At the least, any app where you erase the email settings on restart should come up with a big notification on restart right across the screen that email settings have been zeroed with a hint of what to do about it. This would not be difficult to do across all applications as it's easy enough to run a check if email settings match env or not before overwriting them.
In terms of the platform and what you maintain, I agree it's a lot. It might be better if there were fewer applications with more robust support. Originally I spun up a Cloudron instance just to demo some open source software for internal use. We now use Cloudron in production. In production, issues like this are considerable friction and let down the user experience.
-
Perhaps it is time to think about alternatives@Sam_uk We looked at Mattermost at the time we first considered RocketChat, many years ago. There were some issues then (about five years ago). What are the limitations of Mattermost in 2023?
-
Automated env configuration destroys InvoiceNinja custom mail configuration on every restart@nebulon said in Automated env configuration destroys InvoiceNinja custom mail configuration on every restart:
One consideration here is always how much options we support for how many apps. Each such tweak setting causes support tickets and ongoing testing, which takes time away from other things. Its easy to add initially but the long tail will have an impact.
Another consideration is the living hell we've been through with our InvoiceNinja instance. This is production financial software and Cloudron is willy-nilly overwriting settings.
Generally the Cloudron default email setup is unsatisfactory.
- Cloudron recommends DigitalOcean as the default server provider.
- Maintaining deliverability to large commercial ISP on DigitalOcean IP's is a nightmare/impossible (this is what we tried first, SendGrid only came in later).
- Automated setup with SendGrid is not possible.
This is just tear-your-hair-out-in-frustration open-source-sucks territory.
Cloudron mysteriously overwriting our email settings has cost us about ten billable hours, disrupted client payments and communication and created a huge amount of stress for eighteen months.
Overwriting mail settings on every reset is about the craziest thing I've ever heard of. If you want to be this aggressive remove the email settings within the applications or lock them. Or warn us on every restart:
Your email settings have been overwritten. Please be sure you are happy with the current settings
and then show the current settings to us.
This libertarian attitude of it's up to you to know all your tools inside out all of the time, rather than a protect the user attitude, is one of the principal downfalls of open source (along with "make every option visible, fulfill every feature request however obscure").
There was a guy called Steve Jobs. He pioneered a method of software development which is to make applications and processes user-friendly. I call this way of designing software "intelligent defaults". Wiping email settings on restart is not an intelligent default.
Cloudron does so much of the plumbing right but this careless attitude towards email is extremely user-unfriendly, neckbeard kind of attitude, which does not fit the rest of what you get right.
Email must be just right for deliverability in 2023 (in fact any time after about 2018). Without perfect email pipelines, the production use of any communication application becomes a game of Russian roulette.
Right now there are certainly thousands of other Cloudron users going through frustration with email deliverability and email setup right now. Like us (and we are technically competent), they just don't know how they landed in the email hell they are in.
-
Perhaps it is time to think about alternatives@marcusquinn Marcus, I noticed your crowing about NextCloud talk higher in the thread. It caught my eye. My own experience with NextCloud file sharing and address sync has been painful enough over the course of years (partly Apple's fault) that I'm not keen to rely more on NextCloud. It's been a high maintenance slog. Probably for hundreds of users it's worth it but certainly not for half a dozen users.
To be honest, until relatively recently our RocketChat experience has been much better. We were early users and really loved this app, it's just become so community unfriendly.
@LoudLemur I'll take a look at Zulip. Thanks for the suggestion.