Report system legacy
janssens-geert at telenet.be
Sat Jun 29 10:06:50 EDT 2013
Thanks all for your feedback. I'll keep from this that duplicate names
among custom reports are not desired. To which I agree.
I originally asked this question in the scope of one of the bugs in the
GnuCash bounty program:
Allow saving of Custom Reports without changing name, overwriting
Before I go into more detail, let me start with this: the current code
is not able to prevent duplicate custom report names either. Don't
believe me ? Try this:
- open a new report
- edit it's name in the report options and hit ok
- edit it's name again, resetting it to the original name and hit ok
- save the report
You can do the same thing by creating a new report and changing its name
to the name of any existing custom report. There is no validation on the
So the unique name requirement is a new requirement, which I see
independently of the bounty requirement of being able to resave changes
to an existing report template. I hope we can agree on this. I do intend
to look into this as well, but not right now.
I have been massaging the reports code for about a week now to come up
with a satisfactory solution. You can not imagine what a can of worms
that code is...
To make the rest of the discussion a little bit manageable, allow me to
first make a distinction between reports and report templates: each menu
option you see in the reports menu is a report template. The moment you
open one such menu you instantiate one instance of such a template. This
is a report. "Custom reports" are also report templates, which have a
parent template and a set of custom options. When you open a "custom
report" you create an instance of one template, hence you have a report
again. When you "save" a report, what you really do is creating a
template based on the parent template and the current set of options for
this report. In this discussion, we're constantly on this edge between
report templates and reports.
While looking at the custom reports code I found several issues with it,
not only the inconvenience of having to change the name all the time
before resaving. I came to the conclusion that simply adding a dialog
box asking if a report should be overwritten is only shifting the
problem to the next annoyance.
Since I would be working on this code anyway, I wanted to eliminate
several of these annoyances at once.
So I worked from the file system metaphor that was already referred to
in this discussion. Most programs have two Save options: simply Save and
then Save As. You use the first to save your changes to an existing
file, you use the second when you want to save your changes in another
file. This is much more in line with how humans think than the current
custom reports logic where you first have to change a name and only then
can save it.
So that's my general idea so far: make the custom reports logic more
like a file manager. So far I have created two independent save buttons
for reports as well: a save and a save as button which behave as you
would expect: save will update the custom report template the current
report is based on. Save as will prompt the user for a name and create a
new template with this name. If the report to be saved is not based on
any custom report template, the save button will behave as a save as
button, just like a file manager save button would.
The name prompt dialog is an improved version of the custom reports
dialog, which also now allows to rename any existing report. Using this
dialog makes it easy to see which custom report template names do exist
already, so it becomes easier to generate a unique name. The old system
relied on you to know which name is unique or not.
Note that this solution implies that you know which template a report is
instantiated from. The current code doesn't keep track of this. The
obvious thing to do is to add a parameter to the report record for this.
And the most obvious parameter to store is the custom report template's
So far a unique name is not enforced yet in my new code. But since you
see the names of all existing reports when you save a new one, it's easy
to maintain this manually.
Now regarding this unique name enforcement, I'd like to think out lout a
With the new implementation, we risk duplicate names both when a user
hits "Save As..." or when she uses the custom reports dialog to rename a
report. So I'll just work with the generic situation of renaming a report.
Suppose I have two report templates called "TemplateA" and "TemplateB"
and there are reports currently instantiated for both templates. Next I
try to rename TemplateB to TemplateA. What should I do ?
a. delete TemplateA and rename TemplateB to TemplateA, probably after
user confirmation ? That means that old TemplateA's guid is lost, and
any open report based on it is no longer based on any custom report
You could consider updating the open reports while renaming a template,
but you can't. Templates are shared across all books, so at best you can
update the reports in the currently open book. The issue could still pop
up in another book.
An even stronger reason no to attempt updating open reports: what if
TemplateA and TemplateB are not based on the same parent report ? So you
now have one template "TemplateA", and some reports that claim to be
instantiated from it, although they come from totally different
Each time you hit save on either report, TemplateA will effectively swap
parent template in addition to options. So depending on which report you
last saved, your custom template will instantiate a totally different
report. Perhaps this is an uncommon situation, but it may cause lots of
confusion for a user that accidentally gets into it. So I don't think
it's a good idea.
b. delete TemplateA, rename TemplateB to TemplateA and set TemplateB's
guid to old TemplateA's guid. In this variant, suddenly all open reports
that were based on TemplateB won't be based on any template anymore.
This is probably a very bad idea.
c. If the new name already exists, simply refuse to continue. Ask the
user to change the name again. This may be the simplest to implement,
but in reality this will result in situations exactly like case a,
except it's more cumbersome to the user: if you refuse to overwrite a
template, the user can first delete that template and then rename the
new template to the old one. All issues you get in case a will repeat here.
In summary, I don't think we can avoid some loss of report to template
links. So which option looks the most user friendly here ? I would think
On 29-06-13 12:31, Carsten Rinke wrote:
> Here comes a user's voice:
> I also vote in favour of Derek's, Christian's and Herbert's preferences.
> On 06/29/2013 10:29 AM, Herbert Thoma wrote:
>> Am 28.06.2013 22:22, schrieb Christian Stimming:
>>> I think we shouldn't add any suffix to the report name
>>> automatically. I also
>>> think we shouldn't have multiple saved reports with the same name.
>>> To resolve
>>> this, I think Derek's proposal works best: Saving the report
>>> requires a unique
>>> name among the saved custom reports (but which might be identical to
>>> the non-
>>> custom report). If the report with this name already exists as
>>> custom report,
>>> the user gets a question "Another report already exists with the
>>> name XX.
>>> Overwrite? [Cancel] [Ok]" and no additional options. If the user
>>> doesn't want
>>> to overwrite, he/she always can guess to "Cancel" here and then
>>> change the
>>> name to have it unique again.
>> I agree. We could add a third button [Choose different name] to open a
>> kind of save as dialog, if we want to get fancy.
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel