Author: Simon Arlott <bugzilla.gnome.simon@arlott.org>
BP
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23088 57a11ea4-9604-0410-9ed3-97b8803252fd
Disable quartz accelerators: They grab menu accelerators without regard
to focus GtkWindows, breaking bindings.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23085 57a11ea4-9604-0410-9ed3-97b8803252fd
Each saved report now has 3 actions
- run
- rename
- delete
Rename is a new feature that allows to rename a report without having to
delete/readd.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23081 57a11ea4-9604-0410-9ed3-97b8803252fd
- whether a report template is a custom one
- whether a report is based on a custom report
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23079 57a11ea4-9604-0410-9ed3-97b8803252fd
For now, the date that couldn't get parsed is replaced by today. Improvements
to this behaviour are welcome, though :-)
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23073 57a11ea4-9604-0410-9ed3-97b8803252fd
GnuCash was crashing if you searched for all unposted invoices, selected two or
more of them, and posted them. This was because the list of invoices to be posted
changed while it was being processed. As part of fixing this the prompt for post date,
due date, etc. will only be given once, not once per invoice.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23071 57a11ea4-9604-0410-9ed3-97b8803252fd
The biggest problem was that it was adding an invoice's entries to both the old
and the new invoice when duplicating the invoice.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23070 57a11ea4-9604-0410-9ed3-97b8803252fd
- Rename two functions that work with guids instead of names (legacy)
- Don't sort the a list of guids. This doesn't add value and slows down the report loading code
- Add/improve some comments
- Reorder record accessors for the report-template record
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23067 57a11ea4-9604-0410-9ed3-97b8803252fd
This changes the ordering but only for txn with the same date
and same number. The buttons are active only in cases where this is
possible, otherwise the buttons are inactive anyway.
- for reconciled splits, user will be asked
- book-closing txn are ignored as well as frozen splits
- After changing the sort order, update the UI buttons immediately as well
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23061 57a11ea4-9604-0410-9ed3-97b8803252fd
When loading a scheme data file such as ~/.gnucash/stylesheets that contains
invalid characters (e.g., all-zero bytes), the loading throws a scheme
exception and we are redirected into the error catch handler. When trying
to convert the erroneous scheme expression into a string for the
message output, scheme runs into an exception right again. Hence, the
conversion to string must be guarded by a stack_catch as well.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23059 57a11ea4-9604-0410-9ed3-97b8803252fd
The code for ensuring a commodity that is a currency was duplicated among
the file. This is now refactored into the reg_currency variable. Also, in
a non-currency register the currency is now taken from parent accounts or
the default currency, which matches the old register's policy but is different
from what register2 previously did.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23057 57a11ea4-9604-0410-9ed3-97b8803252fd
Previously, this could result in transactions that have a non-currency as
txn commodity, which is what the multi-currency register tried to avoid hard.
Now by using account_or_default_currency, the currency choosing policy from
the register is available in the other places where new transactions are
created, hence we better use that here.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23056 57a11ea4-9604-0410-9ed3-97b8803252fd
The missing part was the line in assistant-hierarchy.c, but I've added
it to the two other calls to file_access_for_save_as() to be on the safe
side on those two other book creation places as well.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23053 57a11ea4-9604-0410-9ed3-97b8803252fd
This only changes the single line that doesn't break the existing utest-Split.c
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23051 57a11ea4-9604-0410-9ed3-97b8803252fd
Sigh. It turns out the utest-Split.c relies on the "warning" log level
in order to check for specific code paths. This sucks. The log level
"warning" should please be reserved for things that are actual warnings,
not for code path checks that are used in the unittests.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23048 57a11ea4-9604-0410-9ed3-97b8803252fd
The book-closing txn currently assume that their
posted-date is the end date plus 12 hours, so that the closing txn can
be distinguished from normal txns of the last day. This is the only
case within GnuCash where the PostedDate is a different time-of-day
that what the GDate normally says as a normalized date.
We better change this sometime in the future so that the PostedDate
doesn't silently contain this hidden extra meaning...
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23047 57a11ea4-9604-0410-9ed3-97b8803252fd
In fact, all calls to this setter refer to the plain date and not to
any time-of-day. Consequently, only the normalized setter must be used
everywhere. (Subsequently, the previous setter could be removed, as
it turned out to be not used anywhere, but that's another story.)
As a side effect, this makes the register2 set the PostedDate in the
same way as the old register again. The register2 used to introduce a
time-of-day part in the PostedDate, but this should not be done. Only
the EnteredDate has a time-of-day part.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23045 57a11ea4-9604-0410-9ed3-97b8803252fd
We've struggled with the time-of-day part of the PostedDate for long
enough. The PostedDate field is just not meaningful with anything else
but a plain date, and no time-of-day at all. Hence, the correct setter
function for this particular field must ignore the time-of-day. Consequently,
a GDate should be used here anyway, but in many places the time64 is more
convenient. The new function will now redirect that time64 to the GDate
setter function to make sure we will now map everything to one single date.
git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@23044 57a11ea4-9604-0410-9ed3-97b8803252fd
