enable/disable password field on User model using config

[ssi-anik]

WHY

Can disable password-related entries if the model doesn't have the password field. Scenario: Users can log in using the organization's SSO.

BEFORE - What was wrong? What was happening before this PR?

It was assumed that the model always has the password field.

AFTER - What is happening after this PR?

Developers can decide if they want to show or disable password-related inputs, true by default.

HOW

How did you achieve that, in technical terms?

??

Is it a breaking change or non-breaking change?

No

How can we test the before & after?

:shrug: I just tested using my own fork!

[welcome[bot]]

BOOM! Your first PR with us, thank you so much! Someone will take a look at it shortly.

Please keep in mind that:

• if this constitutes a breaking change, it might take quite a while for this to get merged; we try to emulate the Laravel release cycle as much as possible, so developers can upgrade both software once; this means a new big release every ~6 months;
• even if it's a non-breaking change, it might take a few days/weeks for the PR to get merged; unless it's a no-brainer, we like to have some community feedback on new features, before we merge them; this leads to higher-quality code, in the end; we learnt this the hard way :-)
• not all PRs get merged; sometimes we just have to hold out new features, to keep the packages lean; sometimes we don't include features that only apply to niche use cases;
• we're not perfect; if you think we're wrong, call us out on it; but in a kind way :-) we all make mistakes, best we learn from them and build better software together;

Thank you!

-- Justin Case The Backpack Robot

[tabacitu]

Hi @ssi-anik ,

Thanks for the PR, really appreciate the time you put in. But I think this is outside the scope of this package. If we account for people with SSO, another person will come tomorrow, asking that we should account for people using username & password. And this package isn't really meant to cover all use cases, just the most common one, which... it already does, I think 👀

So for people who need customization, I heavily recommend:

• (A) copy-pasting this code into their projects, and customizing the hell out of it 😀
• (B) if the changes are very small (eg. remove some fields and replace FormRequest), extending this package by binding new classes in AppServiceProvider to replace the classes this package provides; this will also make you receive updates for this package; but... as you can see from its history... it won't receive many updates, as we consider it feature-complete already;

Thank you for understanding. Cheers!