Problems with transaction cut/paste

Gary Bickford garyb@fxt.com
Sun, 24 Sep 2000 23:42:38 -0700


Perhaps the right answer is to have a different function, "move".  In fact, the
first thing I tried was to 'drag' the transaction from one account to another.
 Cut/paste was my last resort.  I would propose that it's better from a user
interface point of view to not change the semantics and results of cut and paste
from what people expect (whatever that is...)  Thus moving a transaction or
group of them might properly be done another way.

This may require some looking at the other money apps to see what if anything
they do.  This was, after all, rather a special case where things got put in the
wrong account in the first place.  So it's not obvious what the right thing is.
GB

Dave Peticolas wrote:

> "Phillip Shelton" writes:
> > > > I have a couple of problems to report with 1.4.2.  These
> > > > may have been
> > > > fixed already in 1.5.1?
> > > >
> > > >   1. The pasted transaction had lost both the date and the
> > > >      ID number. Since I cut instead of copy, I didn't know what the
> > > >      invoice no. and date were any more.  So I had to look them up in >
> > >      the old paperwork and re-enter that data.
> > >
> > > I had originally thought that copying a transaction shouldn't
> > > use the old date or id number, since it's a 'new' transaction.
> > > But that's probably too confusing. I'll change it to keep the
> > > date and number, too.
> >
> > If you are copying then perhaps you do not want the old date or ID but if
> > you cut then you probably do. Is it possible to flag the difference?
>
> Yes, we may need to do that. It's a bit confusing since cut
> is generally equivalent to "paste, delete", but maybe it's
> unavoidable.
>
> dave
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

--
"We feel that this change will be sufficient to discourage "hackers",
although it is obviously insufficient to protect a node against a
determined and malicious attack."
- RFC521 (ftp://ftp.isi.edu/in-notes/rfc521.txt), 1973

Gary E Bickford, mailto:garyb-at-fxt.com.
Web and content/asset management systems, PHP, XML, Apache, SQL
FXT Corp, http://www.fxt.com, tel. 541-383-2749