Bug in xtcPrice-Klasse in xtcGetGraduatedPrice()

[noRiddle]

In der Funktion xtcGetGraduatedPrice() in Zeile 298 wird abgefragt

if (count($graduated_price_array) > 0

Ich meine das müsste so lauten

if (count($graduated_price_array[$this->actualGroup][$pID]) > 0

Andernfalls gibt die Funktion immer etwas zurück und es greift SpecialGraduated auch wenn es nicht greifen dürfte, weil es keinen Kundengruppenpreis > 0 (personal_offers_by_customers_status_X) gibt.

Das hat wiederum zur Folge, daß, wenn man für ein Produkt SpecialDiscount hat, dieser preisanzeigen-technisch nicht greift und die Preisanzeige entsprechend nicht korrekt ist.

Das fällt erst auf wenn man mal einen Artikel im Backend geöffnet und gespeichert hat und sich dann wundert, daß die Preisanzeige sich geändert hat, weil dann nämlich, auch wenn man keine KG-Preise vergeben hat, Einträge in den personal_offers_by_customers_status_X-Tabellen gemacht wurden, und zwar mit 0.0000.
In dem Zusammenhang frage ich mich allerdings auch warum dies geschieht, also warum die Tabellen mit 0.0000-Einträgen bestückt werden, was doch imho unnötig ist und die Tabellen unnötig aufbläht.

Gruß,
noRiddle

[Gerhard Waldemair]

In 14760:

fix #2353 - check single price for product

[noRiddle]

Weiß nicht wie es gefixt wurde.
Wurden auch die unnötigen Einträge von 0.0000 in die personal_offers_by_customers_status_X-Tabellen abgeschafft ?

Gruß,
noRiddle

[Gerhard Waldemair]

Die 0.0000 Preise ist historisch und wurde in 2.0.7.0 korrigiert meine ich. Hat aber auch zur Folge, dass kein Kundengruppenpreis mit 0 eingtragen werden kann.

Also dass zB eine Kundengruppe einen bestimmten Artikel kostenlos bekommt ist so dann nicht mehr möglich.

[noRiddle]

Ich hatte es in 2.0.7.2, es werden nach wie vor die 0.0000 Preise gespeichert.
Habe mir den Code mal angeschaut. In der categories-Klasse finde ich in der Tat dies.

      if (isset($products_data['products_price_'.$customers_status['id']])) {
        $personal_price = xtc_db_prepare_input($products_data['products_price_'.$customers_status['id']]);
        if ($personal_price == '' || $personal_price == '0.0000') {
          $personal_price = '0.00';
        }
        $personal_price = $this->priceCheck($personal_price, $products_tax_rate);
        
        
        if ($personal_price > 0) {
          $sql_data_array = array(
            'personal_offer' => $personal_price,
            'quantity' => '1',
            'products_id' => $products_id
          );
          xtc_db_perform(TABLE_PERSONAL_OFFERS_BY.$customers_status['id'], $sql_data_array);
        }
      }

Wenn man "Aktualisieren" anstatt "Speichern" klickt werden die 0-Werte allerdings trotzdem in der DB gespeichert. Habe noch nicht herausgefunden warum (getestet in der aktuellen 2.0.7.2).

Man könnte es übrigens ja auch so implementieren, daß 0 zulässig ist und nur wenn der POST-Wert leer ist nichts in die DB speichern. Dazu müsste man ja, neben der Anpassung im zitierten Code, nur noch eine kleine Anpassung in der Funktion priceCheck() machen.

Gruß,
noRiddle

[Gerhard Waldemair]

ich habe den Übeltäter gefunden. Schau mal die Function get_group_price() in der general.php an...

[Gerhard Waldemair]

In 14847:

fix #2353 - prevent zero for personal offer

[noRiddle]

Ha, und ich hab' mich blöd gesucht und schrittweise Ausgaben im Browser gemacht es aber nicht gefunden.
Sehr gut.

Gruß,
noRiddle