fix: corrected access path for password_profile_registration_node_group feature flag

[luflow]

Description

Fixed incorrect configuration path for the password_profile_registration_node_group feature flag.

Change:

• Moved from: selfservice.methods.password.config.password_profile_registration_node_group
• Moved to: feature_flags.password_profile_registration_node_group

This aligns the feature flag with other feature flags under the feature_flags namespace and matches the config schema thats defined in https://github.com/ory/kratos/blob/master/embedx/config.schema.json#L3063

Related issue(s)

None reported until now?

Checklist

• I have read the contributing guidelines.
• I am following the contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security vulnerability.

[luflow]

@aeneasr Thats a breaking change by the way that was not mentioned in the release notes of 25.4.0

[aeneasr]

Hello @luflow - thank you for the fix! Unfortunately, this slipped through our review process. Since this change is now already on our production system and a couple of customer systems, the incentive to fix this is quite small. Instead, we want to get rid of the flag. Since this has been rolled out to all commercial customers already without incidents (the feature is available for quite a while on other channels) we will most likely just remove the flag.

Therefore I would encourage updating your UI implementation. Also consider using ory/elements which has an architecture that avoids issues such as group name changes.

Overall we want a better API for Ory Kratos here and will at some point work on a v2 of the self-service APIs to reduce reliance on state such as group names and have deterministic confidence in the UI flow state.

[luflow]

@aeneasr I understand that your enterprise customers are a priority to you, but because there was no release for over 12 months I assume a lot of open source users will face this issue because they didn’t see it coming - especially when they implemented native flows in their iOS/Android apps that are not as easily updated as a web frontend…

So at least mentioning it in the release notes as breaking change would help already. So apps first can be updated and have enough rollout percentage out there before the update to the latest kratos version is done.

[aeneasr]

So at least mentioning it in the release notes as breaking change would help already. So apps first can be updated and have enough rollout percentage out there before the update to the latest kratos version is done.

Absolutely agree, and we immediately updated the release notes yesterday! As you can tell from the code, it was an oversight and not intentional. Generally, we try to keep BC.