Joshua Ferraro a écrit :
>> Q2 : if the script were not written, what about adding it after a 3.0
>> release ? would it be "yes" or "no" according to you.
> Probably NO in this case, it should be moved to 3.2, and presumably, 3.2
> would be within arm's reach, two to three months max.
(from the pa
Just FYI - I did submit an enhancement request a while ago for this:
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1987
---
Nicole C. Engard
Open Source Evangelist, LibLime
(888) Koha ILS (564-2457) ext. 714
[EMAIL PROTECTED]
AIM/Y!/Skype: nengard
http://liblime.com
http://blogs.liblime
Hello,
This is a record from the original MARC export:
01293pam 22003254a
45100130003000600013005001700019008004100036010001700077020001800094020001500112035002700127040003200154050002300186082001300209119004500960024126000820033732600419651005200445650005200497650004600549
Any chance of preserving the list of barcodes somehow in a way that might be
used again, or by other features? This kind of batch/bulk management is
going to be increasingly important as more large institutions come online.
--Joe
On Thu, Jul 24, 2008 at 9:21 AM, Paul POULAIN <[EMAIL PROTECTED]>
>
> what are the differences introduced at Perl 10.0
> in the CORE that you refer to? Would they affect an existing
> Koha/2.2.9 or Koha3.0 install?
The cause/culprit isn't clear, but we definitely have compatibility issues
between 5.10 and MARC::File::XML, for example. See bug #2309:
http://bug
(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:item_statuses_bulk_change)
We will add a page to bulk change the status or location of an item.
The page will let you :
* choose the kind of info to change
* the value to set
Then, the librarian with scan barcodes and all scan
Paul, this is an awesome suggestion, I have had librarians at larger
libraries ask about this!!
---
Nicole C. Engard
Open Source Evangelist, LibLime
(888) Koha ILS (564-2457) ext. 714
[EMAIL PROTECTED]
AIM/Y!/Skype: nengard
http://liblime.com
http://blogs.liblime.com/open-sesame/
On Thu, Jul 2
(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:item_statuses_auto_change)
In Koha 3.0, the item status is set without duration. We will add a
feature to explain how long a given status will be used, and which
status must be set after that.
That will be usefull, for example, to have a
I love it!!!
---
Nicole C. Engard
Open Source Evangelist, LibLime
(888) Koha ILS (564-2457) ext. 714
[EMAIL PROTECTED]
AIM/Y!/Skype: nengard
http://liblime.com
http://blogs.liblime.com/open-sesame/
On Thu, Jul 24, 2008 at 9:20 AM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> (
> http://wiki.koha
Hi all,
I cannot see where the aqorderdelivery table is used except in some
queries in a acquisitions_stats.pl. However, the table never appears to be
populated. I'm wondering if it has any present or future purpose? If not, is
there any objection to removing it?
Kind Regards,
--
Chris Nighswo
Hi,
I'd like to have a new 'Test Suite' component created on
bugs.koha.org. This component would be for bugs and enhancements to
the test suite itself (e.g., 2091) or for cleaning up problems
identified by new tests (e.g., 2400); neither type of issue fits into
'command-line utilities', and I con
On Thu, Jul 24, 2008 at 1:49 PM, Galen Charlton
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to have a new 'Test Suite' component created on
> bugs.koha.org. This component would be for bugs and enhancements to
> the test suite itself (e.g., 2091) or for cleaning up problems
> identified by new t
On Thu, Jul 24, 2008 at 3:00 PM, Andrew Moore <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 24, 2008 at 1:49 PM, Galen Charlton
> <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'd like to have a new 'Test Suite' component created on
>> bugs.koha.org. This component would be for bugs and enhancements to
>> th
The table is not used anywhere in any code that we've been running.
No objections here.
On Thu, Jul 24, 2008 at 2:29 PM, Chris Nighswonger <
[EMAIL PROTECTED]> wrote:
> Hi all,
> I cannot see where the aqorderdelivery table is used except in some
> queries in a acquisitions_stats.pl. However, t
Joe Atzberger wrote:
> what are the differences introduced at Perl 10.0
> in the CORE that you refer to? Would they affect an existing
> Koha/2.2.9 or Koha3.0 install?
>
>
> The cause/culprit isn't clear, but we definitely have compatibility
> issues between 5.10 and MARC::File::XML
> Why would you deduce that it is the Perl CORE at fault?
I didn't: It's not my bug. The conclusion was that the 5.10 installation as
whole held some incompatibility. I agree the slippery XML parser is a
likely culprit (and a serious pain), possibly because the "wrong" one is
already pre-instal
Joe Atzberger wrote:
> I agree the slippery
> XML parser is a likely culprit (and a serious pain), possibly because
> the "wrong" one is already pre-installed(?) for the OS.
Yes, the XML mess has bitten me before. It is probably something
beyond the scope of Koha installation to prevent.
*UNL
Rick Welykochy <[EMAIL PROTECTED]> wrote:
> Yes, the XML mess has bitten me before. It is probably something
> beyond the scope of Koha installation to prevent.
>
> *UNLESS* perl and all its required C libs are plunked into
> a separate area and a known-to-be-right combination of
> everything perl
MJ Ray wrote:
> Just to be as sure as we can be, shouldn't we bundle that perl and all
> its required C libs with copies of zebra, MySQL, Apache httpd, Linux
> and the tools needed to get it all running?
Actually, that is the only way to guarantee a working Koha install.
This is standard practice
Can anyone comment on whether serials/serials-recieve.pl is being used?
If not, any objections to its removal?
Kind Regards,
--
Chris Nighswonger
LibLime
www.liblime.com
[EMAIL PROTECTED]
___
Koha-devel mailing list
Koha-devel@lists.koha.org
http://l
We should also think about the ways in wich items can be selected to
be part of the batch. Scanning bar codes is cool, but not enough. One
should be able to do it using a kind of search/filter process: i.e.
make a batch of items in branch X with location Y wih status Z.
And name the batch? I agree
Nicolas Morin a écrit :
> We should also think about the ways in wich items can be selected to
> be part of the batch. Scanning bar codes is cool, but not enough. One
> should be able to do it using a kind of search/filter process: i.e.
> make a batch of items in branch X with location Y wih status
22 matches
Mail list logo
