Closes #21209: Support real model names in configuration parameters

[adionit7]

Summary

This PR adds support for real model names (e.g., dcim.Site) in DEFAULT_DASHBOARD, CUSTOM_VALIDATORS, and PROTECTION_RULES configuration parameters, matching the syntax used by FIELD_CHOICES.

Changes:

• Add normalize_model_identifier() utility function to convert real model names to lowercase format used by ObjectType
• Update get_models_from_content_types() in dashboard widgets to normalize model identifiers
• Update CUSTOM_VALIDATORS and PROTECTION_RULES lookups to check both real model names and lowercase names
• Update documentation with real model name examples and backward compatibility notes

Backward Compatibility

Both formats are supported:

• Real model names: dcim.Site, ipam.IPAddress
• Lowercase names: dcim.site, ipam.ipaddress (existing behavior preserved)

Fixes #21209

[pheus]

Thanks a lot for working on this! 🙌

While reviewing the feature request, I noticed the scope is a bit broader than what’s currently covered in this PR. The request is to allow ContentType/ObjectType strings (e.g. dcim.Device) to be case-insensitive across all relevant configuration parameters. The FR author specifically called out three areas:

• PROTECTION_RULES
• DEFAULT_DASHBOARD
• FIELD_CHOICES

From what I can see, this PR currently addresses only the PROTECTION_RULES and the DEFAULT_DASHBOARD case.

Would you mind taking another pass to review the other config paths as well, and extend the PR to include any additional configuration options where these model strings are accepted?

[adionit7]

Thanks a lot for working on this! 🙌

While reviewing the feature request, I noticed the scope is a bit broader than what’s currently covered in this PR. The request is to allow ContentType/ObjectType strings (e.g. dcim.Device) to be case-insensitive across all relevant configuration parameters. The FR author specifically called out three areas:

• PROTECTION_RULES
• DEFAULT_DASHBOARD
• FIELD_CHOICES

From what I can see, this PR currently addresses only the PROTECTION_RULES and the DEFAULT_DASHBOARD case.

Would you mind taking another pass to review the other config paths as well, and extend the PR to include any additional configuration options where these model strings are accepted?

Thanks for the review @pheus! Really appreciate it! 🙌
You're right.. we initially missed FIELD_CHOICES. I've added case-insensitive support for it in utilities/choices.py using the same pattern.

The PR now covers all three areas mentioned in the FR:

• DEFAULT_DASHBOARD — accepts both dcim.site and dcim.Site
• PROTECTION_RULES — case-insensitive lookup via helper function
• FIELD_CHOICES — case-insensitive lookup for both dcim.Site.status and dcim.site.status (and the + extension variant)

As a bonus, I also updated CUSTOM_VALIDATORS to use the same case-insensitive pattern for consistency.

All changes follow the same approach: try an exact match first (O(1)), then fall back to a case-insensitive search if needed. This maintains backward compatibility while allowing users to use either format.

The PR is ready for another review.

[jnovinger]

Left some notes, but this is a great start. Also, you need to make sure you update the docs (as noted in the PR description).

[pheus]

Thanks for pushing this forward! I appreciate that you’re applying it consistently across FIELD_CHOICES and CUSTOM_VALIDATORS.

A few follow-ups I’d like to see addressed

Tests: please add an integration-style test for FIELD_CHOICES casing + + suffix

The unit tests for get_config_value_ci() are helpful, but I’d like to see at least one test that proves:

• replacement works when config key casing differs (e.g. dcim.Site.status), and
• extension works with the + suffix under casing differences (e.g. dcim.Site.status+).

That will ensure the original reported issue stays fixed and avoids future regressions.

[adionit7]

Thanks for the feedback @pheus! Appreciate that.

I've added integration tests in test_choices.py that verify:

• Replacement works when config key casing differs (lowercase config key utilities.teststatus found when code looks up PascalCase utilities.TestStatus)
• Extension works with + suffix under casing differences.

Other comments are also resolved as per the feedback. Ready for your review! :)

[pheus]

Thanks for the updates! I re-reviewed the latest changes.

Nice cleanup 👍

Overall, LGTM — thanks for iterating on this and for adding solid tests.

Taking over review from jnovinger

[adionit7]

Thanks for the updates! I re-reviewed the latest changes.

Nice cleanup 👍

Overall, LGTM — thanks for iterating on this and for adding solid tests.

Thanks a lot for the review @pheus!
Happy to help :)