Skip to content

Commit e0a4bbb

Browse files
authored
v0.8.3 (#297)
* **Refactored `StagedTransactionModel` logic and template conditions:** - Simplified queryset filters and refactored helpers like `can_unbundle` and `ready_to_import` for better readability. - Replaced `children_count` check with `children_mapping_done` to streamline logic. - Updated template conditional to check for `receipt_uuid` instead of `has_receipt`. - Added commented-out logic for potential future conditions in `data_import_job_txs_table.html`. ### **Summary** Refactored transaction evaluation logic and templates for clarity and maintainability. Improved existing checks and prepared room for future enhancements in transaction handling. * v0.8.2.3 - **Enhanced import handling and UI for transactions:** - Introduced clearer logic for bundled vs. unbundled transactions in `StagedTransactionModel`. - Added new fields (`imported_count`, `children_import_pending_count`) for tracking transaction states. - Improved `is_imported` and `is_pending` query handling for parent and child transactions. - Enabled staged transaction deletion with `can_delete` and pre-deletion validation to reject invalid deletes. - Updated forms to streamline `tx_import` and `bundle_split` behavior for child transactions. - **Refined receipt migration and undo-import logic:** - Modified `migrate_receipt` to handle split amounts during migration. - Enhanced undo-import to account for child transactions and ensure proper cascade delete behavior. - **Improved templating and user experience:** - Added currency formatting for transaction amounts in receipt details. - Refined dropdown actions in imported transactions list to dynamically respect transaction types. - Reorganized transaction states and validations in templates for consistency. - **Refactored import state tracking for clarity:** - Expanded staged transaction attributes for better state evaluation (`is_children`, `is_parent`, `is_bundled`). - Introduced additional parent-child relationship checks for transaction clarity. ### **Summary** Refactored `StagedTransactionModel`, forms, and templates for improved import logic and UI experience. Introduced split amount handling and * - **Simplified journal entry update logic in import process:** - Adjusted the order of `unlock` and `unpost` calls to reflect appropriate transactional sequence before deletion. - **Refined transaction actions in template:** - Updated dropdown structure to consistently display transaction actions regardless of `is_parent` or `is_bundled` status. - Improved conditional logic to dynamically manage available actions like "View JE," "View Receipt," and "Undo Import." - Enhanced template organization for better readability and maintainability. ### **Summary** Streamlined journal entry handling logic and improved dropdown action display in transaction templates for better consistency and user experience. ### **Backwards Compatibility** These changes are fully backwards compatible. No significant behavioral or structural changes to existing workflows. * - **Refactored forms and staged transaction handling:** - Consolidated and streamlined widgets, labels, and help texts for `TransactionModelForm`, `BankAccountCreateForm`, and `StagedTransactionModelForm` for consistency and usability. - Simplified queryset filters, removed redundant queries, and enhanced `BaseStagedTransactionModelFormSet` to handle more dynamic setups (e.g., `children`, `units`, `vendors`). - Improved `tx_import`, `tx_split`, and `bundle_split` handling logic with clearer validation and dynamic element visibility for child transactions and account selections. - Enhanced validation and cleaned data logic for specific fields including `matched_transaction` and `activity`. - **Enhanced `BankAccountModel` account selection:** - Expanded filters for account roles in `BankAccountCreateForm` and `BankAccountUpdateForm` to include `LIABILITY_CL_CREDIT_LINE`. - Adjusted widget definitions to improve uniformity and provide better placeholders and help texts. - **Major improvements to transaction matching logics:** - Added mechanisms to dynamically adjust querysets for match candidates against transfers and debt payments. - Introduced informative error messages for ambiguous match cases, ensuring user clarity in selection. ### ** * - **Updated typing imports in `roles.py`:** - Re-ordered and ensured proper import layout for `List`, `Set`, and `Union` from `typing`. - **Added `ASSET_CA_CASH` to `GROUP_DEBT_PAYMENT`:** - Included `ASSET_CA_CASH` as a new element in the `GROUP_DEBT_PAYMENT` list to expand its scope. ### **Summary** Optimized import definitions for better readability and expanded `GROUP_DEBT_PAYMENT` to include `ASSET_CA_CASH`. No backwards compatibility concerns. * - **Refactored model definitions and improved transaction query logic:** - Reorganized imports across affected files for consistency (`bank_account.py`, `journal_entry.py`, `data_import.py`). - Enhanced `BankAccountModel` by streamlining field definitions and `configure` method logic to reduce redundancy. - Refactored queryset methods in `StagedTransactionModel` and `ImportJobModel` for improved clarity: - Introduced new annotations (`txs_imported_count`, `txs_pending`, `ready_to_match`) for better transaction state tracking. - Refined `is_imported` and `is_pending` methods to handle parent-child relationships and improve state evaluation. - Added additional URL methods to `ImportJobModel` for easier navigation (`get_list_url`, `get_delete_url`, etc.). - Expanded `StagedTransactionModel` with new fields such as `matched_transaction_model`, `matched_transaction`, and `notes` for better transfer handling and description support. - Introduced `ready_to_match` and `is_ready_to_match` for staged transactions to support enhanced matching workflows. ### **Summary** Refactored model structure and enhanced transaction tracking/query logic for better clarity, maintainability, and functionality. Improvements include streamlined method definitions, additional annotations, and new fields for transaction operations. ### **Backwards Compatibility** No breaking changes introduced; existing workflows remain unaffected. Newly added functionality is fully compatible with previous logic. * CSS Styles Update * - **Reorganized and refactored HTML templates for data import transactions:** - Removed outdated templates: `data_import_job_txs_imported.html`, `data_import_job_txs_table.html`, and `data_import_job_txs.html`. - Introduced new reusable templates: - `includes/staged_txs_form_card.html` for compact card-based transaction forms. - `import_job_txs.html` for centralized transaction display and actions handling. - Streamlined template structure by implementing improved layout with clearer separation of concerns. - Enhanced visual styles and dynamic behavior: - Added match indicators, account mapping helpers, and conditional logic tags for visual cues. - Incorporated responsive styles and conditional element visibility. - **Updated template logic for staged transaction and import workflows:** - Consolidated logic into reusable components to reduce redundancy. - Improved handling of `matches_found`, `is_matched`, and import validation for staged transactions with intuitive actions. ### **Summary** Replaced legacy transaction templates with modular and reusable components for improved clarity, maintainability, and user experience. Enhanced workflows for staged and imported transaction handling. ### **Backwards Compatibility** These changes are not backwards compatible. Old templates were removed and replaced with redesigned structures and updated logic. * - **Enhanced templates for improved styling and functionality:** - Updated receipt type rendering in `vendor_detail.html` to use `get_receipt_type_display` for enhanced context. - Adjusted side menu column width in `content_layout_1.html` from `is-2` to `is-3` for better layout proportions. - Renamed "Ledger List" navigation label to "Ledger Detail" in `je_detail.html` for improved navigation clarity. - Simplified `<form>` tags in `je_detail_txs.html` to remove redundant `action` attribute and added minor spacing adjustments. - **Introduced theme toggle functionality and improvements to base layout:** - Added `<meta>` tag for light and dark color scheme support. - Implemented script managing light and dark theme toggling and persistence via localStorage. - Modified base template logic to dynamically load appropriate theme and synchronize state. - Updated stylesheet URLs for better CDN reliability. - **UI improvements in navigation bar (`nav.html`):** - Added theme toggle button with accessibility features, including icon and label updates based on current theme state. - Removed hardcoded `is-light` class to allow dynamic theme application. - **Enhanced template action URLs with `next` parameter (`ledgers_table.html`):** - Added `?next={{ current_path }}` to action links for locking, posting, hiding, and deleting ledgers to enhance navigation context. ### **Summary** Improved template structure and functionality by introducing a theme toggle feature, updating receipt type rendering, navigating labels, and fixing layout proportions. Added better context handling for action URLs and streamlined form elements across templates. ### **Backwards Compatibility** These changes are fully backwards compatible with existing workflows. Dynamic theme support is an additive improvement, and no logic impacting workflows was altered. * - **Refactored inclusion tags for template handling and model integration:** - Replaced multiple outdated `data_import` templates with updated naming and structure (`import_job_list_table.html` and `import_job_txs_*` templates). - Enhanced `import_job_txs_pending` and `import_job_txs_imported` to improve pending transaction handling and model integration using `ImportJobModel`. - Updated method definitions to include explicit type hints (e.g., `ImportJobModelQuerySet`) for improved readability and functionality. - Removed unnecessary multi-line decorators in `@register.inclusion_tag` to simplify and standardize style across templates. - **Enhanced transaction and entity-based table methods:** - Passed additional context parameters (e.g., `current_path`) where relevant, streamlining associated logic for better navigation and state-awareness. - Consolidated and improved queryset sorting and validation for tables (`bank_account_table`, `closing_entry_txs_table`, etc.). - **Streamlined template references and decorators:** - Shortened all `@register.inclusion_tag` decorators to a single-line format to enhance code readability. - Updated and standardized template paths across `/templates` for consistency and clarity. ### **Summary** Refactored and standardized inclusion tags for clearer, maintainable, and scalable template handling. Enhanced model references, added type hints, and improved navigation/context parameters. Simplified template references and decorator styling. ### **Backwards Compatibility** These updates are fully backwards compatible—no existing workflows or usage patterns are affected. * - **Refactored URL definitions and view logic for consistency:** - Updated `entity.py` to use `entity-dashboard-year` reverse URL instead of `entity-dashboard-month`, simplifying navigation URLs. - Consolidated multi-line `reverse()` calls into single-line definitions for readability in several locations. - **Improved imports and class definitions across views:** - Reorganized `ledger.py` imports for logical groupings and systematic readability. - Adjusted multi-line class definitions in `ledger.py` to a single-line format where appropriate, improving readability. - Reformatted classes like `FiscalYearLedgerModelCashFlowStatementView` and `FiscalYearLedgerIncomeStatementView` for consistency. - Removed redundant and excessive spacing between widget definitions and parameters. - **Optimized extra context definitions:** - Simplified `extra_context` definitions in views like `LedgerModelListView` and `ImportJobModelListView` to make them more concise. - **Enhanced form-level changes for better structure and clarity:** - Refactored `get_form()` calls in multiple views to bundle kwargs more cleanly. - Replaced redundant calls to multi-line dictionary configurations with unified patterns for better functionality. - **Enhancements in `data_import.py` for new reset and handling capabilities:** - Introduced `ImportJobModelResetView` to manage resets on import jobs, e.g., clearing matches and invalid imports. - Added detailed reset transaction logic, including children collapse and match clearing in bulk scenarios. - Updated `ImportJobDetailView` to show progress details, import actions, and contextual information like pending/ready counts. - **Additional refinements in staged transaction handling:** - Introduced `StagedTransactionUpdateView` for managing parent-child relationships, splits, and matches within staged transactions. - Enhanced validation logic for transaction forms, especially for `tx_import` and child transaction splits. ### **Summary** Refactored and cleaned up URL definitions, imports, and view logic for consistency and maintainability. Introduced advanced reset capabilities for import job workflows, optimized transaction states, and improved code readability. These changes support better scalability, clarity, and UX across ledger management and importing modules. ### **Backwards Compatibility** These changes are fully backwards compatible. * - **Added new configuration option for transaction matching:** - Introduced `DJANGO_LEDGER_MATCH_DAYS_WINDOW` with a default value of 7 days for matching logic. - **Version bump:** - Updated version in `pyproject.toml` and `__init__.py` from `0.8.2.3` to `0.8.3`. ### **Summary** Added configurable `DJANGO_LEDGER_MATCH_DAYS_WINDOW` setting to enhance transaction matching flexibility. Incremented version to `0.8.3` to reflect these changes. ### **Backwards Compatibility** These changes are backwards compatible. Default value ensures current behavior is maintained unless explicitly overridden. * - **Added new fields to `StagedTransactionModel`:** - Introduced `matched_transaction_model` as a One-to-One field linked to `TransactionModel`. - Added `matched_transaction` BooleanField indicating if a transaction is matched. - Added `notes` TextField for storing additional transaction details. - **Indexes and field updates:** - Added an index on `matched_transaction_model` for optimized lookups. - Updated `transaction_model` field to enhance its definition. - **Altered `JournalEntryModel`:** - Adjusted the `description` field to allow optional entries with a maximum length of 120 characters. ### **Summary** Introduced enhanced fields in `StagedTransactionModel`, including transaction matching, notes, and indexing for better transaction workflows. Updated `JournalEntryModel` description field for flexibility and optional usage. ### **Backwards Compatibility** These changes are backwards compatible; legacy workflows will not be impacted. * - **Introduced `staged_tx_update.html` for staged transactions:** - Added a new HTML template aimed at managing staged transactions with a parent-child card layout. - Integrated inherited templates, responsive design, and block structures to support dynamic content like JS scripts for interactivity. - **Enhanced visual styles and class definitions:** - Defined unified card styles (`parent-card`, `child-card`) with custom borders, hover effects, and color variants for types (`is-income`, `is-expense`, `is-transfer`). - Added modular and reusable CSS blocks for transaction card headers and helptexts. - **Dynamic transaction form behavior:** - Incorporated advanced JavaScript for dynamic field handling: - Filtering, visibility toggling, and seamless account or match selection. - Ensured responsive interactivity with bundling, matching, and splitting toggles. - Improved contextual UI elements such as tags for status, `matches_found`, and `can_import`. - **Parent and child transaction structures:** - Unified headers for parent and child transactions within the staged transaction view. - Used clear labels and status indicators, including dynamic chip updates for customer/vendor associations. - **Responsive design improvements:** - Optimized layout for smaller screens, maintaining usability with collapsing cards and adaptive grids. ### **Summary** Introduced `staged_tx_update.html` for enhanced management of staged transactions. Features reusable styles, dynamic form interactions, and responsive layouts, improving the UX for complex transaction workflows. ### **Backwards Compatibility** Fully backwards compatible. This is an additive feature and does not override or disrupt existing workflows.
1 parent 16a95a5 commit e0a4bbb

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

41 files changed

+3027
-976
lines changed

django_ledger/__init__.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
default_app_config = 'django_ledger.apps.DjangoLedgerConfig'
77

88
"""Django Ledger"""
9-
__version__ = '0.8.2.3'
9+
__version__ = '0.8.3'
1010
__license__ = 'GPLv3 License'
1111

1212
__author__ = 'Miguel Sanda'
Lines changed: 47 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -1,29 +1,36 @@
1-
from django.forms import ModelForm, TextInput, Select, ValidationError
1+
from django.forms import ModelForm, Select, TextInput, ValidationError
22
from django.utils.translation import gettext_lazy as _
33

4-
from django_ledger.io.roles import ASSET_CA_CASH, LIABILITY_CL_ACC_PAYABLE, LIABILITY_LTL_MORTGAGE_PAYABLE
4+
from django_ledger.io.roles import (
5+
ASSET_CA_CASH,
6+
LIABILITY_CL_ACC_PAYABLE,
7+
LIABILITY_CL_CREDIT_LINE,
8+
LIABILITY_LTL_MORTGAGE_PAYABLE,
9+
)
510
from django_ledger.models import BankAccountModel
611
from django_ledger.models.accounts import AccountModel
712
from django_ledger.settings import DJANGO_LEDGER_FORM_INPUT_CLASSES
813

914

1015
class BankAccountCreateForm(ModelForm):
11-
1216
def __init__(self, *args, entity_slug, user_model, **kwargs):
1317
super().__init__(*args, **kwargs)
1418
self.ENTITY_SLUG = entity_slug
1519
self.USER_MODEL = user_model
1620

1721
# todo: only the accounts that do not hava an associated bank account should be available to pick from...
18-
account_qs = AccountModel.objects.for_entity(
19-
user_model=self.USER_MODEL,
20-
entity_model=self.ENTITY_SLUG
21-
).available().filter(
22-
role__in=[
23-
ASSET_CA_CASH,
24-
LIABILITY_CL_ACC_PAYABLE,
25-
LIABILITY_LTL_MORTGAGE_PAYABLE
26-
])
22+
account_qs = (
23+
AccountModel.objects.for_entity(user_model=self.USER_MODEL, entity_model=self.ENTITY_SLUG)
24+
.available()
25+
.filter(
26+
role__in=[
27+
ASSET_CA_CASH,
28+
LIABILITY_CL_ACC_PAYABLE,
29+
LIABILITY_LTL_MORTGAGE_PAYABLE,
30+
LIABILITY_CL_CREDIT_LINE,
31+
]
32+
)
33+
)
2734
self.fields['account_model'].queryset = account_qs
2835

2936
def clean(self):
@@ -36,9 +43,7 @@ def clean(self):
3643

3744
# catching unique database constraint...
3845
if BankAccountModel.objects.filter(
39-
account_model=account_model,
40-
routing_number__exact=routing_number,
41-
account_number__exact=account_number
46+
account_model=account_model, routing_number__exact=routing_number, account_number__exact=account_number
4247
).exists():
4348
raise ValidationError('Duplicate bank account model.')
4449

@@ -52,35 +57,26 @@ class Meta:
5257
'aba_number',
5358
'swift_number',
5459
'account_model',
55-
'active'
60+
'active',
5661
]
5762
widgets = {
58-
'name': TextInput(attrs={
59-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES,
60-
'placeholder': _('Enter account name...')
61-
}),
62-
'account_number': TextInput(attrs={
63-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES,
64-
'placeholder': _('Enter account number...')
65-
}),
66-
'routing_number': TextInput(attrs={
67-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES,
68-
'placeholder': _('Enter routing number...')
69-
}),
70-
'aba_number': TextInput(attrs={
71-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES,
72-
'placeholder': _('Enter ABA number...')
73-
}),
74-
'swift_number': TextInput(attrs={
75-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES,
76-
'placeholder': _('Enter SWIFT number...')
77-
}),
78-
'account_type': Select(attrs={
79-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES
80-
}),
81-
'account_model': Select(attrs={
82-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES
83-
})
63+
'name': TextInput(
64+
attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES, 'placeholder': _('Enter account name...')}
65+
),
66+
'account_number': TextInput(
67+
attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES, 'placeholder': _('Enter account number...')}
68+
),
69+
'routing_number': TextInput(
70+
attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES, 'placeholder': _('Enter routing number...')}
71+
),
72+
'aba_number': TextInput(
73+
attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES, 'placeholder': _('Enter ABA number...')}
74+
),
75+
'swift_number': TextInput(
76+
attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES, 'placeholder': _('Enter SWIFT number...')}
77+
),
78+
'account_type': Select(attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES}),
79+
'account_model': Select(attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES}),
8480
}
8581
labels = {
8682
'name': _('Account Name'),
@@ -96,23 +92,13 @@ class Meta:
9692
class BankAccountUpdateForm(BankAccountCreateForm):
9793
class Meta:
9894
model = BankAccountModel
99-
fields = [
100-
'name',
101-
'account_type',
102-
'account_model',
103-
'active'
104-
]
95+
fields = ['name', 'account_type', 'account_model', 'active']
10596
widgets = {
106-
'name': TextInput(attrs={
107-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES,
108-
'placeholder': _('Enter account name...')
109-
}),
110-
'account_type': Select(attrs={
111-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES
112-
}),
113-
'account_model': Select(attrs={
114-
'class': DJANGO_LEDGER_FORM_INPUT_CLASSES
115-
})
97+
'name': TextInput(
98+
attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES, 'placeholder': _('Enter account name...')}
99+
),
100+
'account_type': Select(attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES}),
101+
'account_model': Select(attrs={'class': DJANGO_LEDGER_FORM_INPUT_CLASSES}),
116102
}
117103

118104
def clean(self):
@@ -124,8 +110,8 @@ def clean(self):
124110
# catching unique database constraint...
125111
if 'cash_account' in self.changed_data:
126112
if BankAccountModel.objects.filter(
127-
cash_account=cash_account,
128-
routing_number__exact=self.instance.routing_number,
129-
account_number__exact=self.instance.account_number
113+
cash_account=cash_account,
114+
routing_number__exact=self.instance.routing_number,
115+
account_number__exact=self.instance.account_number,
130116
).exists():
131117
raise ValidationError('Duplicate bank account model.')

0 commit comments

Comments
 (0)