As an admin when I go to another user's address book and I add a profile, the profile owner is set to me instead of the user whose address book I was on. I'm using Commerce 2.14 and Profile 1.0.0.

Here is my theory thus far. It seems to me that Commerce is not supplying a user in the way that Profile does on its user tabs. Here is how it was done in Profile. I wonder if a similar pattern should be followed here? If that's the case, I'd be happy to work on a patch. Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lkacenja created an issue. See original summary.

lkacenja’s picture

Issue summary: View changes
lkacenja’s picture

Issue summary: View changes
ericchew’s picture

Status: Active » Needs review
FileSize
756 bytes

I ran into this issue today. This patch seems to fix it. Its kind of a workaround...it would take a lot of changes to replicate how Profile does it.

ericchew’s picture

For some reason my previous patch did not have the proper 'use' statements that it needed.

bojanz’s picture

Here's the full logic ported over from the Profile module, along with test coverage.

Contains the same security hardenings as Profile 1.1.

  • bojanz committed bb2d092 on 8.x-2.x
    Issue #3086299 by ericchew, bojanz: Admins can't add profiles to another...
bojanz’s picture

Status: Needs review » Fixed

Committed.

kristiaanvandeneynde’s picture

+++ b/modules/order/src/Controller/AddressBookController.php
@@ -117,14 +129,13 @@ class AddressBookController implements ContainerInjectionInterface {
-  public function overviewPage(RouteMatchInterface $route_match) {
-    $user = $route_match->getParameter('user');
+  public function overviewPage(UserInterface $user) {
     $profile_types = $this->addressBook->loadTypes();

This broke our code :(

I see what you're doing here but it was not BC and we had a custom class extending this one to override that specific method.

bojanz’s picture

Controllers are always @internal, no BC guarantees there.

Maybe we should mark them all final to prevent inheritance, forcing people to copy paste the entire class? It's more redundant but safer. Does mean you also keep all the bugs though. Personally find it better to crash people's overrides to let them know there is an important fix they need to copy over, but it's subjective.

kristiaanvandeneynde’s picture

I'm usually careful when extending internal code, but in this case the controller was not marked as @internal.

Maybe we should mark them all final to prevent inheritance, forcing people to copy paste the entire class?

Nah, that's just making people jump through hoops.

Controllers should be extendable because people might need to alter a title callback, an access check or page callback depending on their business logic. If you want to treat it as internal so you can make the changes you made here, I'd be fine with that too but would like to ask you to please mark the classes as @internal then :)

bojanz’s picture

Please open a followup for making that explicit (adding @internal to all controllers and forms). I believe there was a core issue on the same topic, might be useful to reference.Thanks!

greggles’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.