johnpicozzi → credited antiorario → .
johnpicozzi → credited antiorario → .
Marking this as fixed since it’s been merged.
This issue will become obsolete if 📌 [Opinions welcome] Remove customizable options Needs review goes forward. (And I’m very inclined to make it go forward, unless I get massive pushback.)
This issue will become obsolete if 📌 [Opinions welcome] Remove customizable options Needs review goes forward. (And I’m very inclined to make it go forward, unless I get massive pushback.)
I opened a MR with the proposed code changes (but I guess because I didn’t create a proper issue fork it’s not showing up on here 🤷🏼♂️🤦♂️): https://git.drupalcode.org/project/passwordless/-/merge_requests/9.
antiorario → created an issue.
antiorario → created an issue.
Whoa, that was a glaring omission. Fixed now, and I should have a new beta out later.
Fixed a long time ago, so I can safely close it.
I finally got to this issue, and realized that the corresponding issue in Drupal core was fixed a couple of years ago. I’m absolutely in favor of this, but I don’t think it should be optional—we should just follow best practices and Drupal core’s behavior.
I can see the point of this issue, but:
- I’m not sure why the confirmation should be different for login and registration—and in fact the proposed defaults are the same. Can we keep it simple and use the same settings for both, so there’s no need to have an update function?
- The branch has changed a lot since this was proposed (I’d been meaning to refactor a few things for a long time), so this code will need to be rebased and adapted.
antiorario → created an issue.
From what I can tell, this is fixed—probably in 🐛 Overriding the user.reset route is unnecessary Fixed .
Thank you @stefanos.petrakis for the contribution. In the meantime I’ve also worked on 🐛 Overriding the user.reset route is unnecessary Fixed , so I’ve had to make some adjustments. I’ll reject the original MR, but brought in your branch to work on, so hopefully proper credit will come through.
@joelseguin, I understand your need, but please create a new issue for that.
This module replaces the standard Drupal login form, so I’m inclined to think that Commerce Checkout is doing something to prevent that from happening. I welcome contributions, but this might be something that needs to be solved in Commerce Checkout or with a bridging module.
The changes in 🐛 Overriding the user.reset route is unnecessary Fixed should fix this issue, so I’m marking it as a duplicate.
This effectively breaks
#2641148: Allow custom redirection after login →
, but as RichardGaunt mentioned, it should be enough to implement hook_user_login().
Although I wouldn’t call this a proper bug, this issue raises a very good point, which boils down to letting Drupal do the heavy lifting and allowing Passwordless to do as little as possible, which has been my goal all along.
The main reservation I had was that making this change would inevitably introduce an extra step between clicking the login link and actually getting logged in (the good old “This is a one-time login…” form). But then I realized that this extra step would most likely be useful to fix 🐛 One-time login link processed by email clients / services Needs work , so I went for it. I’ll add the change straight to 2.0.x-dev.
Let’s see if the bot has anything to say about the 2.0.x branch.
Please let’s not reopen closed issues. There are deep usability issues with this request, one of which is what ptmkenny is saying in #8. This module is trying to provide basic functionality that doesn’t stray too far from Drupal’s design/interaction patterns.
Please review the requested changes in the MR.
Might be a bug in Views. I'm using the References module, not Entity reference, and I have the same problem. I'm also using Node Access User Reference and Node Access Node Reference for access control.