KleeneStar

With rapid and continuous development, KleeneStar is becoming increasingly complete, making now the ideal time to address deeper technical details that there was no time for in the previous process. A central point concerns the structuring of system components. Some time ago, objects were already divided into four core object types such as Document, Blog, Issue, and Asset, which are provided by default by the core system and can be flexibly expanded with custom categories via plugins if needed. Now, the internal structure of these four main groups should be further subdivided and specified. Since each of these object types is already implemented as its own class in the software, this deeper segmentation can be technically realized without any problems. The next concrete step in the implementation is the integration of a new form view. These forms fundamentally behave like classic documents in the system and are displayed identically in the tree structure. The essential difference lies...

In KleeneStar , the need to connect objects such as processes, projects, and documents is steadily increasing. Projects should reference tasks, tickets should link to documents, and workflows should make dependencies visible. The central question is how these connections can be represented most effectively within the data model. Two approaches have traditionally been considered: fields within a class that hold lists of references to other objects, and a dedicated entity that describes relationships between objects. Both approaches have distinct advantages, but analysis shows that a hybrid model combining both is the most sustainable solution. In the field‑based approach, a link is treated as a regular attribute of a class. An object might, for example, have a field containing a list of document IDs. The field type is fixed, meaning it can only reference one specific class. This solution is simple, quick to implement, and performant because it requires no additional tables or complex qu...