Re: [OPEN-ILS-DEV] Extending Authentication
One use case to keep in mind is the possibility that different patron types might use different authentication methods. At MPOW (not running Evergreen), current faculty, staff, and students log in using their campus LDAP credentials, but guest borrowers and alumni log in using their barcode and last name. - David On Wed, Jul 27, 2011 at 14:34, Jason Etheridge ja...@esilibrary.com wrote: That is certainly a related issue but is not directly covered by this proposal. Initially I would expect this case to simply return a 'user not found' type error. The authentication system will only answer the question Is this person who they say they are?. How the user account gets into the system (whether periodically or 'on-the-fly') will need to covered separately. So authentication versus authorization (I remember having to squint at the definitions for those). -- Jason Etheridge | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Post-conference developer day(s)?
This makes a lot of sense. Unfortunately, I'm probably not going to be coming to the conference this year, since I don't have any travel funding. - David On Thu, Jan 6, 2011 at 00:47, Jason Etheridge ja...@esilibrary.com wrote: Anyway - I haven't booked my flights for the conference yet, and I wanted to canvass the other developers and contributors for their thoughts about this before setting my agenda in stone. Thoughts? It's probably a no-brainer for some of us, being local. I'll definitely be available. -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: ja...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] NCIP
The short answer is, No. The slightly longer answer is, I looked at it a bit a few years ago, but, no. There's a new version of NCIP that's just coming out (or just came out), that takes advantage of the implementation experience of the years since the first version came out. We'd have to figure out how different it was, and which version to implement, if they're different. - David On Mon, Jan 18, 2010 at 20:13, Grant Johnson fgjohn...@upei.ca wrote: Anyone working on connectivity to evergreen item status via the NCIP protocol? F. Grant Johnson Systems Coordinator Robertson Library, University of Prince Edward Island 902-566-0630(w), 902-393-4920(c)
Re: [OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Enabling UTF8 data in SIP2 (patch and RFC)
[page 14 of the v2.12 (April 11, 2006) document] This is part of the bizarre underpinnings of SIP, relying on an obsolete Microsoft codepage. It offers coverage for common Western European languages, but in my experience it breaks on, say, Lithuanian or Arabic. The spec goes on to say If another character set is required, the SC and the ACS must mutually define the character set, but it doesn't say how to establish that. So Evergreen isn't dumbing things down on it's own account. It actually is following the (dumb) spec. Joe, in general, when the spec says things like that, I generally assume that the server and the terminal mutually define the character set by having the humans tell them both what set to use. so you suggestion below that it be a configuration option makes sense. However, given that Evergreen is natively UTF8 from top to bottom, it seems that the appropriate thing to do is to just code the SIP module to be UTF8 aware and tell the terminals to use UTF8, or flat ASCII for those places that can get away with it. As a result, anything we do that is not ASCII-only needs to be the configurable exception, in order to avoid breakage with any *other* poor bastards dutifully implementing the spec. As your intuition suggested, I would recommend doing any character conversion is exactly one place, and not out in the leaf objects like Item.pm. A subsequent page in the spec also says Only displayable characters (no control characters) should be included in print or display messages from the ACS. The question of what is displayable obviously depends on the character set, so that seems to rule out things like the zero-width non-joiner used in Arabic and Hebrew. So what character set would you use there? UTF-8 minus some random pieces? Obviously this is a point of failure in the design. Given that 3M's modern equipment is transmitting UTF8 just fine, it would seem that they are ignoring the spec as published. When I have asked questions of 3M about things in the past, they have responded promptly with clarifications. Perhaps they just need to be prodded to revise their document to update it in this area. Or we just ignore the whole thing and implement NCIP and tell every little library that they need to update their self-check machines and print servers if they want to support non-English languages. - David
Re: [OPEN-ILS-DEV] MFHD Patch - Third Try
On Fri, Nov 20, 2009 at 11:56 PM, Dan Scott d...@coffeecode.net wrote:
* format() subroutine:
* I'm not too happy having the English Note: hardcoded here. In
format_textual_holdings in MFHDParser.pm, I delimited the holdings and
the note via a single dash ('$holdings - $note)', but I suppose there is
a possibility of the single dash introducing some confusion with
compressed holdings. Maybe a double-dash as a delimiter?
Z39.71 explicitly states that it documents the format of each of the
major sections (the data areas) of the holdings information, but not
the sequence in which data areas are to be displayed (sec, 1.1.2).
However, the examples in Appendix A do see to use an em dash/double
hyphen to separate the data areas (see example 6, e.g.), which is in
keeping with the spirit of AACR 2 (which uses the infamous period,
dash, dash separator).
- David
Re: [OPEN-ILS-DEV] MFHD Patch - Third Try
On Fri, Nov 20, 2009 at 5:25 PM, Dan Wells d...@calvin.edu wrote: Hello all, Here is yet another version of my MFHD patch. There are no actual code changes from what has already been reviewed by Dan and David. The new patch: - restores deleted debug comments - follows more carefully the whitespace patches as recently applied in trunk - uses svn diff as run from my svn root (the trunk directory) Dan, Thanks for restoring my debug comments. They're my security blanket. While everything works ok now, I have found that when I add a chunk of new functionality and something breaks, I do end up turning them back on again while I track down the strangeness. This patch is definitely easier for me to review than some of the other ones, thanks to your previous whitespace patches and the beginning of the discussion about a standard perltidy configuration. I'll just do a quick check, and then apply this later today. - David
Re: [OPEN-ILS-DEV] MFHD Patch - Third Try
I'll just do a quick check, and then apply this later today. Whoops. I spoke too soon. Dan, when I try to run my regression test suite agains the patched code, the load fails because it can't find OpenSRF/Utils/JSON.pm. Since I never use OpenSRF, I don't have that checked out or installed on my system. I'm willing to check it out into my development environment, but can you give me a hint as to how you think MFHD/test/Makefile should be edited to eliminate this problem? - David
Re: [OPEN-ILS-DEV] MFHD Patch - Third Try
Dan, Thanks. This is what I did, and everything's checked in. - David On Sat, Nov 21, 2009 at 7:15 PM, Dan Wells d...@calvin.edu wrote: Hello David, As another alternative, if you don't want to bother with installing OpenSRF, it seems likely that this OpenSRF dependency will be removed soon for portability reasons anyway. Because generate_predictions() is the end-of-the-line (so to speak), you can safely comment out from MFHD.pm the 'use OpenSRF...' line and the single call to perl2JSON near the bottom and none of the other internals will be affected, allowing the tests to complete normally. Dan On 11/21/2009 at 5:54 PM, Dan Scott d...@coffeecode.net wrote: On Sat, 2009-11-21 at 13:38 -0500, David Fiander wrote: I'll just do a quick check, and then apply this later today. Whoops. I spoke too soon. Dan, when I try to run my regression test suite agains the patched code, the load fails because it can't find OpenSRF/Utils/JSON.pm. Since I never use OpenSRF, I don't have that checked out or installed on my system. I'm willing to check it out into my development environment, but can you give me a hint as to how you think MFHD/test/Makefile should be edited to eliminate this problem? - David Given a checkout of OpenSRF into ~/OpenSRF, the following works here: PERL5LIB=~/OpenSRF/src/perl/lib/:$PERL5LIB make The only dependency appears to be the JSON::XS module. Hope it works for you!
Re: [OPEN-ILS-DEV] MFHD Contribution Preparation - Whitespace Patch
Thanks for this Dan. I'll get to it today or tomorrow. - David On Thu, Nov 12, 2009 at 4:47 PM, Dan Wells d...@calvin.edu wrote: Hello all, Sometime later today or tomorrow I intend to submit a fairly extensive patch which adds new functionality to the MFHD components in EG. In preparation of that, attached are some whitespace-only patches of the files involved. The files in question were run through 'perltidy -ce' as described in the preliminary code standards document here: http://www.open-ils.org/dokuwiki/doku.php?id=code_formatting_standards Please reply when these get applied, if possible. Thanks! Dan -- * Daniel Wells, Library Programmer Analyst d...@calvin.edu Hekman Library at Calvin College 616.526.7133
[OPEN-ILS-DEV] Prototype perltidy rc file
After seeing Dan Wells' whitespace patch, there was a bit of discussion on IRC about how the default settings for perltidy were... less than ideal. Attached is a perltidy configuration file that I created. It doesn't do too much damage, but I'd appreciate the rest of you running it over some of your code to see if there are bad things that happen. It seems that it's impossible to avoid having the opening and closing parens on a _long_ if () statement being broken onto separate lines, and there are some odd, but not unreadable, things that happen with long lines. If you normally use tab characters in your files, then make sure to include the '-et=8' option on the command line when you're testing. This will ensure that the tabs are preserved, and you will only see true formatting changes. perltidyrc Description: Binary data
Re: [OPEN-ILS-DEV] Testing Evergreen
same block. E.g. it chokes on something like this:
int main( void )
{
printf( Hello, World!\n );
int rc = 0;
return rc;
}
Our C code does this sort of thing a lot. It's not kosher according to C89,
but GCC accepts it without complaint. I'm not sure what the C99 standard has
to say on the subject. In any case it's a useful language feature because it
allows you to further limit the scope of your local variables. It saddens me
that splint doesn't like it.
I choke on that. I suspect that gcc accepts it because it is
acceptable for C++, and GCC does both languages. But then, I'm old
school.
Re: [OPEN-ILS-DEV] LDAP Authentication Ideas
Innovative has an LDAP authentication module, which we use at UWO. We're in a similar situation to George in that we have users with LDAP credentials and users without. It seems that Innovative can select the authentication method to use based on the patron type: faculty, staff, students use the LDAP method, alumni and guest borrowers use the internal name barcode authentication method. Something like that, having the authentication method be dispatched through the patron types table, would probably be fantastic. - David On Fri, Oct 16, 2009 at 9:16 AM, Duimovich, George george.duimov...@nrcan-rncan.gc.ca wrote: We haven't looked at LDAP but are interested. We have both internal clients with LDAP accounts and external users (no LDAP accounts) so we'll eventually need something that allows their My Account login to either figure out which 'domain' to authenticate against, or let the user chose EG vs. Departmental authentication. In the interim - for active users - we use a variation of option b) by setting Username to their login id so that when they first login they could optionally sync their EG password for something more familiar to the user (like their LDAP pwd). We also will likely populate username field with LDAP login when we eventually begin to sync parts of our patron database with our ldap directory. George D. -Original Message- From: open-ils-dev-boun...@list.georgialibraries.org [mailto:open-ils-dev-boun...@list.georgialibraries.org] On Behalf Of Nathanael Schilling Sent: October 16, 2009 06:05 To: Evergreen Development Discussion List Subject: Re: [OPEN-ILS-DEV] LDAP Authentication Ideas Interresting... I was looking into LDAP (specifically AD) authentication a week or so ago, but couldn't come up with a solution that a) Was secure (i.e. didn't involve storing cleartext passwords) b) Had password uniformity (i.e. both eg and ldap had the same passwords) c) Synced passwords between ldap and eg one way. If I understood correctly, your solution exports all LDAP users and then loads them into eg, right? I like your method, but the only drawback I can see is that passwords are submitted cleartext over the web, though that might not be a too big problem for some people. Another question would be how many places code would need to be modified for this to work? staff client,OPAC, anything else? Otherwise, this looks quite promising, keep us posted on the mailing list! Nathanael Schilling On Wednesday 14 October 2009 10:27:34 pm Victoria Bush wrote: I don't know how feasible this is, but in our environment the ability to authenticate against LDAP itself would be wonderful. I would prefer it if there isn't a separate password in Open-ILS, as we have a lot of centralized services that authenticate against LDAP and it would be so nice to allow Evergreen to do the same. -Vicki On Oct 12, 2009, at 3:56 PM, Dan Wells wrote: Hello all, I am in the process of implementing a basic LDAP authentication layer for my library for the catalog 'My Account' features. I currently have two working proof-of-concepts and am seeking input about further development of one or the other. The overall approach is common to both and is as follows. The users are exported from LDAP and batch loaded into the Open-ILS system, but the password in Open-ILS is not their LDAP password, but instead is a salted/hashed version of their LDAP ID. The Open-ILS LDAP authetication layer receives the username and password from a web form, binds with LDAP using these as credentials to receive the LDAP ID and verify the password, salts and hashes the ID and uses the this ID and hash to authenticate to Open-ILS. So far I have gotten this to work using both an external and an internal form. For the external version, a separate (mock) login page is created, the user submits their credentials, the script behind the form performs the LDAP bind and subsequent authenticate_init and authenticate_complete steps, then sets the 'ses' cookie variable and redirects to the My Account page. The primary advantages of this approach are needing only to alter the login/logout button behavior in the OPAC and also perhaps not needing an SSL certificate for the catalog server (as the external script can run from a different, already secure server). For the internal version, I created a simple OpenSRF service which replaces/wraps both authenticate_init and authenticate_complete into a single step (since we can simply send the password along) and which is accessed by a slightly modified doLogin script. This approach allows one to use the My Account login page more or less as- is, but does require a bit more customization on the server end. I am not really sure what best practices are for customizations to the OPAC, but I am wondering if a standard way to override doLogin needs some consideration. While it seems I
Re: [OPEN-ILS-DEV] Or maybe, developer IRC meeting: Friday, October 16th, 10:00 am EST
I can do 9:00 eastern but not 10 eastern. So, if it moves, I'm out. Aside from that, it's fine ;-) On Mon, Oct 12, 2009 at 4:00 PM, Dan Scott d...@coffeecode.net wrote: 2009/10/12 Dan Scott d...@coffeecode.net: We had 13 total responses to the poll for best times to hold the developer IRC meeting, although two of them were refined responses based on the clarification of the 1:00am/2:00am as actually meaning 1:00pm / 2:00 pm. So of the total of 11 responses, the best time (where only one person would not be able to attend) turned out to be Friday, October 16th, at 9:00 AM EST. My apologies to our friends on the West Coast - you're welcome to attend in your pyjamas, even in bed - just don't turn on your webcams, please :) As a reminder, this is a public meeting for Evergreen developers that will be held on the #evergreen channel on the Freenode IRC network (http://open-ils.org/irc.php). All members of the community with an interest in contributing to the development of Evergreen are welcome to attend - and if you are unable to attend at the designated time, please feel free to submit comments for any of the agenda items in advance to the Evergreen development mailing list. The agenda is continuing to evolve at http://open-ils.org/dokuwiki/doku.php?id=dev:meetings:2009-10 - please extend and amend to ensure that it meets the immediate concerns of the project. We might be able to make the meeting go a bit smoother by doing some work in advance; for example, I've taken a few minutes to try and clean up the bugs/features in Trac that I should have closed months ago or deferred to a subsequent release. For agenda items that have the potential to be too long to express during a single IRC meeting, it would probably make sense to post more considered opinions in advance on this mailing list. Examples of such agenda items might include major release process changes or drastically revising our bug tracking processes. If a given discussion item starts eating up too much meeting time and a decision is not immediately necessary, we can also delegate the responsibility to a volunteer sub-team for investigating alternatives and coming up with a proposal for adoption at the next meeting. Lastly, all of this is new, so I'm sure there will be plenty of learning as we go - like, distinguishing between AM vs. PM. Heh. :) Well, just to throw another curve... it seems that in an attempt to be helpful, when you enable time zone support, even though you enter the times for a given poll with a given time zone (I chose America/New York), Doodle resets the time zone display to America/Rainy River for everyone every time they enter the poll. So, those who switched the time zone to America/New York (or the equivalent) would have seen time slot choices of 2:00 am, 3:00 am, 8:00 am, 9:00 am, and 10:00 am; while the default of America/Rainy River showed 1:00am, 2:00am, 7:00am, 8:00am, and 9:00am. From David's response pointing out the 1:00 am vs. 1:00 pm screw up, I'm guessing that he missed that time zone problem as well, and it's likely that others did. Which means that we have 11/12 people who responded yes to either 10:00am or 9:00 am (EDT) on Friday, October 16th. I know our West Coast friends would prefer the 10:00am EDT time slot on Friday, October 16th. To side step another Doodle poll, would that be okay with everyone else?
Re: [OPEN-ILS-DEV] Setting up a developers' IRC meeting for next week
Dan, I assume that the 2am and 3am timeslots are really supposed to be 2pm and 3pm. I've been caught out by that feature of doodle as well. - David On Thu, Oct 8, 2009 at 11:04 PM, Dan Scott d...@coffeecode.net wrote: With 1.6 coming close to a final release, I've been pushing for a developers' meeting in IRC over the last few days (hopefully not too annoyingly!) and I think we're close to nailing down a time next week for a meeting, based on my fractured IRC conversations. Since this approach seems to have worked out for the DIGgers for setting meeting times, I've thrown a few time slots for next week into this meeting organizer at http://www.doodle.com/x8s9ihuza86sfurc - just mark OK for any times (America/New York time zone) that would work for you, and on Monday afternoon I'll announce the time that works best for the people that have responded by then. I've also put a shell of an agenda on the wiki at http://open-ils.org/dokuwiki/doku.php?id=dev:meetings:2009-10 - please modify extend this so we have something reasonable to work from!
Re: [OPEN-ILS-DEV] Bug tracking (was: 1.6RC1 - Acquistions - possiblebugs)
Karen, The good thing about a bug tracking system is that it can generate email when new problems are reported, and can allow users to register their interest in updates on the status of individual reports. No matter what structure for handling questions and reports shakes out in the long run, developers will have to continue to trawl the mailing lists and create problem reports based on things that come up in the mailing lists, because we will always as questions about stuff we're confused about, and sometimes those questions will lead to newly identified problems. I like the idea of an address to which people can send messages reporting problems, which Dan's swinging gate peer review committee would all monitor and from which most problem reports would be created. - David On Fri, Sep 18, 2009 at 11:52 AM, Karen Schneider k...@esilibrary.com wrote: Right, in my mind wider community would be a small team who would be able to make that distinction based on questions / reports posted to the mailing lists. We don't have to grant ticket management powers to everyone. I think this was part of the problem with the old Bugzilla instance: lots of noise that quickly became unmanageable. So just to be clear, questions/bug reports would still go to mailing lists? One thought I had about that approach (since I agree on noise reduction but also want the process to be easier) was making THAT more structured, and communicating that process back to the community. A separate mailing list, evergreen-ils-bugs? I worry developers will scream, but this is another situation where I see a single web forum working better than these individual mailing lists. -- -- | Karen G. Schneider | Community Librarian | Equinox Software Inc. The Evergreen Experts | Toll-free: 1.877.Open.ILS (1.877.673.6457) x712 | k...@esilibrary.com | Web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Export to RefWorks in Evergreen
You definitely need to be able to turn it off and on. The default should probably be off. You also need to be able to set the refworks server name, since most Canadian universities don't go to the refworks.com server, but use the Canadian server, refworks.scholarsportal.info. In the perfect world, individual users would have a personal configuration option, but that's easily handled by some of the other ways of integrating refworks. - David On Fri, Jun 19, 2009 at 5:28 PM, Mike Rylandermrylan...@gmail.com wrote: On Fri, Jun 19, 2009 at 5:14 PM, Mike Rylandermrylan...@gmail.com wrote: On Fri, Jun 19, 2009 at 5:11 PM, Bill Ericksonerick...@esilibrary.com wrote: On Thu, Jun 18, 2009 at 7:39 AM, Warren Layton warren.lay...@gmail.com wrote: On Wed, Jun 17, 2009 at 11:50 PM, Mike Rylander mrylan...@gmail.com wrote: Hrm ... is the purpose of VENDOR to tell RefWorks what sort of system the data is coming from, or to tell them which of their clients is using the service? I believe it's the latter (for instance, see the link to RefWorks at http://mirlyn2-beta.lib.umich.edu/Record/001376273 ). I've attached a slightly modified patch that doesn't append +Evergreen to VENDOR and just uses the org's fullname (with spaces replaced with '+' chars). That is likely more appropriate, at least from RefWorks' point of view. Couple comments... We need to turn Export to RefWorks into a DTD entity for i18n purposes (says the lazy i18n-er). Done while integrating the patch. We also need to consider displaying (or suppressing display) of the link by org unit setting or some other easily toggled switch in the javascript. Not done ... but I'm inclined to leave it in, rather than out, by default for now. Thoughts, anyone? Other than that, the patch looks great to me. I also wrapped the code that does the actual attribute setting in a test to make sure the element's there, which it won't be in craftsman, for now. wlayton++ Indeed. Not committed yet. Waiting on an updated xslt. Now ... it's committed. Thanks a ton, Warren. Very nice work. I'm not going to backport this from trunk to 1.6 just yet so we can have some discussion on the ability to turn it on or off, and what the default should be. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Circulation Menu in the Staff Client
In the ILS I normally use, the only way (that I know of) to find a patron record from the staff client is to go to the Circulation screen. Given the most common use case, I think that that is probably the place that it should continue to live. Also, congratulations (?) Laura on becoming a committer. Now if something breaks, we are officially allowed to blame you for making the change. - David On Wed, Jun 17, 2009 at 4:10 PM, Jason Boyerjas...@myjclibrary.org wrote: Why would it be left under Search, and not Circulation? You can't search from it at all, you have to already have and enter the entire barcode for it to work. If it just has to stay under Search, can it be changed to Retrieve Patron by Barcode ? Jason -- Jason Boyer, IT Specialist Jackson County Public Library 303 W Second St Seymour, IN 47274 jas...@myjclibrary.org On Wed, Jun 17, 2009 at 3:54 PM, Laura M. code...@gmail.com wrote: So, I'm going along and I'm adding some functionality to the Staff Client in Evergreen when I realize that we have two ways of looking up a patron by barcode (actually three or four, depending on how technical you want to get). One way to do this is under the 'Search' menu, the other way is under the 'Circulation' menu. Being that I'm a maven for usability and user-centered design, this multiple entry point thing is making me twitchy. But having an identical menu option in a menu that has nothing to do with searches, AND there is a 'Search' menu right next to the 'Circ' menuwell, I just want to remove this entry point. Does anyone have any major objections to this? I am NOT, in ANY WAY, removing Search Patron by Barcode, I am JUST taking out a redundant menu item that has no place being where it is. I'm trying to make Evergreen a bit more user-friendly and have a few more formal usability specifications and this is a good place to start. Thanks for any feedback! If I don't get any threats in 48 hours I'll remove the tumorous menu item and Search Patron by Barcode will be under *just* the 'Search' menu, where it's always been and will always remain :) Thanks! Laura McFarland -- Developer Equinox Software
Re: [OPEN-ILS-DEV] URL checking
This sounds like it would make a great hackfest project for the conference next month. On Wed, Apr 22, 2009 at 8:37 AM, Duimovich, George george.duimov...@nrcan-rncan.gc.ca wrote: Anybody work out a good process to link check your 856 URLs? In a similar situation for another database, we periodically generated a list of 856 URL's and text and then ran the file through one or another link checker.. We could extract the TCNs URLs to a file and then check links that way, but I'm curious if anybody is doing anything different, perhaps going the extra automation way and updating them post check via SQL? Thanks George Duimovich NRCan Library / Bibliothèque RNCan Tel: (613) 996-2101
Re: [OPEN-ILS-DEV] Booking Equipment or Rooms on Evergreen
Yes, Innovative Millennium has a booking function that allows staff to reserve items in the future. One of the branches at my library uses it to reserve videos for students who want to use them in class. When an item is reserved, somebody who attempts to check the item out now will get a shortened borrowing period, to make sure that the booked item is back for the reserved time. We tried to use it for booking rooms and other types of things, but found that it didn't really work that well, for a bunch of different reasons. The biggest one is that if you have a bunch of rooms which are all pretty much interchangeable, and you just want to find a free room for a given time slot, you end up navigating around a lot. Google calendar or some other corporate calendaring system will probably work better for that sort of thing. If you want to let authorized users book rooms for themselves, then that might be tricky with a stock sort of system. - David On Sat, Nov 15, 2008 at 1:58 PM, David Kane [EMAIL PROTECTED] wrote: Thank you Jason. On Innovative's Millennium, you can do this. I don't know about any open source projects that do this. I will say that I know of cases where Google's Calendar application is used. Just a random relevant thought - the data import/export format for Google Calendar is open. This would make it easy to publicize any booking information. Best, David. 2008/11/15 Jason Etheridge [EMAIL PROTECTED] On Sat, Nov 15, 2008 at 9:02 AM, David Kane [EMAIL PROTECTED] wrote: I was wondering if it is possible to book a resource for a discreet period of time. For example, 'book a multimedia PC between 1 and 2 p.m.' or book a room for a meeting etc. Hi David, there's no booking or reservation system like that in EG today, though I believe there are folks who want to sponsor the development of such. Is this possible now, or can any developers tell me whether this kind of functionality is within easy reach? Are there any other open source projects that do this? We might be able to integrate with them or leverage their code. -- Jason Etheridge | VP, Community Support and Advocacy | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com -- David Kane Systems Librarian Waterford Institute of Technology http://library.wit.ie/ T: ++353.51302838 M: ++353.876693212
[OPEN-ILS-DEV] Does Evergreen support external authentication/identification modules?
I know that in the original PINES environment, users have the option of creating their own user names and passwords and that they can use that to authenticate when doing things, once they've entered their library barcode and everything matches up. My library uses the centrally managed LDAP server to authenticate users, and I suspect that there are academic libraries out there that might like to hook the ILS up to the local Shibboleth single sign-on service. How hard would it be to disable the create your own ID part of Evergreen and hook it into an existing institutional authentication system like that? - David
Re: [OPEN-ILS-DEV] Thinking about receiving
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] wrote: 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 no ISBN. Bryan Baldus Cataloger Quality Books Inc. The Best of America's Independent Presses 1-800-323-4241x402 [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] Thinking about receiving
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 match a PO. As far your second paragraph about multiple copies, this is exactly why I got fuzzy in my original thinking. Thanks for the suggestions. -David On Mon, Jul 28, 2008 at 10:43 AM, Carri L. Oviatt [EMAIL PROTECTED] wrote: 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 far as receiving one copy at a time vs. keying in numbers. To fit multiple needs it would be good to have the option. There are also times when an item has been ordered on multiple POs. If that is the case it would be good to have a prompt that asks which copy is being received. (It isn't always the first copy that was ordered.) Good luck Carri
Re: [OPEN-ILS-DEV] Introductions (a message too late?)
Just so long as he's Harry Potter great and not Voldemort great. On Wed, May 14, 2008 at 1:26 PM, Mike Rylander [EMAIL PROTECTED] wrote: Anyway, that's Kevin, and that's what his patch post was all about. Sorry for the late introduction, but please welcome him as we do. We expect great things! :)
Re: [OPEN-ILS-DEV] SIP2 in Evergreen
John, Yes, any generic sort of SIP self-check machine should work just fine. If you have any problems, Bill and I are the guys to talk to. I know that people are using envisonware for self-check and pc management (in a PL environment) and bluesocket for wireless authentication, at least. - David On Mon, May 12, 2008 at 11:44 AM, John Fink [EMAIL PROTECTED] wrote: Hey folks, We're in the midst of retooling one of our libraries, and we're going to put a self-check machine in it. What self-check machines do the production sites (PINES/Sitka whomever else) use? Is any machine that is SIP2 compliant going to be okay generally? jf -- http://libgrunt.blogspot.com -- library culture and technology.
Re: [OPEN-ILS-DEV] connecting outside of LAN
Robert, I'm on campus at the University of Western Ontario, and I'm having no problems connecting to the your test server. - David On Thu, Apr 24, 2008 at 8:32 AM, Mike Rylander [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 8:25 AM, Robert Soulliere [EMAIL PROTECTED] wrote: We installed the evergreen successfully on our test server and can connect to the evergreen server from inside the LAN and from another University where we have a satellite campus. However, I am unable Congrats! connect from my home network and one of my colleagues was also unable to connect from here home. I was wondering if anyone could 1) test to see if they can connect from their location to the domain name: http://evergreen-server.mohawkcollege.ca/ It's not letting me in from several locations on the 'net. 2) Let me know where else I could look to find out where the problem is. I checked hosts.deny, hosts.allow all the apache configuration files the hosts file and anything else I thought would be related to a webserver and web security. Is it something I need to contact my campus web administrator about to open up access to the machine for the WWW or is it something on the local machine? This is definitely a campus IT issue. They will most likely need to open the border firewall to allow traffic to the proper ports on your evergreen machine. I wouldn't be surprised at all if your satellite campus simply has an all-access ruleset from their network block. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
