projekt kivitendo

CustomerVendor-Picker: 'type' nicht als html-Attribut setzen

Die Parameter des Picker-Aufrufs werden an das Input-Tag weitergeben und so
wurde das type-Attribut mit dem Typ (customer/vendor) des Pickers
überschrieben.

Presenter::CustomerVendor: interface normalisiert

es gibt jetzt zusätzlich:
- customer_picker
- vendor_picker

die auf den jeweiligen typ gecrurried sind

Presenter: Sub-Presenter auf Funktional geändert

1. alle Sub-Presenter aus dem SL::Presenter Namespace geschmissen

2. Keine ungefragten @EXPORTs mehr, nur noch @EXPORT_OK

3. Alle Methoden sind auf Funktionen umgeschrieben (kein $self mehr)

4. Die benötigten Methoden von Sub-Presentern müssen jetzt direkt importiert...

CustomerVendor Picker: auf prototype Picker umgestellt analog zu Part

CustomerVendor-Presenter: neue Funktion customer_vendor()

Damit der Aufrufer nicht im Vorfeld entscheiden muss, ob $object ein
Kunde oder ein Lieferant ist.

CustomerVendor Picker auf displayable_name umgestellt

Sowohl im Autocomplete als auch beim ausgewählten Kunden/Lieferanten
wird jetzt immer Kunden/Lieferantennummer und Name angezeigt.

Customer-autocomplete js im Presenter laden

Im Gegensatz zu den Stellen in oe/do/ir/is (siehe Commit 65b7c724e)
reicht es beim Bearbeiten von BDVs in den Stammdaten aus, den
Autocomplete Code im Presenter zu laden, so wie dies auch beim
PartPicker und Chartpicker gemacht wird.

CustomerVendorPicker: ref($value) nur prüfen, wenn es tatsächlich ein Objekt ist

…und nicht schlicht die ID eines Objektes.

CustomerVendor-Presenter: croaken, wenn Parameter fehlen oder falsch sind

CustomerVendor: Picker nach Art von PartPicker

- reinit_widgets fähig
- Tab und Enter atomar
- unterstützt onChange und set_item:CustomerVendorPicker trigger
- unterstützt fat_set_item

Presenter->customer und ->vendor brauchen keinen $type.

Pflichtenhefte: Basisdaten verwalten, Such- und Listfunktion

Customer/Vendor-Pfade angepasst

Presenter-Module für Listen von Verkaufs-/Einkaufsobjekte