What's coming 5.3
-
-
Maybe basic moderation for email list?
Allows to assign one email address (which is on the list) as the moderator email so that:
- if an email is sent from someone on the list it just goes through and get distributed as normal
- if an email is sent from someone outside the list, the sender gets an email back saying their email is being moderated; the moderator receives the email and can forward it or not to the list
Just though of this as an easy implementation of basic moderation if that's useful.
-
@Upuat You can upvote this thread - https://forum.cloudron.io/topic/1211/zabbix-statistics and we can prioritize based on interest. Are you looking for integration with an external zabbix server or running zabbix as an app on Cloudron?
-
@avatar1024 I prefer to package an existing app which provides distribution list functionality for this instead of writing our own (if possible). Do you know of any? For example, does mailmain or Sympa cover this?
@girish Sure that makes sense. I was more proposing this as a basic twist on what seem to already be built-in Cloudron email features to add some kind of moderation with minimum development work (basically just an auto-forward to a specific address, and the moderator doing again just a forward to the list manually).
Both yes both mailman and Sympa do this. But maybe this is not something many people need as I don't think there have been many upvote (for mailman at least) so feel free to disregard
-
As long as your re-touching the onboarding flow, I have a small suggestion : add a password.
More precisely, when the terminal tells you to go to the IP of your server on your browser, anyone who gets there before could basically take over the server, and could even reset the flow so you don't even notice. I know, the window of opportunity is small. It should basically be impossible as long as you go to the IP in question right then. But still...
A one-time password shown in the terminal, that the web interface would ask you for before allowing you to proceed with the setup would be pretty easy for the user, and would completely solve the issue.
(I must note that I have not gone through the setup and onboarding in a long time, what I am saying may be completely obsolete)
-
As long as your re-touching the onboarding flow, I have a small suggestion : add a password.
More precisely, when the terminal tells you to go to the IP of your server on your browser, anyone who gets there before could basically take over the server, and could even reset the flow so you don't even notice. I know, the window of opportunity is small. It should basically be impossible as long as you go to the IP in question right then. But still...
A one-time password shown in the terminal, that the web interface would ask you for before allowing you to proceed with the setup would be pretty easy for the user, and would completely solve the issue.
(I must note that I have not gone through the setup and onboarding in a long time, what I am saying may be completely obsolete)
-
As long as your re-touching the onboarding flow, I have a small suggestion : add a password.
More precisely, when the terminal tells you to go to the IP of your server on your browser, anyone who gets there before could basically take over the server, and could even reset the flow so you don't even notice. I know, the window of opportunity is small. It should basically be impossible as long as you go to the IP in question right then. But still...
A one-time password shown in the terminal, that the web interface would ask you for before allowing you to proceed with the setup would be pretty easy for the user, and would completely solve the issue.
(I must note that I have not gone through the setup and onboarding in a long time, what I am saying may be completely obsolete)
-
The ability for users to disable / stop services such as redis, mail, etc without needing command-line access to do so. That'd be an awesome (and hopefully small) tweak that'd be useful especially for people who want to optimize their resources on their servers.
-
Hi,
i just wannted to ask about the Firewall in Cloudron Whitelist and Blocklisting IP's.
Usually i would do it over UFW but since its a bit diffrent in Cloudron.
Because i see some IP's thanks to shodan -.- trying to send some spams and i would like to block them.
And GEO IP Blocking as a feature would be nice, i think login to my.cloudron.com should be really high secured, i mean yes we have 2FA but if someone tries bruteforce attacks will not lead to something because of 2FA, but why create uneeded webservice requests. -
Not a feature for 5.3, but wish to point out that Cloudron does not have even a single e-commerce platform (other than woocommerce on Wordpress, of course).
OTH, we have multiple apps under each category.
Can we get started on Magento and Prestashop please?
Thank you!!
-
UI* dashboard improvement -
add the root domain as a secondary text (maybe above the icon?) for sub-domain apps. The apps with a root domain show this and its easy to see but for apps in a sub-domain you have to hover over the app card to see which root domain it belongs to, would be an awesome addition!...thanks! -
Not a feature for 5.3, but wish to point out that Cloudron does not have even a single e-commerce platform (other than woocommerce on Wordpress, of course).
OTH, we have multiple apps under each category.
Can we get started on Magento and Prestashop please?
Thank you!!
-
@jagan This is true, but you can install any nodejs or php e-commerce app in the LAMP app. Which I'd honestly perfer anyway as it would give me more control over the install.
-
@murgero thats cool i never thought of that - you can use the apache server for a nodejs app?
@plusone-nick NodeJS is installed in the LAMP app, you can run the app in the background via run.sh in /app/data.
So in run.sh you can:
cd /app/data/nodejs-app/ npm start & # Or other command to start app (The "&" here runs the app in the background.)Then in
/app/data/public/.htaccess:RewriteEngine On RewriteRule ^/?(.*)$ http://localhost:3000/$1 [L,P] ProxyPassReverse / http://app.example.com/Or something like that, this is untested technically and that will redirect the nodejs via apache.
