Ivan Gretsky Posted February 28, 2015 Share Posted February 28, 2015 Good day! I am building a subscription based site. I created additional template for subscribed users. When I create a user he is created unpublished with the same pass for all. When the payment is completed, the status is changed to published via API. It works as expected. But when I try to publish a user from the admin, I am asked to input a password, though it already exists in the database. Each time I unpublish/publish a user from the admin I have to change a password. Is this a normal behaviour or a bug? Can it be overriden somehow as this is not desired behaviour for my case (I want to let admin publish a user without changing password)? Link to comment Share on other sites More sharing options...
LostKobrakai Posted February 28, 2015 Share Posted February 28, 2015 I think this is not intended. I'd try to create a user manually in the admin, give it a password and check if this triggers the same behavior. 1 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted February 28, 2015 Author Share Posted February 28, 2015 Did try that - I get the same behaviour. But please check it if you got time. Link to comment Share on other sites More sharing options...
Martijn Geerts Posted February 28, 2015 Share Posted February 28, 2015 It's not a bug, it's how Inputfields work. They compare the value stored in the database with the value from the form. ( ___processInput methode) When the two don't match, then $this->trackChange('value') is called that tells PW to change the value and thus the password to. The easiest way to get around this is to handle unpublished users your self. (Not via admin or with custom module) Or you could ask ryan to change this behaviour. Probably not really difficult to implement. Link to comment Share on other sites More sharing options...
LostKobrakai Posted February 28, 2015 Share Posted February 28, 2015 It's not a bug, it's how Inputfields work. They compare the value stored in the database with the value from the form. ( ___processInput methode) When the two don't match, then $this->trackChange('value') is called that tells PW to change the value and thus the password to. This would mean, that you have to insert the password every time you save a user, which is definitely not the case. The "real" password isn't even stored in the db, so there's no way to pre-populate the password field with a value, thus it has to have a blank state, where it won't trigger a database comparison / save. Just un-/publishing a user should normally not intrude this behavior, at least in my opinion. 2 Link to comment Share on other sites More sharing options...
Martijn Geerts Posted February 28, 2015 Share Posted February 28, 2015 Think you're right and I'm totally wrong, sorry Thanks for your respond LoastKobrakai. Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted March 1, 2015 Author Share Posted March 1, 2015 @LostKobrakai - Did you have a chance to confirm the bug? @Martijn Geerts Or you could ask ryan to change this behaviour. Probably not really difficult to implement. How do I do it? Should I make a github issue, pm him, or this topic is enough? Link to comment Share on other sites More sharing options...
LostKobrakai Posted March 1, 2015 Share Posted March 1, 2015 I just tried to see if I've the same problem, but in the current dev there's no setting to un-/publish a user, even with advanced mode enabled. So maybe it's because Ryan never anticipated this to be used. To circumvent the issue you could maybe use a additional role, which you set/unset for users. 1 Link to comment Share on other sites More sharing options...
Ivan Gretsky Posted March 2, 2015 Author Share Posted March 2, 2015 @LostKAbrakai I think this functionality is uncovered when you perform these steps to add different template and root for users. Your advice about using roles instead of published status is probably the way I will have to go. But it seems like we are using a detour instead of a shortcut)) I will try writing a github issue anyway. Link to comment Share on other sites More sharing options...
LostKobrakai Posted March 2, 2015 Share Posted March 2, 2015 But it seems like we are using a detour instead of a shortcut)) I will try writing a github issue anyway. I really feel the exact opposite way. You are trying to stuff a permission decision (is the user allowed to do something based on payment) into something that limits viewability but does not change the permissions of a user. The right way to go would much rather be something like a role "has_payed", which can get permissions like "can access feature X", "can access feature Y". If you're later getting to a stage of different subscriptions you can easily modify it to have roles like "has_payed_model_basic", "has_payed_model_advanced" and reuse all the permissions you used before, without even the need to touch you code. 1 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