Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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!
Comment | File | Size | Author |
---|---|---|---|
#6 | 3086299-6-allow-admin-to-add-profiles.patch | 16.68 KB | bojanz |
| |||
#5 | interdiff-4-5.txt | 687 bytes | ericchew |
#5 | admin-address-book-3086299-5.patch | 1.05 KB | ericchew |
|
Comments
Comment #2
lkacenjaComment #3
lkacenjaComment #4
ericchew CreditAttribution: ericchew commentedI 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.
Comment #5
ericchew CreditAttribution: ericchew commentedFor some reason my previous patch did not have the proper 'use' statements that it needed.
Comment #6
bojanz CreditAttribution: bojanz at Centarro commentedHere's the full logic ported over from the Profile module, along with test coverage.
Contains the same security hardenings as Profile 1.1.
Comment #8
bojanz CreditAttribution: bojanz at Centarro commentedCommitted.
Comment #9
kristiaanvandeneyndeThis 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.
Comment #10
bojanz CreditAttribution: bojanz at Centarro commentedControllers 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.
Comment #11
kristiaanvandeneyndeI'm usually careful when extending internal code, but in this case the controller was not marked as @internal.
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 :)
Comment #12
bojanz CreditAttribution: bojanz at Centarro commentedPlease 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!
Comment #13
gregglesI opened #3119196: Add @internal to all controllers per 3086299.