Cloudron Forum

girish

@sponch it shouldn't be a problem if troubleshoot works fine.

Overall, it's become quite common now to run apt upgrade by habit or the VPS providers are running this automatically. With that in mind, we have decided to change our policy to allow apt upgrades (but not dist upgrades). We will (already have) change the platform code accordingly to adapt to different base packages as required. For Cloudron 10, the warning is already removed - https://git.cloudron.io/platform/box/-/commit/1ae9fb2477a33b724ccffb17a1fda800953aafda

timconsidine

TinaCMS-based Cloudron app now exists, but a quick note on positioning: TinaCMS is not an out-of-the-box full-featured CMS. It needs configuring, and Tina themselves mainly document it around content-model/schema setup plus general site configuration.

What I’ve built is about 90% TinaCMS, but configured as a generic, customizable brochure-website editor aimed at non-technical users, rather than e.g. a docs site or an e-commerce site.

The implementation is quite opinionated, so it may not suit everyone’s preferences or use case.

I’m not releasing it as a Community App for general use yet, as I want more testing and a few more tweaks first. That said, if someone has a strong use case and genuine interest, I can make it available on request.

timconsidine

Came across a need to help a freiend with a simple build, so I am attempting a Cloudron package of TinaCMS.

EDIT : alpha version runs - now working on making it release ready

timconsidine

@jdaviescoates oh, yes, rather good point !

girish

Right, the check is simply hardcoded to check for a: entry in the SPF. To check all the possibilities would be quite complicated, since we will have to implement the full SPF spec just for diagnostics.

(What you see on the dashboard is just a diagnostic. The mail server Haraka has a fuller SPF implementation).

timconsidine

https://forum.cloudron.io/post/123102

timconsidine

Isn’t this a duplicate ? Or it’s an original very close to something else

girish

Login sessions is now much better. It individually lists the sessions and you can also log out from those specifically (or all of them).

I think there was always some confusion about "app" oidc sessions and I looked into this. In theory, we can list the app sessions in the UI below as well. But clearing a app oidc session, will only clear the session from the Cloudron side. Practically speaking, all apps maintain their own session and this means the app will still remain logged in. So, we have decided to not list them here to avoid any confusion.

If you want to truly log out (from say some kiosk):

Click "log out from all" in cloudron dashboard. At this point, Cloudron will ask apps which want to authenticate afresh to re-login.
Log out from apps that were already logged in previously one by one.

girish

Personal access tokens will be renamed to API tokens.

Currently, the tokens are per user and created in the user's profile page and is hidden from the purview of admins. On Cloudron, most (practically all) of the APIs are server level operations. There is nothing a user can do which is really just for themselves. The common situation is to create tokens for CI/CD. With this in mind, the tokens are now global in System -> Settings and all admins can see created tokens, created by whom, last accessed etc.

girish

@BenjaminJ you have to use something like https://docs.cloudron.io/packages/dolibarr/#manual-utf8mb4-migration to migrate an existing installation .

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

Cloudron Forum

AppDev

Posts

Member List