Release Notes — v0.2.17 (July 11, 2026)
1. URL Registry Respects Custom url_name
Status: Uncommitted
get_registered_urls() in enezaframework/utils.py now respects the url_name class attribute on views. When a view specifies url_name = "orders", the generated URL patterns use orders as the prefix instead of the auto-derived model name.
Problem
When url_name was introduced in v0.2.16 for UrlMixin and individual view classes, the auto-registration URL generator (get_registered_urls()) was not updated. This caused URL patterns to be registered using the model name (e.g., purchaseorder/) while the views expected the custom name (e.g., orders/), resulting in NoReverseMatch errors on reverse() calls.
Fix
enezaframework/utils.py:55 — Added url_prefix computation before URL pattern generation:
url_prefix = getattr(view_class, 'url_name', None) or view_class.model.__name__.lower()
model_name = view_class.model.__name__.lower()
All 10 URL pattern types updated to use url_prefix instead of model_name:
| View Type | URL Name | URL Path |
|---|---|---|
list |
{url_prefix}_list |
{url_prefix}/ |
detail |
{url_prefix}_detail |
{url_prefix}/<str:pk>/ |
create |
{url_prefix}_create |
{url_prefix}_create/ |
delete |
{url_prefix}_delete |
{url_prefix}_delete/<str:pk>/ |
parameter |
{url_prefix}_parameter |
{url_prefix}/ |
one_to_one_detail |
{url_prefix}_detail |
{url_prefix}/<str:pk>/ |
Dashboard |
{url_prefix}_dashboard |
{url_prefix}/ |
autocomplete |
{url_prefix}_autocomplete |
{url_prefix}_autocomplete/ |
workflow |
{url_prefix}_workflow |
{url_prefix}_workflow/<str:pk>/ |
document_report |
{url_prefix}_report |
{url_prefix}_report/<str:pk>/ |
Action views (view_type == 'action') are unchanged — they continue to use action_name.
The model_name variable is preserved for the model_name_title fallback display name.
Backward Compatibility
- Views without
url_nameset continue usingmodel.__name__.lower()as the prefix — identical behavior. - No migration or template changes required.
Files changed: 1 file (26 lines changed).
2. Inline Tab URLs Respect Custom url_name
Status: Uncommitted
get_inline_fieldtab_config() in enezaframework/views/mixins.py now supports an optional url_name key on inline tab definition dicts. When specified, inline URLs are generated using the custom prefix instead of the model name.
Problem
Inline related object tabs (configured via get_inline_related_objects() or the inline config dict) generated URLs using tab.get('model', '').lower() as the prefix. If the target inline view had a custom url_name (e.g., url_name = "party_addresses"), the generated URL address_detail would not match the registered URL party_addresses_detail, causing NoReverseMatch errors.
Fix
enezaframework/views/mixins.py:899 — URL prefix now checks for url_name on the inline tab config:
url_prefix = tab.get('url_name') or tab.get('model', '').lower()
if relation_type == 'one_to_one':
url = f"{url_prefix}_detail"
else:
url = f"{url_prefix}_list"
The url_name is also passed through to the output tab_dict for downstream use:
tab_dict = {
...
'url_name': tab.get('url_name', ''),
}
Usage
inline_related_object = [
{
'name': 'address',
'caption': 'Address',
'model': 'Address',
'url_name': 'party_addresses', # matches the inline view's url_name
'relation_name': 'addresses',
'relation_type': 'one_to_one',
...
},
]
Backward Compatibility
- Inline tab configs without
url_namecontinue usingmodel.lower()— identical behavior. - No template changes required. The
urlfield in the output config is used directly by templates.
Files changed: 1 file (6 lines changed).
3. Version Bump
setup.py: Version bumped from0.2.16→0.2.17.
Summary
| Area | Description | Files |
|---|---|---|
| URL Registry | get_registered_urls() respects url_name on view classes for all 10 URL pattern types |
1 |
| Inline URL Names | get_inline_fieldtab_config() supports url_name key on inline tab dicts for correct URL generation |
1 |
| Versioning | Version bumped to 0.2.17 | 1 |
Total: 3 files changed (utils.py, mixins.py, setup.py).
Note: All changes are uncommitted and untested. The user is solely responsible for testing and validating all outputs before committing or deploying.