Cloudron Forum

@jimcavoli I think that makes sense. Let me see if I can get the recvmail addon working again, should be straightforward. For your suggestion of having a "selector" in the email UI, we did exactly that for sendmail addon in the previous release. So, we can do the same for recvmail as well I guess. Let me investigate.

@jimcavoli Ah nice. I have enabled it now. Just have to add domains in Custom domain. The 'Set domain' is misleading because it's really 'Add domain' [image: 1612033766759-abff855e-5a6d-405d-8a37-5610bfbaa122-image.png] Add add the aliases in Cloudron dashboard: [image: 1612033820585-34c38d0c-c85e-4659-9c37-21ceea0f9d81-image.png]

@jimcavoli Bump

@girish When will this be exposed in the GUI? Hopefully this can be planned for 7.4 perhaps, along with the many other mail improvements requested?

Even if we could just get LDAP groups working with Nextcloud that'd be a big win imho given how many of us use Nextcloud (I think I'm correct in assuming it's the 2nd most popular app on Cloudron?)

I understand the use case might be a bit narrow, but for those who understand - that's an absolute killer.

@robi yes, probably. But I can't seem to find who calls pcntl_signal_dispatch in EspoCRM. @jimcavoli Can you grep the code for pcntl_signal_dispatch ? Maybe it's coming from plugin?

This is in 7.4

@jerimiah Interesting. Can you try to take some websocket test pages like https://www.websocket.org/echo.html or https://websocketstest.com/ to see if it's some browser/websocket issue or package issue?

@girish To that end, perhaps this one is better locked at this point

Upgrade went well - all good on v5.1.3 now

For discourse, we found that it doesn't have proper LDAP support yet. Please see https://forum.cloudron.io/topic/2/discourse/20 . If a plugin comes up, we are happy to integrate it into the package.

@nebulon said in Feature request: Optionally restrict user profile editing: That sounds like an important use-case indeed and goes into a whole field of more fine-grained control over what users can and cannot do. So far we have tried to not overcomplicate the access control settings, but we are open to small useful adjustments. Given that Cloudron has a special permissions group, the admins and then simply the rest of the other users, would it be sufficient for your use-case to have an admin setting to prevent non-admins from changing their own profile? And if so, what fields should be protected? agreed!!

@dogansur this forum is very helpful.. .

Thinking about it, if there were going to be a bigger, badder SSO solution "baked in" to the platform, keycloak (https://www.keycloak.org) may be the better tool to close some of that gap than Shibboleth for the job (OpenID Connect, OAuth 2.0, and SAML support built-in; similar flexibility on the backend). My main thought in the use case of SSO apps is that SSO as a platform component is, to date, a platform-internal feature, and I think there's a huge benefit to being able to essentially treat Cloudron as your authoritative directory / user store and leverage it for SSO with SaaS and other strictly off-host products.