Max. Feldlänge ist -1 bzw. 10 für Feldtypen, die keine Nummer im Feldnamen tragen

Hallo zusammen,

wollte eigentlich einen Bug report senden, erhalte dort beim Abschicken aber ein “403 Foribbden” ;( da ich den Text aber nicht umsonst geschrieben haben wollte, poste ich ihn mal hier. Auf Englisch, weil war wie gesagt für das Ticketsystem gedacht:

"The method \OxidEsales\EshopCommunity\Core\Database\Adapter\Doctrine\Database::getColumnMaxLengthAndScale checks for numbers in database field names and uses those as the max. field length. This works for VARCHAR, DECIMAL etc., but not for other types like floats or text. or types that have an optional provided max. length.

In line 1337 there is supposed to be an assignment of the default max length, but it’s not implemented.

This results in all types having a field length of -1 if they don’t have a numeric value as part of their database field name.

The method \OxidEsales\EshopCommunity\Core\Model\BaseModel::_getNonCachedFieldNames then checks for the -1 and sets a max. length of 10 as default, so text field for example, who normally have a max. length of 65.535 characters now have a max. length of 10."

Steps to reproduce:
“Example: Change the field type of OXSHORTDESC in the oxarticles table from VARCHAR(255) to TEXT.
Clear the cache (make sure the txt file containing the oxarticles table information is deleted).
Go to the admin page, edit an article and inspect the short description field, it should have a max. length of 10.”

Aufgefallen ist es in der 6.5.0, Fehler ist aber auch schon in früheren Versionen vorhanden.

Viele Grüße,
Malte

Was ist die Frage? Das Problem ist IMHO, dass Text nicht limitiert werden kann und die Abfrage in _getNonCachedFieldNames deswegen keinen Max-Wert erhält und das Feld auf 10 Zeichen begrenzt. Hier kannst die Methode adäquat zu datetime erweitern und z.B. den Wert 65535 vorgeben.

Hey,

vielen dank für die Rückmeldung. Frage eigentlich keine, war eher als Hinweis Richtung @OXID gedacht, weil beim Absenden im Bugtracker ein 403 Forbidden kam. Ggf. kann das in einer zukünftigen Version korrigiert werden, in der getColumnMaxLengthAndScale ist ja ein Todo vorgesehen, entsprechende MySQL-Standardwerte für solche Feldtypen zurückzugeben. Denn aktuell ist die Feldlänge bspw. im Artikel-Objekt bei vielen Feldern einfach falsch; so hat z.B. auch die Longdesc eine max. Länge von 10 angegeben, was nur im Standard nicht auffällt, weil es nirgendwo geprüft wird.

Also, kein dringendes Thema, im betroffenen Kundenprojekt wissen wir uns erstmal zu helfen, nur als Hinweis zu verstehen.

Viele Grüße,
Malte

Ich habe es selbst gerade mal versucht und einen Testuser registriert und hatte kein Problem ein Ticket anzulegen. Warst du vielleicht ausgeloggt?
Kannst du es bitte noch einmal versuchen?

Hallo Sven,

bekomme den Fehler nach wie vor, siehe: Startseite - OXID eShop bugtrack – Opera 2023-01-11 09-58-33.mp4 - Google Drive

Das ist in meinem Standard-Browser (Opera). Habe mich danach noch einmal in Chrome neu eingeloggt > selbes Problem.

Ich hatte das gleiche Problem mit dem Bugtracker im Dezember ebenfalls, aber mittlerweile scheint es wieder zu funktionieren.

Ich habe testweise mal versucht dieses Ticket anzulegen, aber ich erhalte hierfür ebenfalls wieder ein “Forbidden”. Kann es ggf. sein, dass bestimmte Zeichen verboten sind und eine temporäre Sperre auslösen?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.