Attribut data-object-id in inputItemList beim Bearbeiten eines UserFormField gleich 0

  • Affected Version
    WoltLab Suite 5.4
    Affected App
    WoltLab Suite Core

    Hallo,

    bei der Verwendung vom UserFormField ist mir folgendes Fehlverhalten aufgefallen:

    Wenn ich das Feld mit zwei Usern befülle sieht der Quellcode wie folgt aus:

    Wenn ich den Inhalt der Feldes aber jetzt bearbeite (sprich die UserIDs vorher an das Feld als Value übergebe) sieht der Quellcode wie folgt aus:

    Zusehen ist, dass das Attribut data-object-id den Wert 0, statt den Wert der ID hat. Neu hinzugefügt User haben beim Bearbeiten allerdings wieder ihre ID als Wert.

  • Tim Düsterhus February 16, 2022 at 3:54 PM

    Added the Label Confirmed
  • Tim Düsterhus February 16, 2022 at 4:11 PM

    Set the Label from Confirmed to Feedback required
  • Hallo,

    ich habe für Objekte Ansprechpartner, die der Autor von einem Objekt über das UserFormField hinzufügen kann. Anhand der Eingabe des Autors lade ich via. Javascript gewisse Daten der User nach, um diese im Formular noch mit anzuzeigen/das Formular zu modifizieren.

    Prinzipiell kann ich natürlich auch den Wert vom ".itemListInputShadow"-Input verwenden. Allerdings wird hier halt der Username verwendet, womit ich einfach nur ungern arbeite, wenn etwas eindeutigeres, wie z.B. hier die ID zur Verfügung steht.

    Aber ich kann verstehen, wenn das einfach ein sehr spezieller Use-Case ist und der offiziell dann einfach nicht unterstützt wird.


    Beste Grüße

    Titus

  • Kleine Ergänzung noch: Der oben beschriebene Use-Case funktioniert auch derzeit unter der Verwendung von data-object-id. Nur beim Bearbeiten und dortigem Entfernen eines Users kann so nicht eindeutig bestimmt werden, welcher User entfernt wurde (außer man nutzt die Usernamen statt die IDs).

  • Hallo,

    ich habe für Objekte Ansprechpartner, die der Autor von einem Objekt über das UserFormField hinzufügen kann. Anhand der Eingabe des Autors lade ich via. Javascript gewisse Daten der User nach, um diese im Formular noch mit anzuzeigen/das Formular zu modifizieren.

    okay, ich verstehe den Use Case, glaube aber nicht, dass das in Bezug auf die explizite API des FormBuilders eine gute Idee ist. Die HTML-Struktur und das JavaScript kann sich bei Bedarf ändern, wenn es erforderlich sein sollte (beispielsweise um die UX oder die Accessibility zu verbessern).

    Als Beispiel würde ich für das MultipleSelectionFormField (siehe: MultipleSelectionFormField - Button, um alle auszuwählen) nur annehmen, dass das Feld in irgendeiner Weise eine Mehrfachauswahl erlaubt. Aber ob das nun über ein Multiselect, über Checkboxen oder über die .scrollableCheckboxList passiert, bleibt offen. Die API ist das, was am Ende im PHP dabei herausfällt.

    Aber ich kann verstehen, wenn das einfach ein sehr spezieller Use-Case ist und der offiziell dann einfach nicht unterstützt wird.

    Ich würde anregen, dass du hier auf ein eigenes Feld speziell für deinen Einsatzzweck setzt (eigene Klasse, die nicht von UserFormField erbt, eigenes Template). Auf diese Weise kannst du das Verhalten des Feldes sehr genau kontrollieren und vermeidest damit Kompatiblitätsprobleme.


    Das ist im Endeffekt genau die gleiche Empfehlung, die ich gn5VmUKCtv6ekrMf auch hier gegeben habe (auch für das UserFormField): RE: Dependencies auf UiItemList-Felder fehlerhaft.

  • Tim Düsterhus February 17, 2022 at 2:28 PM

    Set the Label from Feedback required to Won’t fix

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!