wakabayashi Posted December 5, 2022 Share Posted December 5, 2022 (edited) Right now I am cleaning up the identity controller (when customer changes his profile in frontOffice) a little bit. IMO it was done a bit untidy. For my store I will also change the behaviour a little. I wondered, if it's wanted in the core to: Using date field type for birthday instead of three selects (dd-mm-yyyy). Now customer are forced to type their password each time, they change their profile. I want to make this restriction only, if he changes his password or eail. Why? At registration we have optional fields like birthday. Later I hope a customer would complete their profile, but obviously don't want to force them to type their password. As an user I hate such tasks. My brain says: ok sorry, then no birthday. I will implement an account deletion apply function. Important: it's an apply. A merchant will be notified somehow about it and then he can handle it. Of course this will also require the user to type his current password. This could also be implemented by a module, but IMO this functionality is kind of a core thing (at least much more than other things being on core). Opinions? Edited December 5, 2022 by wakabayashi Link to comment Share on other sites More sharing options...
the.rampage.rado Posted December 5, 2022 Share Posted December 5, 2022 1. I would like the option to turn off this field altogether because I don't need this information, I don't do such statistics and it's slowing the registration + GDPR.... 2. I'm not sure that if the customer is logged in they should not be asked for a pass for changing anything other than (stored) payment details (which we don't store as far as know anywhere in TB). 3. This is a must for TB core as per GDPR. It would be nice to be extended with the other GDPR bloatware too. And there should be simple switch somewhere in BO (Do you need GDPR? Yes/No), then those options become visible. Merchants who don't care about it don't use it and their BO doesn't get bloated with stuff. Link to comment Share on other sites More sharing options...
wakabayashi Posted December 5, 2022 Author Share Posted December 5, 2022 1 hour ago, the.rampage.rado said: 1. I would like the option to turn off this field altogether because I don't need this information, I don't do such statistics and it's slowing the registration + GDPR.... It would be easy to add another configuration switch, but I dont like this idea as the BO is already now bloated with configurations. Somehow we need a proper form handler that allows required/optional setting for each field and allows to add custom fields. Obviously that's a huge and complex task, that won't come soon. I would recommend you, to just use CSS and hide the birthday field 🙂 1 hour ago, the.rampage.rado said: 2. I'm not sure that if the customer is logged in they should not be asked for a pass for changing anything other than (stored) payment details (which we don't store as far as know anywhere in TB). Thought that too. But also thought, if somebody goes on your computer, while you are logged in... That's why I want to secure password change, email change and account deletion. The rest isnt too critical imo. Saving payment infos on tb is crazy imo, I would never do it. 1 hour ago, the.rampage.rado said: 3. This is a must for TB core as per GDPR. It would be nice to be extended with the other GDPR bloatware too. And there should be simple switch somewhere in BO (Do you need GDPR? Yes/No), then those options become visible. Merchants who don't care about it don't use it and their BO doesn't get bloated with stuff. Yeah I thought so, that this feature could even be a must in some countries. In general I don't think that all GDPR settings should be in core. Actually there is a module, but maybe it was never finished (?) https://github.com/thirtybees/tbgdpr. I don't need GDPR and don't know the rules, that's why I won't work on this deeply. How are you handling it now? Link to comment Share on other sites More sharing options...
the.rampage.rado Posted December 5, 2022 Share Posted December 5, 2022 13 minutes ago, wakabayashi said: Yeah I thought so, that this feature could even be a must in some countries. In general I don't think that all GDPR settings should be in core. Actually there is a module, but maybe it was never finished (?) https://github.com/thirtybees/tbgdpr. I don't need GDPR and don't know the rules, that's why I won't work on this deeply. How are you handling it now? Flying low under the radar.... :/ 1 Link to comment Share on other sites More sharing options...
wakabayashi Posted December 5, 2022 Author Share Posted December 5, 2022 3 minutes ago, the.rampage.rado said: Flying low under the radar.... 😕 I would do the same ^^ The module above is crap? Link to comment Share on other sites More sharing options...
wakabayashi Posted December 7, 2022 Author Share Posted December 7, 2022 No other opinions on this topic? Link to comment Share on other sites More sharing options...
the.rampage.rado Posted December 7, 2022 Share Posted December 7, 2022 (edited) On 12/6/2022 at 12:40 AM, wakabayashi said: I would do the same ^^ The module above is crap? Never tried it. Will do now. Unable to install. But I don't have time to test what's the issue Edited December 7, 2022 by the.rampage.rado Link to comment Share on other sites More sharing options...
wakabayashi Posted December 8, 2022 Author Share Posted December 8, 2022 PR are out: https://github.com/thirtybees/thirtybees/pull/1582 https://github.com/thirtybees/niara/pull/65 At the moment only the password confirmation handling was changed in Niara. The birthday is still handled the old way. The deletion apply was not implemented yet, as I am not sure, if it's really wanted. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now