[reports] import/export report to json

[christopherlam]

(not functional yet)

Instead of saving reports as an obscure scheme expression in saved-reports in the profile dir, export/import from simple json files to be managed by the user.

The user will then manage/rename their json files using their favourite file manager.

e.g. I may maintain my mybook.gnucash somewhere, and will store my mybook-balsheet.json in parallel. If I maintain business.gnucash I'll also maintain business-balsheet.json next to it.

[jralls]

We've discussed using json before, but as a replacement for scheme in saved-reports and report tabs in .gcm. I think that would be better than a separate import/export feature.

There was some discussion on gnucash-user a couple of weeks ago about splitting up saved-reports into per-book files. Given that in the general case saved report configs aren't portable between books (unless one book was copied from another) because the account GUIDs will be different I'm quite in favor of that change.

[bhardwajs]

Should this be tmpnam?

[christopherlam]

this is a placeholder during dev to stop annoying me with file dialog.

[christopherlam]

We've discussed using json before, but as a replacement for scheme in saved-reports and report tabs in .gcm. I think that would be better than a separate import/export feature.

json/toml/yaml any will work.

There was some discussion on gnucash-user a couple of weeks ago about splitting up saved-reports into per-book files. Given that in the general case saved report configs aren't portable between books (unless one book was copied from another) because the account GUIDs will be different I'm quite in favor of that change.

But where to save the json/other data? I now think it's not right to save into book kvp. saved-reports hidden in profile folder isn't intuitive either.

[jralls]

json/toml/yaml any will work.

Any will work for a file, but toml/yaml won't work as well as json in a string in the .gcm file.

But where to save the json/other data? I now think it's not right to save into book kvp. saved-reports hidden in profile folder isn't intuitive either.

Not in the book; I think that was generally agreed in the thread (begins). The suggestion that I liked best was next to the .gcm file in GNC_DATA_DIR/books. Maybe <book-file>.rpts for a filename?

[christopherlam]

But where to save the json/other data? I now think it's not right to save into book kvp. saved-reports hidden in profile folder isn't intuitive either.

Not in the book; I think that was generally agreed in the thread (begins). The suggestion that I liked best was next to the .gcm file in GNC_DATA_DIR/books. Maybe <book-file>.rpts for a filename?

Or, here's an idea -- any saved-reports either in saved-reports or gcm must have a root-guid property so that it only shows up when an appropriate datafile is loaded?

[jralls]

I guess that could extend the usefulness of saved-reports, but it's not necessary in a .gcm file because that's already tied to the book.

[christopherlam]

@derekatkins here's another idea. Transfer custom reports to another instance via regular Json (or scheme) files

[jralls]

That's how we do it now, in a scheme file called custom-reports-2.8. I guess you meant a separate file for each report?

[christopherlam]

That's how we do it now, in a scheme file called custom-reports-2.8. I guess you meant a separate file for each report?

Yes. The main report store still stays, but we gain ability to export to a file for transfer and import from file into report store.

[christopherlam]

That's how we do it now, in a scheme file called custom-reports-2.8. I guess you meant a separate file for each report?

Yes. The main report store still stays, but we gain ability to export to a file for transfer and import from file into report store.

The idea is to delegate report management to the file system! No need for CRUD UI to manage the user reports. Therefore the custom reports may be backed up together with the data files.

[derekatkins]

@christopherlam --

@derekatkins here's another idea. Transfer custom reports to another instance via regular Json (or scheme) files

Why are you tagging me here? I've not been involved in this thread!
In my opinion, if we're going to create a transfer format it needs to be something that is not white-space dependent. That means it cannot be yaml. It COULD be json, or scheme.. Or even cbor if we want a binary representation -- but I don't see the need for that.
Obviously, using scheme would be easiest in the sense that we already save reports in scheme format so it would allow us to re-use that code.

I agree that pretty much any "custom report" is going to be data-set specific. I can't think of how one would create a report that does not specify the accounts -- which ties it to the book.

[jralls]

@derekatkins What's behind your objection to white space dependent config formats like yaml/toml?

Not that we were considering that anyway, @christopherlam and I have been musing about JSON for over a year. It occurred to me a few weeks ago that boost::property-tree is a good fit for options and it includes reading and writing json. We're already using it for F::Q interface.