PaymentOptionsBuilder gets the order's customer and then, if the customer isAuthenticated() will show the stored options for that customer. Whilst in core, isAuthenticated() is a direct opposite of isAnonymous(), it's possible to override the user entity class and make modifications to that for other purposes (in our case we have a CRM, so we have users stored that are not anonymous, but also have no login credentials, so are not authenticated).
There are also a bunch of other places, such as payment gateways, profiles, receipts etc that do the same.
Switch to checking !isAnonymous() where we are trying to identify accounts that are not the anonymous user.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3165903-4-switch_to_is_anonymous.patch | 6.9 KB | mrdalesmith |
| #3 | 3165903-3-switch_to_is_anonymous.patch | 6.45 KB | andrewbelcher |
Comments
Comment #2
andrewbelcher commentedHere's a patch to make the switch.
Comment #3
andrewbelcher commentedThere are various other places which do the same, so here's a patch where I've gone through every call to
User::isAuthenticated()and, where I think appropriate, switched it to!User::isAnonymous().Comment #4
mrdalesmith commentedUpdated patch as it no longer applied to the latest version.
Comment #7
jsacksick commentedI think this makes the code a little bit less readable... But if this helps with your usecase... The thing is, if we follow your reasoning then what guarantees that the
isAnonymous()method will always contain logic that work in our cases?I'm guessing the problem is how core named its methods,
isAuthenticated()makes it sound the user is actually authenticated while the check performed only ensures the$user->uid() > 0.Since I committed an equivalent patch already previously, decided to also commit this one though we'll probably have to make sure to not forget about this when it comes to adding similar checks in the future.