Feature questions from an enterprise perspective

Hi, I've been looking into using this software and have some questions regarding its architecture and the project status in a number of feature areas. The questions can be viewed as feature requests as well. But I don't have enough specific knowledge of BetterCMS to articulate the precise and relevant tickets.

The point is to be a bit enterprise-focused, i.e. applicable when the software is being used by a large and/or complex organisation. If the software is not intended for this, i.e. if scalability is not a goal, please feel free to close this issue. If not, I imagine that the questions and discussion/answers could be useful for anyone to read, so I chose a GitHub issue as the medium for these thoughts.

How are peripheral properties stored?

Firstly, my definition of the "core" her would be: The part of the code that is working with the system's primitive objects, while exposing an internal and external API for data access. One of the first thing I look at in a platform is how small its core is. If a CM platform can produce a strong feature list while keeping the core small and slow-moving, it means that the core is well-aligned with the project's long-term goals.

This has to be combined with the fact that all moving parts in the platform are actually using the core (a small core is easy to create if all subsystems are circumventing it). But if all subsystems are using the core, we have a great platform for coherency.

My idea of a good core is when the platform has an object wrapper that all parts of the system is using for all needs of access and persistence. That means that e.g. changes to permissions can be implemented in one place only, while applying to all parts of all of the subsystems. It also means that all persistence is done in the same way. To clarify with an example, if users are created in the CMS backoffice they should A) be using the same object wrapper as other objects in the system and B) roles should be maintained in the same way (not in e.g. configuration).

Taken to its extreme, it will mean that all entities of the system (including templates, configuration, backoffice itself etc.) are stored in the same place, e.g. a database, using the core. That particular case might not be optimal, of course, but coherence should be the starting point. All deviations should be well-founded decisions. Inevitably, entities that not are persisted in the same way as the baseline (those entities are the ones I refer to as “peripheral properties”) will grow the codebase and affect maintenance as functionality is introduced that should work across various persistence layers.

Are permissions granular, inheritable and scalable?

Permissions are a critical tool for managing a solution used by large organizations with hundreds of editors. This boils down to four general bullets:

Which system entities can be restricted?
Which actions can be restricted?
Which complexity can be expressed?
Which scalability can the permission system handle?

To clarify, some example questions: Can any combination of role and user permissions be set on a particular content item? Can all possible actions in the system (and its subsystems) be controlled using permissions? Can a content item inherit permissions from parent nodes? Can a content item prevent inheriting permissions from its parent node? Can roles use inheritance to express complex roles? Can publishing a content item be restricted? Can publishing a content item in a particular language be restricted? Can publishing a content item in a particular language to a particular data location be restricted? How many roles can a role inherit? How many roles can a user be assigned to? How many permission sets on a node is supported?

Assorted CM questions

Are complex workflows supported? Which workflow actions are supported?
Is content migration supported? In which format? Can all system entities be migrated, such as workflows, users, roles, permissions, assets, templates etc.?
Can a number of domain names be used for a particular set of items? Is a complex setup with > 500 domains easily administered?
Are content items versioned per language? Are there any limitations to the number of versions?
Can fields on content items be shared across languages?
Can content items be cloned? So that the content item is following a master version but field alterations are tracked.
Are content items separated from renderings? I.e. can the same content item be used as the data source of two renderings?
Do templates support multi-inheritance?
Can arbitrary data (e.g. entities from an external ERP system) be modelled and persisted in order for the editor to use and edit it? Can that data be treated as a first-class citizen and have e.g. permissions, versions, workflows, language versions etc.?
Is it possible to set a future date of publishing a language-versioned content item? Is it possible to set a complex set of timestamps that defines which version of a content item should be published at which point in time?
Is indexing configurable by an editor, to be used in product filterings etc.?
Are bulk operations available? E.g. how do I assign or remove a workflow to/from a large set of content items? How do I move a large set of content items from one parent to another? How do I set permissions on a set of items?
Assorted infrastructure questions
Can the indexing work be sharded? Indexing often becomes a bottleneck in large solutions.
Can the (resulting) index be distributed across geographical data locations?
Can the content delivery be distributed across geographical data locations? Also, can the content management be distributed across geographical data locations?
Can content management and content delivery be separated by infrastructure (for security)?
Can content delivery be scaled horizontally? Can content management be scaled horizontally?
Can a particular part of the content be placed in a separate database while maintaining editorial support for it?
Thanks for reading

I'm hoping that my questions gives you an insight into how the software could evolve in order to scale up to enterprise use. Sorry for the stir :seedling:

Thanks!

devbridge / BetterCMS