@nebulon That's exactly what I had in mind; just keeping non-admins out of the fields you listed. Anything more advanced, like forcing 2FA or allowing app installation or email administration on certain domain(s) would all be cool, but I get that it becomes a more advanced permission system build-out, so I wouldn't consider it in-scope for this ask - the simpler case covers 90% of my headaches.
Especially when operating in business environments, I tend to want to force users' primary email address to be their "official" email address and only have it be editable by administrators, as well as ensuring that they keep their actual name set as their name. Currently, there's no way to restrict users to only be able to change their password recovery email address and not the other fields - it would be very useful for these types of deployments if there were settings available to turn off the ability of users to self-edit certain field(s) of their profile.
I've purchased the EspoCRM Advanced Pack (https://www.espocrm.com/extensions/advanced-pack/) and gone to install it per the instructions (https://www.espocrm.com/documentation/administration/extensions/) to an EspoCRM instance running on one of my Cloudron installations. The file uploads fine, but the extension installer fails, spitting out the following error(s):
Error: Permission denied for
application/Espo/Modules/Advanced/Acl,
application/Espo/Modules/Advanced/Business/Report/EmailBuilder.php,
application/Espo/Modules/Advanced/Business/Workflow/AssignmentRules,
application/Espo/Modules/Advanced/Controllers,
application/Espo/Modules/Advanced/Core/Bpmn,
application/Espo/Modules/Advanced/Core,
application/Espo/Modules/Advanced/Entities,
application/Espo/Modules/Advanced/Hooks/BpmnProcess,
application/Espo/Modules/Advanced/Hooks/BpmnUserTask/Resolve.php,
application/Espo/Modules/Advanced/Hooks/Common/Workflow.php,
application/Espo/Modules/Advanced/Hooks/Workflow/ReloadWorkflows.php,
application/Espo/Modules/Advanced/Jobs,
application/Espo/Modules/Advanced/Notificators/BpmnUserTask.php,
application/Espo/Modules/Advanced/Reports,
application/Espo/Modules/Advanced/Repositories,
application/Espo/Modules/Advanced/Resources/i18n/cs_CZ,
application/Espo/Modules/Advanced/Resources/i18n/de_DE,
application/Espo/Modules/Advanced/Resources/i18n/en_US,
application/Espo/Modules/Advanced/Resources/i18n/fr_FR,
application/Espo/Modules/Advanced/Resources/i18n/it_IT,
application/Espo/Modules/Advanced/Resources/i18n/pl_PL,
application/Espo/Modules/Advanced/Resources/i18n/ru_RU,
application/Espo/Modules/Advanced/Resources/i18n/uk_UA,
application/Espo/Modules/Advanced/Resources/layouts/BpmnFlowNode/listSmall.json,
application/Espo/Modules/Advanced/Resources/layouts/BpmnFlowchart,
application/Espo/Modules/Advanced/Resources/layouts/BpmnProcess,
application/Espo/Modules/Advanced/Resources/layouts/BpmnUserTask,
application/Espo/Modules/Advanced/Resources/layouts/Report,
application/Espo/Modules/Advanced/Resources/layouts/Workflow,
application/Espo/Modules/Advanced/Resources/metadata/app,
application/Espo/Modules/Advanced/Resources/metadata/clientDefs,
application/Espo/Modules/Advanced/Resources/metadata/dashlets,
application/Espo/Modules/Advanced/Resources/metadata/entityAcl/Report.json,
application/Espo/Modules/Advanced/Resources/metadata/entityDefs,
application/Espo/Modules/Advanced/Resources/metadata/scopes,
application/Espo/Modules/Advanced/Resources,
application/Espo/Modules/Advanced/SelectManagers,
application/Espo/Modules/Advanced/Services,
client/modules/advanced/css/bpmn.css,
client/modules/advanced/fonts,
client/modules/advanced/lib/espo-bpmn.js,
client/modules/advanced/res/templates/bpmn-flow-node/fields/element/detail.tpl,
client/modules/advanced/res/templates/bpmn-flowchart/fields/flowchart,
client/modules/advanced/res/templates/bpmn-flowchart/modals/element-detail.tpl,
client/modules/advanced/res/templates/bpmn-flowchart/record/panels/flowchart.tpl,
client/modules/advanced/res/templates/bpmn-flowchart-element/fields/actions/detail.tpl,
client/modules/advanced/res/templates/bpmn-flowchart-element/fields/conditions/detail.tpl,
client/modules/advanced/res/templates/bpmn-flowchart-element/fields/flows-conditions/detail.tpl,
client/modules/advanced/res/templates/bpmn-flowchart-element/fields/timer,
client/modules/advanced/res/templates/bpmn-user-task/modals/resolve.tpl,
client/modules/advanced/res/templates/bpmn-user-task/record/resolve.tpl,
client/modules/advanced/res/templates/dashlets/options/report.tpl,
client/modules/advanced/res/templates/report/fields/email-sending-time/edit.tpl,
client/modules/advanced/res/templates/report/fields/email-sending-weekdays,
client/modules/advanced/res/templates/report/fields/filters-control,
client/modules/advanced/res/templates/report/filters,
client/modules/advanced/res/templates/report/modals,
client/modules/advanced/res/templates/report/record,
client/modules/advanced/res/templates/report/reports,
client/modules/advanced/res/templates/report,
client/modules/advanced/res/templates/workflow/action-fields,
client/modules/advanced/res/templates/workflow/action-modals,
client/modules/advanced/res/templates/workflow/actions,
client/modules/advanced/res/templates/workflow/condition-fields,
client/modules/advanced/res/templates/workflow/conditions,
client/modules/advanced/res/templates/workflow/field-definitions,
client/modules/advanced/res/templates/workflow/fields/help-text/detail.tpl,
client/modules/advanced/res/templates/workflow/record,
client/modules/advanced/src/controllers/report.js,
client/modules/advanced/src/dynamic-handlers,
client/modules/advanced/src
It looks like /app/code/5.6.9/application/Espo/Modules and /app/code/5.6.9/client/modules are supposed to be writable - since those are where the extension installer is attempting to write files. This seems to be confirmed by visiting the /#Admin/systemRequirements page on the same EspoCRM instance - the only failures on that page are the ones shown in the partial screenshot below, which are also paths that are in the earlier error message when trying to install the extension:
Also, per the EspoCRM Server Configuration section of the Administration guide (https://www.espocrm.com/documentation/administration/server-configuration/#user-content-required-permissions-for-unix-based-systems) :
/application/Espo/Modules, /client/modules – should be writable the current directory (775 for the current directory, 644 for files, 755 for directories and subdirectories);"
From some poking around through ssh and digging through /home/yellowtent and the container, it looks like these folders also aren't symlinked out to the mutable appsdata presently, which would seem to indicate to me that this might likely be most cleanly fixed with an update to the packaged app. All that said, if there's something I'm missing or have done wrong, please let me know! It's very important to get this (and soon probably another or two) EspoCRM Extension working, and I definitely don't want to have to stand up a non-cloudron app install of EspoCRM just to do so.
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.
Strongly prefer Decidim over DemocracyOS for maintenance and security posture (echos my thoughts on that thread: https://forum.cloudron.io/post/3286)
This might be close-able since the DemocracyOS project hasn't seen much in the way of serious activity for quite some time, especially around security updates, which is usually a good barometer of earnest maintenance.
Apache Nifi is an easy to use, powerful, and reliable system to process and distribute data. It supports powerful and scalable directed graphs of data routing, transformation, and system mediation logic.
Basically, it's a highly configurable way to make sure data gets from A to B and/or C etc. while maintaining transparency, logging, and simplifying the design and maintenance of each step along the way. It'd be a great complement to existing apps/services to allow management and ingest to Cloudron apps of external data sources, moving/copying data between apps, etc. (though to be fair, the learning curve is steep - not quite a brick wall, but a bit of a mountain, to get at its power).
Already dockerized, can do LDAP SSO, and it's a full-on ASF project, so there's some staying power implied there.
Yeah, I can get behind that school of thought. Good points made, and given full ability to pick and choose, I'd lean away from SAML, but it is one of the more widely supported options for SSO.
Specifically here, I was thinking about SSO for external services, like a SaaS product, especially one without an on-prem variant that could run on Cloudron, so that you can make the Cloudron user store an authoritative source of truth for necessarily off-Cloudron products.
Enables management and real-time monitoring of endpoints running osquery in the organization.
Track, manage, and monitor your entire infrastructure from a single screen. Create labels populated with hosts matching a query. Whether you want to see machines running an old OS, low on disk space, or running vulnerable software, labels group your fleet in an organized and intelligible way.
Already dockerized for distribution, though SSO is currently SAML-only.