frontend-edit, benutzerrechte gruppen/einzelpersonen

[em_we_es]

ich habe eine theoretische frage zum funktionsumfang und den möglichkeiten:
ist es möglich, z. b. 100+ user auf den frontend-edit bereich zu lassen, wobei sie alle eine einzige cc-datenbank mit einträgen befüllen, aber nur jeweils ihre eigenen einträge im frontend-edit sehen und bearbeiten können?

ich habe ja im backend die möglichkeit, das fe-edit auf benutzergruppen zu legen – das berücksichtigt dann aber nicht noch einzelne nutzer, oder?
frage ich da zu naiv? evtl. geht das ja ganz easy.
mir erschliesst sich nur leider nicht, wie man das am besten einrichten könnte, wenn es denn geht. :-(

[Tim]

Dies ist bereits in den Online-Demos dargestellt. CC Feedit hat ein Rechtelevel bishin zum einzelnen Eintrag.
Für die zusätzliche Regelung von Besitztümern je User gibt es das Protection Attribut "Elemente schützen".

Besitzrechte manuell vergeben:

// usage: table level
// $GLOBALS['PCT_CUSTOMCATALOG_FRONTEDIT']['EXCLUDE']['myTable'] = true; // exlucde the whole table, including all entries. No rights at all
// usage: entry level
// $GLOBALS['PCT_CUSTOMCATALOG_FRONTEDIT']['EXCLUDE']['myTable'] = array(10,11,12); // exlucde the entries with id 10, 11 and 12
// usage: entry level, restrict certain operations
// $GLOBALS['PCT_CUSTOMCATALOG_FRONTEDIT']['EXCLUDE']['myTable'][10] = array('keys'=>array('copy')) // show only copy button for entry id=10 

[em_we_es]

ok, merci – hm, ich habe den datensätzen ein "elemente schützen" attribut mit auf den weg gegeben (screenshot) und sie im backend unterschiedlichen mitgliedern zugewiesen.
nach login im fontend bekommen aber dennoch alle mitglieder alle datensätze gelistet und können sie auch bearbeiten.

Dies ist bereits in den Online-Demos dargestellt

die onlinedemo zum frontentedit hat ja kein backend-login zum lernen, die onlinedemos zum cc sind aber ohne das attribut "elemente schützen" aufgebaut.
hab ich etwas etwas übersehen, damit es funktioniert?

wichtig wäre dies z.b. auch beim listing anderer tabellen über das tag-element, welches die datenbanktabellen nutzt, da sonst ja auch alle alles gelistet bekommen (was man unter umständen nicht will) …

[Tim]

Baue das ohne das Editing im Nacken erstmal auf. Elemente schützen ist nicht auf das fe editing bezogen, sondern bereits deine normalen Einträge müssen entsprechend runtergebrochen werden. Das editing kommt nur on top.

[em_we_es]

dankeschön für deine antwort, aber ich komme damit leider nicht klar.

mein ansatz war ja, im frontend-edit die einzelnen mitglieder voneinander zu trennen in de eingabe ihrer daten.
wie müssen die listingmodule zu den einzelnen einträgen denn aufgebaut sein, dass sie jeweils ihren autor berücksichtigen?

ich habe mal im listing eine eigene sql-bedingung auf "editor={{user::id}}" mit eingebaut – das funktioniert zwar, aber leider nicht bei tag mit datenbank-listings (da gibt es eine fehlermeldung, da der inserttag nicht übersetzt wird.

[Tim]

Im Liste Modul unter eigene SQL Bedingung passt das doch gut.

aber leider nicht bei tag mit datenbank-listings (da gibt es eine fehlermeldung, da der inserttag nicht übersetzt wird.

Ich weiss nicht, was das heissen soll.
---
Hast du mit deinem Elemente schützen - Attribut ein Mitglied je Eintrag ausgewählt und einen Elemente Schützen Filter für die Liste hinterlegt?

[em_we_es]

hui, ich hab mich da verquast ausgedrückt…

mit der eigenen sql-bedingung oder einem filter klappt das gut, die einträge nur den jeweiligen mitgliedern auszugeben. soweit klappt das.

aber:
hat man aber bei einer tabelle andere tabellen verlinkt, indem man das tag-element mit eigener sql-quelle nutzt, kann man diese wiederum nicht auf das jeweilige mitglied reduzieren.
das bedingungsfeld lässt keine inserttags zu wie z.b. "member={{user::id}}", womit eine filterung wie im modul selbst über das feld "eigene sql-bedingung" möglich wäre.

screenshots anbei.

ich kann mir theoretisch da nur behelfen, indem ich das tabletree modul anpasse (dirty …), sodass dort im frontend die listings nur noch mitgliedsbezogen ausgeben.
… wäre toll, wenn bedingungsfeld wir das sql-feld funktionieren würde, dann ginge das.
was anderes fällt mir da gerade nicht ein.

[Tim]

Naja, du mischt hier halt auch zweierlei Dinge. Das Tabletree ist ein Backend Element und du möchtest aber eine Bedingung definieren, die nur im FE zutreffen würde!

Möglich ist alles, aber das wir eine richtig tiefe Op. Zusätzlich erschwert, dass das Tabletree auch noch in einem Pop läd.
Das erste Problem wird schon sein, dem Tabletree das Backend aus dem Kopf zu schlagen. Im Backend werden nämlich keine Inserttags ersetzt und das Tabletree denkt für sich weiterhin ich bin im BE.

CC Feedit macht es quasi vor, wie man selbst strikte BE Elemente biegen kann. Siehe File-Picker, Page-Picker und halt auch Tabletree. Du wirst anfangen müssen die Controller zu überschreiben: https://github.com/timgatzky/pct_cus...tTableTree.php

--- >

Ein event. möglicher Weg wäre es den Element neue Wurzeleinträge unterzujubeln via Session. Das Element reagiert auf die Session "'pct_tabletree_roots'" bzw. auf den Parameter des Widgets ['tabletree']['roots'].
https://github.com/timgatzky/pct_tab...eTree.php#L145

Aber selbst dafür muss du manuell die Datenbankabfrag erstellen, die als Ergebnis die anzuzeigenden Einträge (id) enthält, die dann in die Session speichern.

[em_we_es]

hm, das tabletree kommt aber automatisch ins spiel, wenn user im frontend einträge hinzufügen und auf tags mit datenbankanschluss stoßen.
es drängt sich mir auf, das frontend-edit verspricht da mehr im bezig auf rechte, als es im detail aktuell hält.

ich programmiere ja eher auf dem level eines maulwurfes und das hier ist sicher eine ziemlich schlechte umsetzung, aber so funktioniert es theoretisch, dass frontend und backend unterschieden wird und dann beim frontend-fall und abfrage auf eine tabelle die eingeloggte userid berücksichtigt wird. bei tabletrees, die auf tags oder andere listen zurückgreifen, wird die userid ignoriert.

tabletree.php, ab zeile 425 bei abfrage auf die rows
… aber das geht natürlich "in die vollen", da direkt in der extension …

if (TL_MODE == 'FE')
{
    //FE-Zustand abfragen, ist user eingeloggt?           
       $this->import('FrontendUser', 'Member');
    if (FE_USER_LOGGED_IN)
    {
       $memberId = $this->Member->id;
       //püfen, ob auf tabelle zugegriffen wird oder auf andere tags
       if (strpos($this->strSource, 'cc_') !== false){
             //tabelle, also userid mit beachten 
             $objRow = $objDatabase->prepare("SELECT * FROM ".$this->strSource." WHERE ".$strKeyField."=?".($this->strConditions ? " AND ".$this->strConditions:"  AND editor='".$memberId."'" ))->limit(1)->execute($id);
        }else{
               //alles ausser tabelle, also userid nicht beachten
               $objRow = $objDatabase->prepare("SELECT * FROM ".$this->strSource." WHERE ".$strKeyField."=?".($this->strConditions ? " AND ".$this->strConditions:"" ))->limit(1)->execute($id);
        }
    }
    else
    {
       $return = '';
    }
}else{
    //BE-Zustand, alles wie gehabt
    $objRow = $objDatabase->prepare("SELECT * FROM ".$this->strSource." WHERE ".$strKeyField."=?".($this->strConditions ? " AND ".$this->strConditions:""))->limit(1)->execute($id);
}

[em_we_es]

ich muss zum thema nochmal "nerven".
gehe ich den ansatz, über das backend editoren die eingabe in zwei tabellen zu erlauben und lege in beiden das "element schutzen" objekt mit an auf benutzer-ebene(user), dann kann ich die einträge ja gut filtern im listing.
was ich aber nicht hinbekomme – front- wie backendseitig – dass in dieses feld die user-id des editors automatisch eingetragen wird.

es ist in der regel leer, sodass nach neuanlage eines eintrages dieser im auf den user eingegrenzten listing nicht mehr sichtbar ist. der voreinstellebare wert auf einen user nützt da ja auch nichts, es sollte immer der eingeloggte user sein.

was muss man denn genau einstellen, dass im datensatz der user, der den datensatz angelegt hat, auch mitgeführt wird.

[em_we_es]

und zuguterletzt für heute:
ich fände es knorke, wenn das protection-attribut beim edit im backend automatisch auf den eingeloggten user eingestellt wäre.
es gibt nur die option der vorauswahl eines users, aber der aktuelle wird nicht als default übernommen.

das habe ich in der system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Attributes/Protection/protection.php ab 43 mal nachgezogen …
… wenn default-wert eingestellt, dann den nehmen, ansonsten den des eingeloggten users
aber auch das steht halt jetzt direkt in der extension …

if($this->get('defaultValue'))
        {
            $arrReturn['default'] = $this->get('defaultValue');
        }else{
            $objUser = \BackendUser::getInstance();
            $arrReturn['default'] = $objUser->id;
        } 

[Tim]

Standardwerte werden nur bei neuen Datensätzen eingetragen. Vergleiche mit normalen Contao Elementen. Sonst könnte man einen Wert nie leeren.

[eblick]

Ich würde das Thema nochmals aufgreifen.
Ich hätte auch die Anforderung dass ein eingeloggter Backend-Benutzer neue CC-Sätze eintragen darf. Er soll dann aber auch gleichzeitig die User-Protection für seinen Usernamen erhalten.
Alles andere wäre ja recht umständlich, wenn jedesmal erst ein Admin oder Gruppenredakteur die Zuordnung erledigen muss.
Aktuell sieht der User nach dem Abspeichern seinen erstellten Datensatz nicht.

[Tim]

Ich sehe eine weitere Standard-Wert Option vor, die den akuellen Benutzer bzw. Benutzergruppe einträgt. (nur Backend möglich, nicht FE editing!)

[eblick]

Prima, im FE-Editing ist es ja auch meines Wissens schon umgesetzt....