On Wed, Oct 15, 2008 at 6:30 PM, Daniel Sweeney
<[EMAIL PROTECTED]> wrote:
> From a system perspective, I think
> you would probably need more than one type of loan, so that you could
> give the patron an "in-library" loan for a few hours, using an hourly
> circulation policy, then let them upgrade
On Wed, Oct 15, 2008 at 6:37 PM, Galen Charlton
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've found at least one Koha database that has multiple issues rows
> for the same item but different patrons. This doesn't map well to the
> reality of loaning physical items, unless somebody's slipped in a Star
++ here. I would suggest going just a bit further:
let's fix the other columns in the table while we're there.
* what is the difference between branchcode and issuingbranch ?
A transaction can only happen at one location, so that should be NOT NULL
and the other should be removed.
issues.retu
The example crontab file was altered to make it's examples invalid. They
look like lines for cron, not crontab.
Please see the original crontab.example:
http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=misc/cronjobs/crontab.example;hb=830d1f19b458fce4ba9c03bd9aa7759e9f698def
--Joe Atzberge
Hi,
On Wed, Oct 15, 2008 at 7:12 PM, Chris Cormack <[EMAIL PROTECTED]> wrote:
> Does the issues table now only contain current issues?
> Ie no history of past issues
Past issues were moved to old_issues a while back, so the reading
history is still retained until purged or anonymized.
Regards,
Hi Galen
Does the issues table now only contain current issues?
Ie no history of past issues
How do we find out a borrowers reading history then? (People in NZ
like this feature a lot, especially places like retirement homes so
the library doesnt send them the same books all the time)
Im hoping
All sound good to me.
On Wed, Oct 15, 2008 at 6:37 PM, Galen Charlton
<[EMAIL PROTECTED]>wrote:
> Hi,
>
> I've found at least one Koha database that has multiple issues rows
> for the same item but different patrons. This doesn't map well to the
> reality of loaning physical items, unless somebo
Hi,
I've found at least one Koha database that has multiple issues rows
for the same item but different patrons. This doesn't map well to the
reality of loaning physical items, unless somebody's slipped in a Star
Trek-style replicator feature, so I propose the following changes to
constraints on
On Wed, Oct 15, 2008 at 12:41 PM, Ryan Higgins <[EMAIL PROTECTED]> wrote:
>
> I highly favor adopting DBIx::Class or another db abstraction layer
> over writing our own lightweight abstraction layer. While it will seem
> lighter at first to create our own, we will want to add more functionality,
Hi,
On Tue, Oct 14, 2008 at 6:17 PM, Luis Maguina Silva
<[EMAIL PROTECTED]> wrote:
> 3. I write a console (Debian etch)
> ./rebuild_zebra.pl -b -a -z >/dev/null
> the koha show me :can\'t use an undefined value as a hash reference at
> rebuild_zebra.pl line 87
>
> the line 87 says:
> my $biblioser
I highly favor adopting DBIx::Class or another db abstraction layer
over writing our own lightweight abstraction layer. While it will seem
lighter at first to create our own, we will want to add more functionality,
multi-db support, etc. I think it is better to take advantage of the
excellent
wo
Hi Paul,
This is interesting. The scenario you describe would not be accounted
for in the Hourly Circulation Policies specification. Libraries that I
have talked to in the US and UK that have significant closed-stack or
reserve collections don't seem to follow the model you talk about
belo
I'll assume you have the circulation and fines rules setup already for
overdue fines. Also it sounds like you have Koha version 3, so I'll
assume you do.
Setting finesMode to "production" is the first step. The next is to
make a cron job to run the script "fines.pl" once a day. There is an
exam
Hello everybody. That's my first email so I hope I can express myself.
I want to use the fines Mode but I'm not sure how to put it working. I
have gone to "Circulation preferences" and I put the "finesMode"
variable to "production", but it doesn't do nothing.
I want to create a fine when anyone d
On Wed, Oct 15, 2008 at 10:45:07AM -0400, Joe Atzberger wrote:
> Marc --
yeah, i know ... that's almost a part of your autoreply, now :)
> It is a little more of an OO approach, and I'll be interested to see
> what you think of it.
it would be a pleasure to me.
I didn't use OO approach because
Joe Atzberger a écrit :
> Marc --
Hi Joe, so, in fact, it's marc ++, right ;-)
we (BibLibre) have decided to dedicate Marc half time on this kind of
subjects, from nov, 1st, to dec, 31. Marc has a lot of ideas that, i'm
sure will improve Koha performances & code.
(PS : Unless a new contract fa
Joe Atzberger a écrit :
> Marc --
>
I think you meant Marc++ ;)
> Looks cool. We have been talking about consolidating all the
> repetitive table operations in similar ways. I have an experimental
> implementation as "C4::Table" that also tries to provide baseline
> SELECT, UPDATE and eventually
Marc --
Looks cool. We have been talking about consolidating all the repetitive
table operations in similar ways. I have an experimental implementation as
"C4::Table" that also tries to provide baseline SELECT, UPDATE and
eventually DELETE. I think I'll have a chance to look at it more on Frida
Hello Daniel (& koha-dev),
I'm reading your RFCs abour hourly circulation policies. and I have a
question about them.
Here in France, a common situation is the following :
the students can issue ON SITE (in the library) some books (say 10), for
the day.
If they are happy with the book, they can
hello guys,
I just rewritten the C4::Bookseller::AddBookseller and it now looks
like:
sub AddBookseller {
_koha_insert_and_get_id(
'aqbooksellers', shift
);
}
_koha_insert_and_get_id is a function where i deal with DBI and all specific
DBD tricks with reuse in mind. You can s
20 matches
Mail list logo
