Genau ein Item pro Mitglied

[Allan]

Hallo Alexander,

im Prinzip geht es nur um die Zuweisung der ausgelesenen Datensätze und die weist Du mit

userid={{user::id}} 

zu, wobei "userid" für den Tabellennamen des "useridfield" steht.
Das "useridfield" erhältst du nach Installation der Erweiterung "catalogitemuseridfield".

Wie Du dann Deine Anforderungen aufbaust steht beispielhaft in diesem Tutorial: http://de.contaowiki.org/Catalog_mit...flow_erstellen
sehr verständlich beschrieben.

Gruß
Allan

[Alexander]

Hi Allan,

vielen Dank für deine Antwort!
Wo filter ich denn aber nach der userid? Ich habe einen FE-User in einer Testumgebung angelegt, dazu einen Katalog mit einem Eintrag. Bei diesem Eintrag habe ich ein Testfeld gemacht (Textfeld) und ein userid-Feld, wobei ich beim einzigen Eintrag in diesem Katalog den angelegten User ausgewählt habe. Soweit so richtig oder?
Nun habe ich eine Seite eingerichtet, die ich einfach "Bearbeitung" genannt habe. Darin habe ich dann "Katalog bearbeiten"-Modul eingebunden, in dessen Einstellungen ich den Katalog ausgesucht habe und alle zwei erstellten Felder zur Bearbeitung freigegeben habe.
Logge ich mich nun als dieser FE-User ein und rufe die Seite auf, kann ich leider nichts sehen. Irgendwo muss ich nun ja noch filtern; nur wo?

Über weitere Tipps wäre ich echt dankbar!

Beste Grüße
Alexander

[Andreas]

Ist in dem Ausgabe-Modul kein Feld 'Bedingung', wo du userid={{user::id}} eintragen kannst?

[Alexander]

Hi Andreas,

danke für deine Antwort.
Leider gibt es beim Modul kein entsprechendes Feld, das habe ich auch zuerst gesucht. Modulname ist "Katalog-Bearbeitung".

Versionen:
Contao: 2.10.4
Catalog: Aus dem ER

Beste Grße
Alex

[Andreas]

Ah, ok. Die Bedingung kann man in der Liste eingeben, mit der man die Bearbeitung ansteuert.

Damit dann auf der edit Seite keine Einträge erraten werden können muss man im catalog_edit_xxx Template das Feld userid des Datensatzes empfangen (ich hoffe das geht). Schau mal mit print_r($GLOBALS) oder was sich da anbietet und suche in der Ausgabe nach userid.

Sperren der Bearbeitung ist ja dann einfach.

if($feldMitUserId !== $this->replaceInsertTags('{{user::id}}'))
{
  echo 'no edit allowed';
  return;
} 

Evtl. kommt man auch noch ohne replaceInsertTags an die User-ID, evtl. mit $this->User->id, weiß ich jetzt nicht auswendig.

[Alexander]

Hi Andreas,

danke für deine späte Antwort! :-)
Also ich habe nun <?php echo '<pre>' . print_r($GLOBALS) . '</pre>'; ?> in die catalog_edit.html5 eingegeben, bekomme aber leider nix zurück. Ich habe das Gefühl, dass beim FE-Aufruf das Modul erst gar nicht verarbeitet wird, obwohl aber folgendes im Quelltext steht:

<section class="mod_catalogedit block">
<p class="info"></p>

<p class="back"><a href="index.php/seite.html" title="Zurück">Zurück</a></p>

</section>

Nun bekomme ich auch durch print_r nichts zurück. Wo muss ich dann die Bearbeitung sperren? Gleich im Template? Leider bin ich nicht firm genug, um das Ganze gleich richtig einzuarbeiten. Und wie filter ich im Template dann? Auf Grundlage des leider ausgebliebenen print_r Ergebnisses, richtig?

Beste Grüße & einen angenehmen Sonntag
Alex

[Andreas]

Das ist nicht das original Template, aber erstmal egal.

Hast das fast richtig gemacht, aber print_r() ist ein Ausgabebefehl, so wie echo, gibt also nicht die Variable zurück. Wenn du das willst, musst du print_r($meineVar, true) benutzen. Meistens benutzen wir das aber so

// Meist so
echo '<pre>';
print_r($GLOBALS);
echo '</pre>';

// So müsste es allerdings auch gehen
echo '<pre>' . print_r($GLOBALS, true) . '</pre>'; 

Du kannst dir die Ausgabe auch im Quelltext ansehen, dann brauchst du kein <pre>.

Filtern tust du dann wie ich vorher gezeigt habe mit der IF-Anweisung. Das return stoppt das Template an dieser Stelle.

[Alexander]

Hi Andreas,

vielen Dank für deine nächtliche Reaktion!:-)
Also folgendes Template habe ich daraus dann erstellt:

<?php echo $this->rteConfig; ?>
 
<form action="<?php echo $this->action; ?>" id="<?php echo $this->formId; ?>" method="post" enctype="<?php echo $this->enctype; ?>">
<div class="formbody">
<input type="hidden" name="FORM_SUBMIT" value="<?php echo $this->formId; ?>">
<input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}">
<table cellspacing="0" cellpadding="0" summary="Table holds form input fields">
<?php echo $this->field; ?>
  <tr class="<?php echo $this->rowLast; ?>">
    <td class="col_0 col_first">[nbsp]</td>
    <td class="col_1 col_last">
      <div class="submit_container">
<input type="submit" name="save" id="save" class="tl_submit" accesskey="s" value="<?php echo specialchars($GLOBALS['TL_LANG']['MSC']['save']); ?>">
<input type="submit" name="saveNclose" id="saveNclose" class="tl_submit" accesskey="c" value="<?php echo specialchars($GLOBALS['TL_LANG']['MSC']['saveNclose']); ?>">
<input type="submit" name="saveNcreate" id="saveNcreate" class="tl_submit" accesskey="n" value="<?php echo specialchars($GLOBALS['TL_LANG']['MSC']['saveNcreate']); ?>">
      </div>
    </td>
  </tr>
</table>
</div>
</form>


<?php echo '<pre>';
print_r($GLOBALS);
echo '</pre>'; 
?>

Allerdings gibt mir das FE nichts aus auf der Seite. Es entsteht nach wie vor nur der oben erwähnte Code. Binde ich es nach wie vor falsch ein? :-)

Beste Grüß
Alexander

[Andreas]

Nein, ist richtig. Suche mal im FE im Quelltext nach dem pre, wenn du das nicht findest, wird das Template nicht ausgegeben. $GLOBALS ist in PHP immer vorhanden, unabhängig von Contao.

[Allan]

@Alexander: Problem schon gelöst?

Gruß
Allan

[izanagi]

Also ich habe mit catalogeditsingleown nie gearbeitet, hatte mir damals alles selbst zusammgebastelt damit der User nur seine Katalogitems sieht und bearbeiten kann.
Ich habe das Modul "Katalog-Liste" die habe ich im User Account Bereich zur Verfügung gestellt.
Das Modul hat folgende Konfig:

Weiterleitung > Katalog-Reader Seite
Sichtbare Felder > BenutzerID [xyz:useridfield]
Bearbeitung aktivieren > aktiv
Sprung zur Seite > Katalog-Edit Seite
Katalog-Layout > catalog_eigeneliste

das Template "catalog_eigeneliste" ist eine Kopie der catalog_simpletable und bekam von mir folgende modifikation:

In Zeile 1 folgendes:

<?php $this->import('FrontendUser', 'User');
$user = $this->User->id;
?>

Ab Zeile ca. 14 den kompletten tbody (bis ca.33) Inhalt ersetzt mit :

<tbody class="body<?php echo $entry['class'] ? ' '.$entry['class'] : ''; ?>">
<?php foreach ($this->entries as $entry): ?>
<?php if ($entry['data']['paten_benutzerid']['raw'] == $user): ?>
<tr class="item<?php echo $entry['class'] ? ' '.$entry['class'] : ''; ?>">
<?php foreach ($entry['data'] as $field=>$data): ?>
<?php if (!in_array($field, array('catalog_name','parentJumpTo'))): ?>
    <td class="field <?php echo $field; ?>"><?php if (strlen($data['value'])): ?>
    <?php echo $data['value']; ?>
<?php endif; ?>
</td>
<?php endif; ?>
<?php endforeach; ?>
<?php if ($entry['showLink'] && $entry['link']):  ?>
<td class="link"><div class="link"><?php echo $entry['link']; ?></div></td>
<?php endif; ?>
<?php if ($entry['linkEdit']): ?>
<td class="edit"><div class="linkEdit"><?php echo $entry['linkEdit']; ?></div></td>
<?php endif; ?>
</tr>
<?php endif; ?>
<?php endforeach; ?>
</tbody>

Im Prinzip einfach nur eine Abfrage dazwischen gesetzt die den User rausfiltert.

[Andreas]

Ja, das kannst du machen, aber die Liste bietet ja schon die Möglichkeit eine Bedingung anzugeben. Dann kannst du dir das im Template sparen, da die entries, welche die Bedingung nicht erfüllen dort erst gar nicht ankommen.

Ich würde das edit auch über eine Liste ansteuern, die halt nur die entries zeigt, die auch bearbeitet werden dürfen. Bleibt aber immer noch das Problem, dass das edit Modul auch andere entries bearbeiten würde, wenn nur der entsprechende Datensatz über die URL mit dem GET-Parameter angesteuert wird. D.h. der GET in der URL kann leicht manipuliert werden.

Ich hatte das gestern so gelöst, dass ich bei der Listenausgabe die erlaubten entries (die ID davon) in die Session geschrieben habe. In dem edit Template habe ich dann den GET-Parameter mit den erlaubten entries in der Session abgeglichen und ne Weiterleitung zurück auf die Liste gesetzt, wenn's nicht passt.

In der Liste sah das so aus

// Set allowed items to session for a last safety check in edit modul
// $arrAllowedItems natürlich vorher irgendwo mit den erlaubten IDs aufgebaut.
if(count($arrAllowedItems) > 0)
{
  $this->Session->set('arrAllowedItems', $arrAllowedItems);
} 

Im Template für das edit Modul dann das

// Parameter übergeben? Bearbeitung erlaubt?
if(!$this->Input->get('items') || !in_array(intval($this->Input->get('items')), $this->Session->get('arrAllowedItems')))
{
  require_once 'system/libraries/System.php';
  System::redirect('liste.html');
} 

[izanagi]

Hi Andreas, das stimmt die Bedingung ist ja extra dafür da... bitte frag mich auch nicht warum ich es ins Template gebaut hab, da war mal irgendwas vor längere Zeit... ein Problemchen.. ich weiss es nicht mehr ^^ aber normalerweise reicht die Bedingung ja aus.

Das Problem der Manipulation habe ich nicht. Bei mir wird "sie haben keine Berechtigung" angezeigt weil ich im Katalog-Edit das Bearbeitbare Feld BenutzerID [xyz:useridfield]" aktiv hab
Die Sicherheitsfunktion ist also schon irgendwie implementiert.


EDIT: ach jetzt weiss ich was nie geklappt hat. FIND_IN_SET({{user::id}}, xyzbenutzerid) funktioniert in den Bedingungen nicht ebenso wenig wie {{user::id}}=xyzbenutzerid
Die Bedingen ist ja ne SQL Abfrage und da gibts kein InserTag

EDIT2: looooooool ich glaub ich hab Alzheimer..... jetzt weiss ich wie das Problem entstanden ist

https://www.contao-community.de/showthread.php?29013-Inserttags-in-Lister-Bedingungen

[Andreas]

Ja, manchmal muss man es halt im Template machen, z.B. auch wenn du alle ausgeben willst, aber den Link zur Bearbeitung nur denen mit Berechtigung.

Geht das inserttag nun im Bedingunsfeld? Ich denke ja. Ich habe mir da auch ne dynamische Bedingung rein geholt mit {{file::build_query.php}}. Ah, dann muss inserttag dort ja gehen.

Ah, dann reicht also die Anwesenheit des userid fields im edit formular, dass du nur die eigenen bearbeiten kannst? Haste mal nen test gemacht? GET von nem verbotenen in die URL geschrieben?

Ist bei mir wohl so, da ich noch kompliziertere Rechte habe - der zu bearbeitende Datensatz gehört dabei mehreren FE-Usern (Teamcaptains einer Spielgruppe - Ergebnismeldung - und die Teams der Gruppen variieren nat. von Saison zu Saison).

[Tim G]

Ja, manchmal muss man es halt im Template machen, z.B. auch wenn du alle ausgeben willst, aber den Link zur Bearbeitung nur denen mit Berechtigung.

Geht das inserttag nun im Bedingunsfeld? Ich denke ja. Ich habe mir da auch ne dynamische Bedingung rein geholt mit {{file::build_query.php}}. Ah, dann muss inserttag dort ja gehen.

Ah, dann reicht also die Anwesenheit des userid fields im edit formular, dass du nur die eigenen bearbeiten kannst? Haste mal nen test gemacht? GET von nem verbotenen in die URL geschrieben?

Ist bei mir wohl so, da ich noch kompliziertere Rechte habe - der zu bearbeitende Datensatz gehört dabei mehreren FE-Usern (Teamcaptains einer Spielgruppe - Ergebnismeldung - und die Teams der Gruppen variieren nat. von Saison zu Saison).

Ich hatte mal einen ähnlichen Fall mit dem Auflistungs-Modul. Dort hat FIND_IN_SET partout nicht funktioniert mit einem Inserttag, aber mit IN.
Also hier:
xyzbenutzerid IN ({{user::id}})

Ich hatte eine Kommaliste per POST geschickt und mit inputvars eingesetzt. Das hat funktioniert.