Cannot republish users without password change

[Ivan Gretsky]

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)?

[LostKobrakai]

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. 

[Ivan Gretsky]

Did try that - I get the same behaviour. But please check it if you got time.

[Martijn Geerts]

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. 

[LostKobrakai]

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.

[Martijn Geerts]

Think you're right and I'm totally wrong, sorry 

Thanks for your respond LoastKobrakai.

[Ivan Gretsky]

@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?

[LostKobrakai]

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.

[Ivan Gretsky]

@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.

[LostKobrakai]

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.