Row in Listendarstellung überspringen

[coccyx]

Folgender Stand:
Mehrere Benutzer arbeiten gleichzeitig in einer Extension. Die stellt Einträge mit der Listenansicht dar.
Während der Eingabe (und noch nicht gespeichert) eines neuen Eintrags darin (tstamp == 0), wird den anderen Benutzern in der Listenansicht dieser unvollständige Eintrag angezeigt, was aber nicht sein soll.

Wie kann ich diesen Eintrag in der Listenansicht ausblenden?

Meine Ideen:
- den core (DCTable.php) ändern, damit tstamp==0 übersprungen wird
- per Javascript die Zeile ausblenden (label_callback irgendeine Klasse übergeben)

Gehts auch einfacher/hab ich was übersehen??

Danke!!

2.Frage nachgeschoben:
Gibt es eine Möglichkeit zu prüfen, ob ein anderer Benutzer gerade einen Datensatz bearbeitet/geöffnet hat?

[Piet]

Woher holt er sich die Daten aus einer Datei oder aus der Datenbank?

[coccyx]

aus Tabelle

zwischendurch die "Not"-Lösung per Javascript:
dca:

$GLOBALS['TL_DCA']['tl_hot_bills']['list']['label']['label_callback'] = function($row, $label, $dc) {
if($row['tstamp'] == 0) {
    return array('<span class="hideMe">in Bearbeitung</ span>', '&nbsp;', '&nbsp;', '&nbsp;', '&nbsp;', '&nbsp;');
} 

dazu ein javascript:

//zeilen ausblenden
window.addEvent('domready', function() {
	$$('table tr td span.hideMe').getParent('tr').hide();
});

[the_scrat]

Kann ja nur die DB sein weil meines Wissens keine Listenansicht über Datei möglich ist.

Spontan würde ich sagen probiers mal über den label_callback. Schreib dir in der DCA eine kleine Methode die alle Labels mit tstamp ==0 nicht zurückgibt bzw. den editier-Stift von diesem Datensatz entfernt


Gesendet von meinem iPhone mit Tapatalk

[Tastaturberuf]

Kannst du Callback nicht einfach nur return (null) machen? Der Rest ist ja Overhead.

Gesendet von meinem XT1032 mit Tapatalk

[coccyx]

@scrat
irgendwie gibt es halt die möglichkeit nicht, da der label_callback nur den string für das label zurück gibt.
und wenn ich das label nulle und alle buttons ausblende bleibt halt eine leere zeile übrig

@cord
in meiner variante oben muss ich das array komplett zurückgeben, da die tabelle mit showColumns angezeigt wird. nur null hätte das gleiche problem mit der leeren zeile (und eine verschobene tabelle)

[the_scrat]

Hi,

habs grad ausprobiert, geht wirklich nicht, die leere Zeile bleibt immer.
Wenn ich einen neuen Datensatz erstelle, wird dieser in der DB angelegt, wenn ich nun gleichzeitig die Listenansicht aufrufe, sehe ich diesen Datensatz jedoch nicht. Verstehe also das Problem nicht, ist das nicht genau das, was du wolltest?

Wenn es um das Editieren von Datensätzen geht, reicht es, wenn du beim Aufruf des Datensatzes diesen Datensatz sperrst, so dass diesen niemand gleichzeitig bearbeiten kann. Würde dazu einfach eine eigene Spalte anlegen und die id des Backendbenutzers reinschreiben. Ruft nun ein zweiter den gleichen Datensatz auf, muss nur geprüft werden ob dieser gesperrt ist.
Beim Speichern (on_save_callback) kannst du den Datensatz ja wieder freigeben.

In der Listenansicht hast du auch Zugriff auf den gesperrten Wert und könntest sogar "live" anzeigen wer den Datensatz gerade in Bearbeitung hat. Zudem bringt dieser Weg auch noch einen Vorteil. Macht ein Backendbenutzer einfach sein Fenster zu (Tab, Browser etc.) wäre dieser Datensatz ja in alle Ewigkeit gesperrt. Du könntest also für bestimmte Benutzer ein zusätzliches "unlock" Symbol als Button einblenden um so einen Datensatz auch manuell zu entsperren.

[coccyx]

Hi,

habs grad ausprobiert, geht wirklich nicht, die leere Zeile bleibt immer.
Wenn ich einen neuen Datensatz erstelle, wird dieser in der DB angelegt, wenn ich nun gleichzeitig die Listenansicht aufrufe, sehe ich diesen Datensatz jedoch nicht. Verstehe also das Problem nicht, ist das nicht genau das, was du wolltest?

Wenn nur ein Benutzer das macht, wird der (noch nicht gespeicherte, also tstamp == 0) Datensatz aus der DB gelöscht sobald du die Listenansicht in einem neuen Fenster/Tab (mit dem gleichen angemeldeten Benutzer) aufmachst.
Ich glaube neu angelegte Datensätze werden in der Session gespeichert.
Du kannst das Problem reproduzieren wenn du dich mit 2 verschiedenen Benutzern gleichzeitig anmeldest. Der eine erzeugt einen Datensatz, der andere aktualisiert die Listenansicht. (aus dem Benutzermenü heraus als der anderer Nutzer anmelden reicht nicht, hier greift wieder das löschen wegen der Session)
Ich hab das grad mal mit Events getestet, damit ich weiß dass es nicht an mir liegt

Wenn es um das Editieren von Datensätzen geht, reicht es, wenn du beim Aufruf des Datensatzes diesen Datensatz sperrst, so dass diesen niemand gleichzeitig bearbeiten kann. Würde dazu einfach eine eigene Spalte anlegen und die id des Backendbenutzers reinschreiben. Ruft nun ein zweiter den gleichen Datensatz auf, muss nur geprüft werden ob dieser gesperrt ist.
Beim Speichern (on_save_callback) kannst du den Datensatz ja wieder freigeben.

In der Listenansicht hast du auch Zugriff auf den gesperrten Wert und könntest sogar "live" anzeigen wer den Datensatz gerade in Bearbeitung hat. Zudem bringt dieser Weg auch noch einen Vorteil. Macht ein Backendbenutzer einfach sein Fenster zu (Tab, Browser etc.) wäre dieser Datensatz ja in alle Ewigkeit gesperrt. Du könntest also für bestimmte Benutzer ein zusätzliches "unlock" Symbol als Button einblenden um so einen Datensatz auch manuell zu entsperren.

Ja. Das ist die saubere, aber aufwändige Variante. Da geht es schneller im Core einfach alle tstamp==0 in der Listenansicht zu überspringen (falls das keine Seiteneffekte hat...)

Bei mir sollen dann mal 4/5 Leute gleichzeitig arbeiten und ich hab die dumme Vorahnung, dass die sich irgendwann mal doch in die quere kommen könnten.

Ich hab grad nochmal geschaut, die Funktion zum löschen der "falschen" datensätze ist: reviseTable in DC_Table.php inkl. Hook. Dazu gibts noch die Session Variable new_records.

[the_scrat]

Also ich habe hier einen ganz anderen Effekt beobachtet, der sogar als Bug durchgehen könnte.

Wenn ich wie du gesagt hast, mit Benutzer 1 einen neuen Datensatz erstelle, mich dann (sogar im anderen Browser) mit einem anderen Benutzer anmelde und die Listenansicht aufrufe, löscht dieser Aufruf den nicht fertiggestellten Datensatz. Dieser wird (zumindest in Contao 2.11.17) nicht gespeichert. Ich habe hier dann nichtmal mehr die Möglichkeit diesen Datensatz zu speichern, auch wenn alle Daten korrekt ausgefüllt wurden. Ich lande auf der Errorseite.

Änderungen im Core würde ich dir nicht empfehlen, auch wenn es die "schnellste" Lösung ist. Was spricht gegen die aufwändige Variante? Vorallem wenn du 4/5 Leute gleichzeitig an soetwas arbeiten lassen möchtest, sollte doch gewährleistet sein, dass alles funktioniert wenn man sich mal in die quere kommt. Und wer weiß ob du beim nächsten Update von Contao an deine Änderung im Core denkst.

[coccyx]

ich hab hier Contao 3.2.9

manchmal kann es doch ganz einfach sein...

filter Abfragefilter (array) Ermöglicht das Hinzufügen eigener Filter als Arrays, z.B. array('status=?', 'active').

$GLOBALS['TL_DCA']['tl_tabelle']['list']['sorting']['filter'][] = array('tstamp>?', '0');