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:

python
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_name set continue using model.__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:

python
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:

python
tab_dict = {
    ...
    'url_name': tab.get('url_name', ''),
}

Usage

python
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_name continue using model.lower() — identical behavior.
  • No template changes required. The url field in the output config is used directly by templates.

Files changed: 1 file (6 lines changed).


3. Version Bump

  • setup.py: Version bumped from 0.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.