#592 weitere Standard-Spalten in MM-Tabellen (state: open)

Hallo, in einigen anderen "CRUD-Systemen" werden in den Datentabellen weitere Standardspalten als bei MM angelegt - aus meiner Sicht macht es Sinn, das zu übernehmen. Aktuell gibt es als Standard-Spalten: id, pid, sorting, timestamp m.E. wäre es prima, die folgenden Spalten automatisch mit anzulegen und durch MM auch zu pflegen:

• create_ts - Timestamp beim Anlegen des Datensatzes
• update_ts - Timestamp beim Ändern des Datensatzes
• create_user - User-id beim Anlegen des Datensatzes *1
• update_user - User-id beim Ändern des Datensatzes *1
• status bzw. deleted - Status des Datansatzes 2 1: aktuell würde die ID der Benutzer-Tabelle ausreichen aber da Contao zwei User-Tabellen (Mitglieder und Benutzer) hat, wären bei den beiden User-Spalten noch die Usertypen zu ergänzen - ID = 0 wäre dann per Default Extern/Gast; ein serialisiertes Array aus Usertyp + ID wäre sicher nicht empfehlenswert... Sollte es für die Bearbeitung mal eine ACL geben, wären die die Userinfos sicher notwendig... *2: bisher bin ich bei meinen DB-Umsetzungen gut gefahren, Datensätze nicht (einfach) zu löschen, sondern lediglich als gelöscht (deleted = 1) zu kennzeichnen und das in den Queries als Standard mit abzufragen.

+1

Sinnvoll ... kenne ich so ähnlich auch von CakePHP. +1

Mit Ausblick auf ein mögliches Frontend-Editing sollten die Spalten wie folgt geändert/ergänzt werden:

• create_user_be - BE User-id beim Anlegen des Datensatzes
• update_user_be - BE User-id beim Ändern des Datensatzes
• create_user_fe - FE User-id beim Anlegen des Datensatzes
• update_user_fe - FE User-id beim Ändern des Datensatzes

Wäre dann nicht auch Gruppe(n) sinnvoll?

soweit ich "ACL"s kenne, wird das dann über die zugehörige(n) Gruppe(n) des Users gemacht, d.h.

• nur User selbst darf ändern
• User und seine Gruppe(n-Angehörigen) dürfen ändern
• alle dürfen ändern wobei das "ändern" noch in Anlegen, Ändern, Löschen unterschieden wird bei der "strategischen Auslegung" gibt es die zwei Ansätze
• alles erlauben und dann einschränken
• alles verbieten und dann frei geben

Naja, was ist, wenn es den User nicht mehr gibt? Dann kann man über die ID desjenigen auch nicht mehr an die Gruppenberechtigung.. oder man ändert die Gruppenberechtigungen, die aber nicht für das Item anders sein sollen.. usw. ;-) Ich kann mir da schon kranken scheiß ausdenken was man da brauchen kann ^^

siehe letzer Punkt: "status bzw. deleted - Status des Datansatzes *2"

Bei meinen Programmierungen "from scratch" wurden alle Datensätze mit einem Delete-Flag ausgewiesen - gelöscht wurde hier nix!

Sofern der Begriff "audit trail" mal vorgekommen sein sollte - dafür darf der User nicht gelöscht werden!