In my previous patch, all of the objson code was removed from OpenSRF,
including the autotools bits that compiled objson. This patch removes the
remaining autotools bits, in particular giving the user the choice of whether
to build legacy json.
-b
--
Bill Erickson
| VP, Software
Looks good to me
Kevin
On Mon, 2008-07-28 at 09:33 -0400, Bill Erickson wrote:
In my previous patch, all of the objson code was removed from OpenSRF,
including the autotools bits that compiled objson. This patch removes the
remaining autotools bits, in particular giving the user the choice
On Sunday 27 July 2008 11:19 Mike Rylander wrote:
On Sun, Jul 27, 2008 at 9:51 AM, Bill Erickson [EMAIL PROTECTED]
wrote:
On Thursday 24 July 2008 8:54 David J. Fiander wrote:
[snip]
The primary field on the receiving screen is an ISBN input field. The
staff scan the ISBN barcode on
On Monday 28 July 2008 9:35 Kevin Beswick wrote:
Looks good to me
Committed. Thanks for the eyes, Kevin.
-b
Kevin
On Mon, 2008-07-28 at 09:33 -0400, Bill Erickson wrote:
In my previous patch, all of the objson code was removed from OpenSRF,
including the autotools bits that compiled
On Thursday, July 24, 2008 7:55 PM, David J. Fiander wrote:
The primary field on the receiving screen is an ISBN input field. The staff
scan the ISBN barcode on each item, which pulls up the corresponding JUB.
The system would need some way of dealing with duplicate (reused) ISBNs or
items with
Bryan,
You're absolutely right, and I'd already thought of dealing with items
without ISBNs, at least. But for the initial development, I think we need to
focus on the simplest and most common case of items with unique ISBNs.
On Mon, Jul 28, 2008 at 10:13 AM, Bryan Baldus
[EMAIL PROTECTED]
Hello Dan S.,
I think this sounds like a great idea. I know the instructions have not kept
up with Evergreen installation best practices, but I have been hesitant to
rewrite them, since they do (mostly) work. Ejabberd in particular has always
been a problem area, and I have only just
David,
This sounds like a lot of thought has been put into the process. One question
about the invoice #. Many times we only receive a packing list with the
books/media that are being received. Would we then have to wait for an
invoice? If so, that could really slow things down.
As
Hi, John.
Fines are generated by passing the parameter 1 (for true) to the
OpenSRF function
open-ils.storage.action.circulation.overdue.generate_fines(),
generally referred to as the 'fine generator'.
Fortunately, there's a Perl script that comes with the Evergreen
source distribution
That's awesome, Dan!
If you could add the Mnesia spool-clearing to a troubleshooting
section of the wiki, I'm sure that would help lots of people out
(versus the current draconian dpkg --purge ejabberd approach).
I'll let you know when I've updated the docs so you can wrap a Kevlar
vest around
Carri,
The packing slip doesn't have an invoice # on it? If that's the case,
perhaps MIke's idea about using the PO # is better. I'm a bit concerned
about shipments containing odd mixtures of items from various POs; it seems
more likely that a shipment will match an invoice than that it will
Noticed a small error in src/gateway/Makefile.am
Here is the fix
Kevin
On Sun, 2008-07-27 at 23:58 -0400, Dan Scott wrote:
2008/7/25 Bill Erickson [EMAIL PROTECTED]:
On Friday 25 July 2008 11:43 Kevin Beswick wrote:
Updated patch to reflect the changes since the revision that just
David Fiander [EMAIL PROTECTED] 7/28/2008 9:40 AM
Carri,
The packing slip doesn't have an invoice # on it?
--Sometimes, but not always. I do like the idea of tying the receipt to an
invoice. Especially since many of our invoices are electronically downloaded.
Will there be some way of
Applied - thanks!
Dan
2008/7/28 Kevin Beswick [EMAIL PROTECTED]:
Noticed a small error in src/gateway/Makefile.am
Here is the fix
Kevin
On Sun, 2008-07-27 at 23:58 -0400, Dan Scott wrote:
2008/7/25 Bill Erickson [EMAIL PROTECTED]:
On Friday 25 July 2008 11:43 Kevin Beswick wrote:
14 matches
Mail list logo
