Ah ok, checked the code, you are talking about cleanBillingAddress and cleanDeliveryAddress methods.
You are right, this could affect extended createUser method functionality, just because its one huge mess and I assume nobody calls parent on it’s extended method and this core patch becomes useless. And of course think about other implementation cases .. > On 20 Jun 2016, at 19:23, Tomas Kvietkauskas <tomas.kvietkaus...@nfq.com> > wrote: > > Hi Dirk, > > thanks for your insights, > could you please name methods that were changed from protected to private? > > - > Thanks > >> On 20 Jun 2016, at 17:36, Dirk Mueller <dirkmuelle...@yahoo.de> wrote: >> >> >> >> >> Hi, >> >> be aware that the two new implemented methods in oxcmp_user class at the >> previous security patch have been declared as "private functions". >> >> Is there any reason to use "private functions" instead of "protected >> functions"? >> >> Current situation could kill modules which are overwriting "createUser()" >> and "_changeUser_noRedirect()" methods in oxcmp_user class as private >> methods do break the inheritance chain. >> >> So, whenever you are updating your shops or adding the current security >> patch you should also check all modules in your shop which are overloading >> or overwriting the oxcmp_user class. >> >> @OXID devs: What's you opinion about this? Do you think we can change a.m. >> methods to protected functions? >> >> Best regards, >> Dirk Müller >> >> _______________________________________________ >> dev-general mailing list >> dev-general@lists.oxidforge.org >> http://dir.gmane.org/gmane.comp.php.oxid.general > > _______________________________________________ > dev-general mailing list > dev-general@lists.oxidforge.org > http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
