I had tried this on a fresh deployment with absolutely no changes anywhere (had been using Derby database).
Furthermore, the ant target gen-kek references old jars and need fixing as well. -- Vyom On 7 March 2014 08:52, Adam Heath <doo...@brainfood.com> wrote: > I'm surprised there was no test case on this. > > Do you have key-encrypting-key enabled in your new deployment? It's not > possible to enable that on an existing install. You'd have to do a > code-based copy, loading data from the old delegator, without kek, and > copying to a new delegator, with kek. > > But yes, file a jira, give as much detail as possible. > > I can definitely spend time this weekend looking at this. > > > On 03/06/2014 08:51 PM, Jacques Le Roux wrote: > >> This is quite unpleasant indeed, could you please open a Jira? I copy to >> Adam (doogie) because you mentioned it's related to data encryption >> change. Since Adam did it, he might find an easy solution for that. >> >> Thanks! >> >> Jacques >> >> >> Le 05/03/2014 19:05, Vyom Jain a écrit : >> >>> Hello Everyone, >>> >>> FinAccountHelper.getFinAccountFromCode() in trunk as well as in some >>> of the >>> released version is no longer able to fetch the Financial Account ID. So >>> all features dependent on this method would no longer work (an example >>> being paying by gift card during order entry process). >>> >>> Per my research, this stopped working method post some changes related to >>> how data is encrypted (two strings will not have similar encrypted >>> string). >>> >>> While I have figured out a workaround, which is not the ideal solution as >>> it takes away the advantage introduced by the new implementation and >>> switches back to 'old way' of storing encrypted data. I was wondering if >>> someone else has encountered this and has a better fix. >>> >>> -- >>> Vyom >>> >>> >
