>just make the data loaded in Koha match the printed barcodes.
I would just love to be able to do that.
But Its not possible to exactly match barcodes in Koha with printed
barcodes because :
1) No report from the old software has barcodes in it. ( the barcode
printing utility they have provided
>
> > Is it not possible to do one of these two?
>
> I think they are asking for the proper way of modifying the script
> that generates barcodes in koha for NEW items, preserving the
> semantics of the current system they're using.
>
I don't think so, based on:
Post migration we will generate &
On Tue, Nov 2, 2010 at 4:12 PM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:
> On Tue, Nov 2, 2010 at 2:10 PM, Joe Atzberger wrote:
>
>> Chris, I disagree that the first sign-off on a major vendor's patches
>> should be external. The first sign-off from a major vendor should be
>> *i
2010/11/2 Mike Hafen :
> Why can't you correct the barcodes during the migration?
>
> If you are going from MS-SQL to MySQL you should be able to add another step
> in the middle to populate the barcode from the available information in the
> database.
>
> If you are going from MARC into Koha you s
Just to throw in on this thread for ByWater Solutions:
It is company policy to obtain at least one signoff from another staff
member before submitting a patch to the community. We do not anticipate
that this will be sufficient for inclusion into master (except perhaps on
very simple patches), and
On Tue, Nov 2, 2010 at 5:57 PM, Paul Poulain wrote:
> Le 02/11/2010 22:27, Paul Poulain a écrit :
> > SUGGESTIONS TO DISCUSS:
> > * branch next version when the RM declare feature freeze for a given
> version
>
I'll let this one alone for now.
> > * have a website rebuilded every night (week ?
On 3 November 2010 11:10, Paul Poulain wrote:
> Le 02/11/2010 23:05, Chris Cormack a écrit :
>>> I think we (all) failed because Koha 3.2 was 9 months late. Well, in
>>> fact, I think the mistake was not to branch 3.4 immediatly on feature
>>> freeze. That would have been much less pain for us (th
Le 02/11/2010 23:05, Chris Cormack a écrit :
>> I think we (all) failed because Koha 3.2 was 9 months late. Well, in
>> fact, I think the mistake was not to branch 3.4 immediatly on feature
>> freeze. That would have been much less pain for us (that are
>> customer-planning driven) (suggestion belo
On 3 November 2010 10:27, Paul Poulain wrote:
> We haven't started working on any of those RFCs (except solR, to have a
> proof of concept).
> What has really be a problem for us is that we published RFCs for Lyon3
> university a long time ago (mail from Nicolas on koha-devel oct, 12,
> 2009), th
Le 02/11/2010 22:27, Paul Poulain a écrit :
> SUGGESTIONS TO DISCUSS:
> * branch next version when the RM declare feature freeze for a given version
> * have a website rebuilded every night (week ?) (from which branch ? a
> waiting_librarian_feedback one ?), with all marc21 default values fitted
>
Le 02/11/2010 16:24, Chris Nighswonger a écrit :
> As a vendor-neutral voice, I would like to encourage everyone who has
> an vested interest in these areas and the best interests of the Koha
> project at heart to actively participate and respond to these RFC's.
> It seems that often there is littl
Hi Joe,
On Tue, Nov 2, 2010 at 2:10 PM, Joe Atzberger wrote:
> Chris, I disagree that the first sign-off on a major vendor's patches
> should be external. The first sign-off from a major vendor should be
> *internal* to their quality control process. This was at one time the
> standing policy
I agree, neither itemBarcodeInputFilter nor javascript are necessary. Just
make the data loaded in Koha match the printed barcodes.
If you are worried about further generation of barcodes, then you might have
to insert an artificial max barcode value under the scheme you intend to
use, in order t
Chris, I disagree that the first sign-off on a major vendor's patches should
be external. The first sign-off from a major vendor should be *internal* to
their quality control process. This was at one time the standing policy
amongst LibLime and BibLibre for major changes.
I think encouraging abs
Why can't you correct the barcodes during the migration?
If you are going from MS-SQL to MySQL you should be able to add another step
in the middle to populate the barcode from the available information in the
database.
If you are going from MARC into Koha you should be able to populate the
barco
On Tue, Nov 2, 2010 at 11:02 AM, Vincent Danjean wrote:
> On 02/11/2010 14:32, Tomas Cohen Arazi wrote:
>> On Tue, Nov 2, 2010 at 10:24 AM, Galen Charlton wrote:
>>>
Other question : should we have jquery code inside koha (and thus having
to take care of the updates) or should we use an
Starting a new thread because this is indirectly related to Paul's request.
2010/11/2 Paul Poulain
> Hello,
>
> I have filed RFCs for all enhancements you can expect from BibLibre in the
> next few months. All of them are sponsored (by Saint-Etienne University),
> and will have to be delivered
On 02/11/2010 14:32, Tomas Cohen Arazi wrote:
> On Tue, Nov 2, 2010 at 10:24 AM, Galen Charlton wrote:
>>
>>> Other question : should we have jquery code inside koha (and thus having
>>> to take care of the updates) or should we use an external source ? (does
>>> this exist ? for yui it does, see
On Tue, Nov 2, 2010 at 10:24 AM, Galen Charlton wrote:
>
> > Other question : should we have jquery code inside koha (and thus having
> > to take care of the updates) or should we use an external source ? (does
> > this exist ? for yui it does, see yuipath syspref in koha)
>
> I agree with Chris t
Hi All,
We are implementing Koha at a college. They have a existing software
for library. They have barcoded all their collection of about 15
books with this software.
The peculiar thing about the software and the barcode it generates is this :
The barcode related data stored in the database o
Hi,
On Mon, Nov 1, 2010 at 11:07 PM, Paul Poulain wrote:
> I think jquiry-ui (http://jqueryui.com) is good enough to decide to get
> rid of YUI.
I am in favor of this.
> Other question : should we have jquery code inside koha (and thus having
> to take care of the updates) or should we use an
Another upvote for jQuery. I'm using it for Libki now. I find it far more
elegant to work with than YUI.
Kyle
http://www.kylehall.info
Mill Run Technology Solutions ( http://millruntech.com )
Crawford County Federated Library System ( http://www.ccfls.org )
Meadville Public Library ( http://www.m
> I think jquiry-ui (http://jqueryui.com) is good enough to decide to get
> rid of YUI.
I think this is a good goal. I agree that JqueryUI is mature enough to
start using.
> Cons:
> ? (Anyone want to argue ?)
Not a con, but a difficulty: We need to choose a good jquery-based
menu system to repla
On Mon, Nov 1, 2010 at 11:07 PM, Paul Poulain wrote:
>
>
> Other question : should we have jquery code inside koha (and thus having
> to take care of the updates) or should we use an external source ? (does
> this exist ? for yui it does, see yuipath syspref in koha)
>
I have no problem with chan
Hie,
Can we think about removing "No Zebra" mode ?
It will make code more clear.
Regards,
2010/10/31 Chris Nighswonger
> Hi Toni
>
>
> On Sat, Oct 30, 2010 at 8:22 PM, Toni Rosa wrote:
>
>> Hello,
>>
>> We are using Koha 3.0.5
>> I noticed that the opac advanced search in it (opac-search.pl)
Hi all
Il 01/11/2010 12:54, MJ Ray ha scritto:
Paul Poulain wrote:
- http://wiki.koha-community.org/wiki/Category:Abandoned_RFC => contains
abandoned rfcs (because it's no more relevant or we have lost contact
with the developer)
I've rescued two of them (multi-level biblios and requiring item
26 matches
Mail list logo
