-
-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nested categories #1477
Comments
Categories are similar to tags, but are different. Transaction should belong to only one category and sum of categories should be always 100% (including empty/unknown/other category). Category should be the first dimension for reports/analyses/etc. with ability to show or hide details of different levels. This is important for budgeting and accounting. Tags can be nested too. Our internal implementation for categories can use tags of specific type which enforce specific rules for category type tags. But storage, manipulation dialogs, filtering etc. could be the same. |
+1 for "ability to use multiple levels of nested categories".
Thank you |
For calculate car1 and car2 expenses it's enought to add tag, notes or some info into "check number" field. |
A limitation of MS Money was only having a category and a subcategory, no nested categories. Please don't limit Money Manager Ex like MS Money was limited. Nested categories are required to enable users to switch from Quicken to Money Manager Ex. Without nested categories another program is required, such as https://skrooge.org/ Please reopen this enhancement issue and implement nested categories. Thank you |
@vomikan So we can simplify MMEX even more: for calculate not only car expenses but many different things it's enough to have flat category list (without subcategories) and add tag, notes or some info into check number. Or to have no category list at all and add tag, notes or some info into check number... Or not use MMEX at all. Categories are used in budgeting, reporting etc. and cannot be replaced with tags, notes or check numbers. Financial data uses hierarchical structure very often and this should be implemented in MMEX in the future. There is no reason to have category structure limited to arbitrary selected two levels in place of 0, 1, 3, 4, 5... levels. |
I don't understand 'Nested categories'. |
Example:
|
I am on the same point of view. Nested categories is complex to develop and excess for personal finances. |
Personal accounting software from Intuit, Reckon, Quicken all provide nested categories in their desktop personal finance software range. You can try old versions of Quicken by clicking here. Nested categories in Quicken personal finance software has been available at least since the 1990s. Nested categories in Quicken was not, and still is not, complex nor excessive for personal finance software on 16-bit, 32-bit and now 64-bit versions of Windows. |
"And the best is yet to come" with MoneyManagerEx. |
No, nested categories are not complex to develop. The current MMEX categories implementation is hard to change and develop new features. Two different tables for storing the same object causes problems with updating structure (requires updating all db records) - i.e. moving an existing category in the hierarchy. @vomikan Do you remember the famous Bill Gates statement (dated 1981):
;-) |
@slodki in 1981 I was 10 years old soviet boy. In my childhood there was no computers, programs and any available info regarding this. And then become 90x. There was no time for computers. "The current MMEX categories implementation is hard to change and develop new features." Agree. |
Also related: https://forum.moneymanagerex.org/viewtopic.php?t=10540 |
@n-stein Personally I don't need this feature (tags would be better) but I know others have asked for it. But I do like the idea of removing the SUBCATEGORY table. Out of interest, in terms of your DB structure, why do you need to maintain LEVEL, CHILDID, and NEXTID? |
Thank you @n-stein for nested categories. Does this allow for assigning multiple categories to a single transaction, i.e. Thank you |
Testing Version: 1.6.2-Alpha.1 64-bit commit: 1bfd4d2 (2022-11-22) Dragging a category onto its own parent should do nothing. mmex_ook6swPzfN.mp4In the video, it is acceptable for nothing to happen if CCC is dropped onto BBB. However, it would be even better if the the 'CCC' |
PR #5369 contains fixes for everything identified so far. Will have to think about the changing drag symbol part. |
Can a request for action to test the nested categories feature please be added to MMEX facebook, Twitter and any other social media page? Perhaps a message could be posted like:
What do you think? Thank you |
My preference is to keep the testing to those that currently take the development builds before more widely circulating. Most appropriate would be perhaps a post to the forums. But we need to be careful in wording to make sure that people know this is an 'Alpha' build and may contain bugs (along with some fixes of course 😁 ), and to fall back they need to revert to an older version of DB. What we don't want is to have to answer numerous questions on why people can't open the DB now with the 'stable' version, etc. |
I agree with you Mark. We know from experience that we'd get a flood of questions from people don't know to revert to a backup DB. If you(?) do put up a forum post, then I think this needs to be made explicit...
|
I think budgeting in particular will benefit from the eyes of those who routinely use that feature. Honestly I had never even clicked the "Budget" icon in the nav panel until I started work on this issue. I might actually use it now that I have a bit of experience, I quite like it. |
I haven't had time to test this major new change that looks really interesting, but I think that it deserves at least a 1.7.0 version, it's not a minor change. Have you considered the impact on GRM SQL queries? Maybe we could consider adding a step during upgrade process which shows a warning in case some queries return results? In this case if a query (pseudosql) "Select count(*) from GRM where SQL like '%subcategory%'" returns > 0, a warning similar to "Database subcategories structure has been changed, please double check all your GRM reports" should be pop up after upgrade. |
The standard GRM reports were already updated as part of this change, but good idea to check the user's custom reports. |
Too late, the release is out. The release notes advise the user of the change and give advise. |
You can retire it and reissue 1.7.0 with that change. |
We will get complaints regardless of whether we report a warning or declare in release notes. I view GRM users as power users and as such should be able to accomodate the change given the release notes and examples in the GRM templates. |
Categories are stored as adjacency list since 1.6.2 (moneymanagerex/moneymanagerex#1477)
Categories are stored as adjacency list since 1.6.2 (moneymanagerex/moneymanagerex#1477)
Categories are stored as adjacency list since 1.6.2 (moneymanagerex/moneymanagerex#1477)
What I can't work out it was fine in the releases before approx December. Why or what caused it to suddenly fail and take huge cycle time to not work? I've kept silent about my experience as I felt I was being too critical. |
@SJK55 You have resurrected a Closed enhancement issue, the implementation of which was released in December. It would be helpful if you could raise a new issue, explaining clearly the problem that you are experiencing in 1.6.3. |
Ability to use multiple levels of nested categories will be nice. We manage categories as a tree already but limited to 2 levels.
Then reports based on categories should have parameter to aggregate values on first/second/third... categories level.
The text was updated successfully, but these errors were encountered: