Jump to content
  • 0

[Presta 1.6.1.4] Dublowanie adresów klienta


() Maciej ()

Question

Witam,

Zauważyłem dość poważny problem. Po aktualizacji sklepu do tytułowej wersji 1.6.1.4 każda najdrobniejsza zmiana wpisu z adresem klienta dokonana z poziomu frontoffice powoduje utworzenie nowego wpisu z osobnym numerem ID Adresu.

Oczywiście wszystkie wpisy poprzednie dalej są dostępne dla klienta.

 

Dla przykładu.

Klient składa zamówienie i się rejestruje. Wpisuje adres dostawy > klika zapisz > zauważa błąd i go poprawia klikając ponownie zapisz > na liście rozwijanej z adresami ma wtedy 2 dostępne adresy.

 

Czy ktoś jest mi w stanie podpowiedzieć, gdzie presta trzyma skrypty odpowiedzialne za dodawanie kolejnych adresów do bazy ?

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0

A więc tak :

- tablica ps_address dostaje status "deleted" ale tylko i wyłącznie w adresach edytowanych przez panel administracyjny (backoffice) lub dla starych kont klientów (frontoffice). W przypadku zakładania konta przez klienta w trakcie rejestracji nie następuje ustawienie wartości 1 dla tego rekordu.

 

Jak sprawdzę pliki PHP to dam znać, czy tam coś znalazłem.

Edited by () Maciej () (see edit history)
Link to comment
Share on other sites

  • 0

Porównałem pliki PHP, które wskazałeś. Są identyczne (tak mi się wydaje), ale zaczął mnie zastanawiać zapis jednej funkcji :

    public static function aliasExist($alias, $id_address, $id_customer)
    {
        $query = new DbQuery();
        $query->select('count(*)');
        $query->from('address');
        $query->where('alias = \''.pSQL($alias).'\'');
        $query->where('id_address != '.(int)$id_address);
        $query->where('id_customer = '.(int)$id_customer);
        $query->where('deleted = 0');

        return Db::getInstance(_PS_USE_SQL_SLAVE_)->getValue($query);
    }

w pliku Address.php. Czy wartość dla deleted nie powinna tu wynosić 1 ? A jeśli to nie jest funkcja odpowiedzialna za ukrycie starego wpisu to gdzie jest funkcja za to odpowiedzialna ? Może w niej coś jest nie tak.

 

Ewentualnie, zastanawiam się nad przestawieniem wartości zmiennej w :

    /** @var bool True if address has been deleted (staying in database as deleted) */
    public $deleted = 0;

na wartość 1.

Mając program magazynowy historia zmian w adresach w samym sklepie jest mi chyba zbędna. No chyba, że są jakieś przepisy unijne to regulujące.

Link to comment
Share on other sites

  • 0

Status deleted=1 dla rekordu adresu jest ustawiany tylko wtedy gdy edytowany adres był już wykorzystany w zamówieniu, sprawdzane jest to za pomocą funkcji isUsed z Addres.php.


Sprawdź szablon Twojej templatki, plik address.tpl

w oryginalnym szablonie PS 1.6.1.4 jest wpis:

{if isset($id_address)}<input type="hidden" name="id_address" value="{$id_address|intval}" />{/if}


dla edytowanego adresu, od strony kodu przeglądarki powinno wyglądać to tak:

<input name="id_address" value="XX" type="hidden">  - gdzie XX to id adresu

sprawdź za pomocą inspektora przeglądarki czy coś takiego istnieje, i jaką ma wartość, powinna być zgodna z id_address w url


ps
uzyskałem taki efekt duplikowania edytowanych adresów po usunięciu tego wpisu z szablonu
 

Link to comment
Share on other sites

  • 0

I tak właśnie wygląda. Zauważyłem jednak dziwną prawidłowość.

Taki cyrk dzieje się tylko w sytuacji kiedy następuje edycja adresu ze strony potwierdzenia zamówienia (układ zamówienia na 1 stronie) i to tylko dla zamówień jako gość. Wtedy każda kolejna edycja adresu zamiast edytować konkretne ID adresu tworzy nowe ID ze zmodyfikowanymi danymi.

 

Cały problem w tym, że lokalnie nie jestem w stanie odtworzyć tego zjawiska. Tworze nowe zamówienia ze swojego komputera edytując adres przy każdej najdrobniejszej zmianie i nic. Klient w tym czasie robi zamówienie jako gość i dubluje adresy :/

 

--------------------------------------------------

EDIT :

 

Edytując adresy kont testowych o ID 1 oraz 6 następuje zmiana ID adresu np z ID 2 na ID 4044 (czyli kolejne wolne), a ID 2 znika z listy. Czyli tu się potwierdza to co pisałeś, że funkcja isUsed z Addres.php działa. Dla tych ID adresów były zamówienia realizowane.

 

------------------------------------------------------

EDIT 2 :

Wreszcie się udało odtworzyć błąd.

Z tego co zauważyłem problem występuje w przypadku kiedy poprzedni adres był już użyty w jakimś zamówieniu.

Powinno to wyglądać tak

Stary adres > edycja > tworzy się duplikat ze zmienionymi danymi, a stary adres dostaje "deleted=1"

a jest

 

Stary adres > edycja > tworzy się duplikat ze zmienionymi danymi, a stary adres dostaje "deleted=0"

czyli się nic nie zmienia.

Edited by () Maciej () (see edit history)
Link to comment
Share on other sites

  • 0

Po wgraniu nowej presty problem dalej występuje, więc coś podejrzewam, że to zamierzone przez programistów.

Choć dziwi mnie fakt, że przy ręcznej edycji adresu z panelu admina następuje duplikacja adresu i pozostawienie starego widocznego. Fakt faktem jest przypisany stary adres w 2 miejscach. Tzn do adresu dostawy i adresu rozliczenia, ale moim zdaniem powinno to wyglądać tak jak kiedyś, czyli edytuje 1 adres i zmieniają się oba. Obecny stan robi straszny syf w bazie i sklepie, bo klienci co chwilę piszą, że edytowali adres i mają teraz ich 10 na liście.

 

Czy ktoś z Was wie może jak przywrócić poprzedni sposób edycji adresów ? Tzn edytuję adres z poziomu panelu i edytuje się on dla wszystkich miejsc jego przypisania bez tworzenia nowego ID i przypisywania do miejsca, w którym jest dokonywana edycja.

Poza jednym jedynym plusem (zapisywaniem starych danych adresowych np dla faktur) nie widzę najmniejszego sensu takiego rozwiązania. Szczególnie, że w tym przypadku wykorzystywany jest zewnętrzny program księgowy. A więc stare adresy w bazie presty są mi zbędne.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...