That sounds fine. The current website requires you to click "News" then a specific release, and then there are links for the releast notes (just a list of bugs fixes) and for ChangeLog (the git log since the last release.) A more direct link to either or both of those is an improvement. I had separately emailed Thomas about trying in the future to have a more user-friendly description of the change associated with each commit or bug closure, but that's for a future discussion, I think.

It would also be good to have quick links to the ChangeLog and Release Notes for the latest released versions. Before I add too many details, should I open a new issue on invent.kde.org or add it here?

Ah - if you mean using something like the dropdown on the vscode/visualstudio page, I do like it. Right now, it seems it's always two steps - go to the download page, then go to a separate page for the type of build, then pick your version. Saving one step for the latest version of each build type could be good.

@atem Sorry, what dropdown? I see buttons for "Install KMyMoney >" and "Download" which both go to the Download page, but no dropdown. Is there a draft home page? (Minor issue - all the items on the menu line keep the same menu line, except for "Donate" which is the main KDE Donate page, not KMM specific. I don't remember if we ever had a KMM Donate page.)

I wish it were that simeple :-) Although we have both current (5.0.x) and vintage (4.8.x) releases, we have several "versions" of each, especially depending on platform. For Linux, it's source, appimage, or get it from your distribution. For Windows, there are multiple paths, depending on build system (craft or cross compiling) and build system (autotools or msys, and I may have these wrong). There's also MacOS. That multiplicity is unfortunate, but due to not all combinations being able to deliver all functionality and components successfully. However, I think it would be really cool if we could do something like LibreOffice - a drop down for each version with an entry for each available download. That would complement and not replace the current different page for each build type with an entry for each version - especially the CI services with daily entries. Bottom line, however, is the simplest thing we need is just to have the most recent 5.0.x and 4.8.x releases listed, perhaps with release dates, on the main page.

@atem Development is done in master branch, so no version numbers there. However, we do make releases from both 5.0 and 4.8 branches.

I suppose that the minimal fix to prevent the crash is the best approach here, and the issue of notifying the user of why an action is disabled can be deferred for later discussion of a consistent approach.

I defer a decision to Thomas, and consistency across the app is good. The issue of how to notify the user what is blocking the desired action is a more widespread problem, and might be better deferred until it can be addressed in general, and not just in specific cases. (That has mostly arisen when trying to delete something, and it is not clear what is preventing that.)

What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type? That does raise the same issue we have elsewhere of how to inform the user of why the action is disabled - but I suggested in another bug using some sort of notification or status area, especially if there was only one remaining reason the action could not be completed.

• Fix typos found by yurchor

Thanks for your help - these are things I have obviously missed, and will help me in future updates.
This should be able to go into both master and 5.0 branch.

Please note that the KMyMoney team (mainly myself) generally handles the doc editing for this application. However, all these changes look OK to me. Also note that about half the chapters have not yet been updated to reflect Version 5 of the program - there are two of slowly working our way through that backlog. In general, we do not post doc updates through Phabricator, although I'll be happy to do so in order to get a review for these types of changes.

Just out of curiosity, is the No/100 translatable in cases where the local currency is not usually reported to two decimal places?

Much better. Would it be worth the effort to add mention to the home page of the latest released version? If not on the Home page, at least on the Download page? I know I sometimes do go to an application's page just to confirm I'm actually on the latest released version. Right now, other than the News page, I don't see it anywhere within two or three clicks of the Home page.

Yes, especially after the first page. Even the first page is larger than most screens, so putting 5 or even 10 items per page after the first seems OK. (It seems the announcements are clipped to at most a few lines, so they will never be very long.)

Thanks for all the work on this, but there are 12 pages, and the only thing that changes is Announcements, and even that took me a while to notice, since that section is not set off from the rest in any way. Also, the "Major Platform" icons are missing on all except the first page. The second is likely to be a bug somewhere. The first is more a style issue - so where is the best place to discuss how it "should" work, and what options there are.
Thanks.

I just filed a wishlist (Bug 413713) to make the number to text conversion language specific. I also wonder if Bug 255492 (KMyMomney's currency system should be ported to use KDE currency support) might be relevant to this issue.

Should kmymoney be added as either subscriber or reviewer?

I have not yet checked, but this would be a good time to be sure all the available Payee fields in the UI match those available in the check-printing plugin.

Thomas - can you tell me how to land this making Joshua the author, or can you make the commit? Thanks.

Looks good to me (certainly better than I would have gotten.) I have no idea why that text color would have changed. I'll give others a chance to suggest why it happened, but unless fixing it is trivially easy, I'll accept as is.
Thanks for the work.

It compiles and runs fine. However, in testing, it brought up some questions. This is the default transactions by payee report where I did include transfers, organized by payees.

There's no point in delaying this any further. It can be applied to 5.0 and master branches. (I'm not certain if all the recent doc updates to 5.0 have been applied to master, but I think Thomas has merged the 5.0 branch into master recently enough.)

I've just returned from vacation, and there is currently a string/doc freeze, so please give me some days to review, but I'll probably agree. However, I would like to be sure the info from those Q&A sections is maintained somewhere - probably on a web page with the install info specifically for KMM.

If tags are always assigned to splits, then does a tag being shown for a transaction simply mean it is attached to all splits of the transaction? If so, then it might be nice to show for the transaction all tags attached to any splits, with some indication whether the tag is attached to all splits or only some (bold or not, different colors, different font, ...?)

Is it intended that there can be tags on the transaction itself, and also on each split? (This is OK - I just want to be sure it is what is intended.)

I certainly can't comment on the German, but as long as this is only changing the German translation, I have no problem with it.

So, if the person made the original commit by Phabricator, he can request his addition to the script the same way.
Separately, there sill is the case (don't know if real or only potential) of someone making a contribution by sending to a mailing list, so he might not actually have any KDE account at all. I suppose that in that case, if the person had any interest in KDE, it would be reasonably to request he get a basic account (identities.kde.org, I assume).
Finally, would there be any reasonable way to use that basic KDE accountname as a username? (Am I correct a dev account is just a basic KDE account which is in teh developers group? If so, we know there wouldn't be any overlap in names.) I don't think we want a file with every kde account listed, due to the size - might there be an "authors" group for such purpose? I'm just afraid that it wouldn't be easy to maintain. It would need anyone listed as a git author, but who is not already in the developer group.) For now, I'd say let's get the current proposal committed, then we can discuss the additional issues.

Being Perl, It could be done either way. The current code just repeats creating the hash item, which is essentially a no-op. If you use a list, you would have to check if the email is already on the list before pushing it onto the list. (You could always sort and remove dups before printing, but the hash seems simpler to me.

Looks good to me. I had also been considering the possibility of an authors-accounts file (along with accounts and disabled-accounts) but I don't know that it would add anything to what's already proposed here, and maintaining that file would probably need to be done manually.
One problem remains, however. If such a listed author agrees to be added to the script - what should be used as username, since there isn't an account? Would simply adding the email address instead of username be reasonable?

Other than allowing the transaction to be saved without specifying a brokerage account, what would need to be tested? Maybe I'm not sufficiently paranoid, but what effects on reporting are you considering possible>?

I think this should add the team as reviewer.

There are several people who are against this, and only one in favor. Would you please consider others' opinions, and defer this further, or put it in a separate branch?

Successfully tested with xmlstorage. I hope to test sql storage within a few days, but I don't actively use sqlstorage. Using actual SQL code would be good, but probably not enough difference in efficiency to worry about in the short term.

I have not tested this yet, but I do have one investment account that does this, and I just enter it as a normal sell transaction, with fees of the exact amount of the sale, so the final value of the transaction is zero. I suppose this would make entering that type of transaction easier/fewer steps. (I also think it might be used for equities other than mutual funds.) What I can't tell just looking at this Diff is whether this is to be a new type of transaction, or else how the user indicates that this is the case.

My problem was that I had originally cloned from anongit, so of course any push would fail. I did a fresh clone, "arc patch," and then "arc land" worked just fine.

I tried "arc land" but get
Landing current branch 'fixlinks'.
TARGET Landing onto "master", the default target under git.
REMOTE Using remote "origin", the default remote under git.
FETCH Fetching origin/master...
These commits will be landed:

I'm at least somewhat against this change. Maybe it's just wishful thinking, but if we improve Alkimia, maybe there will be other users. That becomes essentially impossible if the code is moved internal to KMM.

I tried landing this using arc, but got "remote: Audit failure - Commit ab7fee01413bd1870dbcc562b6791721ec4d6064 - Non-full name: Joshua".

I'll be glad to land this. Locally it does look like the commit has the correct author, so unless someone says otherwise, I'll land it later this evening.

Thanks for the changes. I think this is good to go. We might come up with further changes, but I'd prefer to at least get the entire set updated to a new and consistent look. You can wait a day or to for any other comments, but I say Ship It.

My bad. I misread (or read too fast) your comment (or how much of my message you quoted.) I do need to recompile and try again. Should be OK.

@tbaumgart Can you also check the account edit dialog. I just checked, and it is titled new account dialog.

This review is for updated screenshots for the manual. I just added myself and the team as reviewers. The image quality looks good overall. Just a few specific comments:

• account_edit.png looks like it is from the new account wizard, not the edit account dialog. Was it just saved under the wrong name?
• the kmy file used (in title bar of all full window shots) is screenshots.kmy. While this is not explicitly wrong, it might make more sense to stick with something like MySampleFinances.kmy. (I could send you the one previusly used, or you could create a new one with similar finances but more current dates.)
• I don't know whether translations also use localized screenshots, but if not, it might be better to use a date format with month name (long or short) to avoid any possible confusion between mm/dd and dd/mm. (this may not matter, I just raise the question.)
• new.png - I'm not sure where it is used, but the new version looks like an icon for a missing icon, not for adding anything. please confirm.

Just a random thought - will any of this code be useful for adding a URL to a Payee? It could be useful there as well.

Fixed those two symlinks and updated the diff. Anything else blocking this?

• Merge branch 'master' into fixlinks
• fix cursors/src/symlinks/col-resize and .../row-resize

Overall - I would prefer to see this new section added to the existing csv import docbook file rather than as a new file, but to be sure it does not get forgotten, I think it is OK to add it like this, and I can rearrange when I do the full review if import/export for 5.0.

Sorry - I see this is only supposed to affect Windows, so questions about Linux are unnecessary.

Question regarding backporting: Is it correct that this does not affect 4.8 branch at all, or just not the Windows build? I don't know if any Linux distros will need another 4.8 release before being able to fully migrate to 5.x Also, does this need backporting to 5.0 branch or will next release be 5,1 and not 5.0.2?

Suggestion for improved wording for the first sentence in the tooltip in konlinebankingstatusdecl.ui "If the server is located in a different timezone than your local time, then the post date of imported transactions could be off by a day." (I tried to make as an inline comment, but it does not appear to have worked.)

I assume the summary should have said different timezone, not different timestamp? I do not have that situation, so I'm not sure I can test, other than to compile and to confirm it does not cause any problems.

I'm a little confused - was this committed or abandoned?

As this is not a really good forum for this type of discussion, I hope I can be sufficiently brief here, and perhaps we can continue the discussion on the dev mailing list.

Thomas: I consider losing track of someone (simply disappearing from the scene) different from someone dying. However, I agree that is a different issue from what to do with listing email addresses which are not know active, or even known to no longer be valid.

Separate question on header style: Is there a suggestion for dealing with a deceased author? (Allan Anderson) There is not much point in listing an email address in this case.

From the original summary:

Moreover, there are some names in the headers, which have not event touched the file, so it's false authorship. Those names has been removed. List of the names to remove has been taken from CVS (http://kmymoney2.cvs.sourceforge.net/) and git logs.

I am extremely concerned by this. If two people worked together on writing/editing some code, and only one of them checked the final copy into cvs/git, then the other name would not show up in the logs, but only in the header. Unless you have better proof they did not contribute, I would not remove names.

I've tried running the relicensecheck.pl script. I manually downloaded a copy of kde-common/accounts, but assume I should actually make a local clone - is it in git, or only svn?
The script seemed to stop at the first author email not in the accounts list for index.docbook. Since it said the email wasn't in the accounts list, I assume it got the email from the accounts list - but why did it stop at the first?
The script gave me a long list of needed permissions for whatsnew.docbook (just for an example) (including yurchor, who I'm a bit surprised not to see already on the list).
Is there a standard email I can send to the contributors (or post to the KMyMoney-devel list) which also tells them how to actually grant permission. It looks like I need to do this myself - do I just add myself to the script and then commit and push?

No, I did not. I will post about this to the kmymoney-devel list. Do I need explicit approval from everyone listed as an author in any of the docbook files, or just provide them an opportunity to object? I'm not even certain that all contributors are still reading the list.

Sorry - I was moving too quickly, and was thinking this was a change in KMM to handle libalkimia, not a change to libalkimia itself.

Thomas - was that a typo for the 5.0 branch?

This looks better to me. Hopefully Thomas can also check it after solving his crash issue.

I like this. I have been thinking about filing a wish list for it for some time.

OK - if the account type for New Account is set to Investment, the Opening balance is disabled. However, on the next screen, for the brokerage account, there is still not an Opening Balance. Less important, the Account number and IBAN are both disabled. Also, on the final page of the Wizard, there is "Opening balance: 0.00 $" shown for the investment account, and no opening balance for the brokerage account.

Normally, I think the idea to be able to test the program from within the build directory is good. However, this has (I think) always been a problem for KDE, which uses environment variables to find many files necessary to run a program. This is why it takes such effort to be able to have both a KDE4 and KF5 version of an application installed at the same time, to be able to use one and test the other. However, thinking about how I do that, I wonder if the same effect couldn't be had here by using a launch script which sets the necessary variables (pointing to the various areas under the build directory) and then launching the app.

I agree with the intent of this. However, if a user is testing both 4.8 and 5.x versions (assume with different kmy files) then once configuration files are moved by 5.x, will 4.8 create new default files, or will it find them in the new location?) I know it is an uncommon scenario, but we should avoid any surprises.

What was the final decision regarding default behavior if OFX is not mentioned at all explicitly in the cmake command? I am OK with either behavior, but want to be sure it is what is intended.