2008-03-03T00:51:10 *** greg-g has quit IRC 2008-03-03T02:16:46 *** Mark__T has joined #openils-evergreen 2008-03-03T08:51:03 *** dbs has joined #OpenILS-Evergreen 2008-03-03T08:55:20 I realized my patch to supply a default opensrf_core.xml location for osrf_ctl.sh will break if the install prefix is ever anything more than a single level of hierarchy. 2008-03-03T08:56:58 I'll need to, at least, add a test for the existence of the file and bail with an appropriate error message 2008-03-03T09:00:42 dbs: when was this? 2008-03-03T09:04:13 about 10 hours ago 2008-03-03T09:04:49 I've got the defensive programming bit working now, will check that in 2008-03-03T09:05:39 After that, I could add checks for file ownership & visibility 2008-03-03T09:07:50 okay, checked in 2008-03-03T09:08:58 miker_: btw - SRU! SRU! 2008-03-03T09:10:46 yeah 2008-03-03T09:11:27 a couple things are still broken, but it's getting there 2008-03-03T09:12:42 for the osrf_ctl.sh patch: I just got tired of having to type -c /openils/conf/opensrf_core.xml, now the script takes the first path element of $0 and tacks /conf/opensrf_core.xml on as the default location 2008-03-03T09:13:29 yeah, I'm not crazy about that ... /etc/opensrf_core.xml is a likely location down the road 2008-03-03T09:13:33 I could make it smarter, I suppose, and take the elements up to "bin" and swap "bin" with "conf", but the current version will work for 99% of the deployed or test systems 2008-03-03T09:13:50 the whole 'conf' thing bugs me... 2008-03-03T09:14:02 miker_: sure - but when we add FHS compliance, there's a hell of a lot more to worry about; that will be a simple fix. 2008-03-03T09:14:49 and I've lived with this for a year now and will go (even more) nuts if I have to live with it for another year 2008-03-03T09:14:57 I'm not talking about FHS, just "put stuff in a more standard location" ... and I really only care about opensrf for that 2008-03-03T09:15:34 maybe that explains berick and me (3.5yr) 2008-03-03T09:15:38 heh 2008-03-03T09:16:35 heh 2008-03-03T09:16:39 and autotools should take care of most of the fhs pain anyway 2008-03-03T09:16:55 --prefix, --bindir, etc 2008-03-03T09:17:11 * miker_ coughs in asmodai's general direction ;) 2008-03-03T09:19:01 *** rsinger has joined #OpenILS-Evergreen 2008-03-03T09:19:33 rsinger: have you come to beat me about the head and neck, sir? 2008-03-03T09:19:36 miker_: true that - while we wait for that, though, I'll be happy to save my fingers the minor strain 2008-03-03T09:20:07 miker_: nossir, i thought that was a good post 2008-03-03T09:20:09 oh, and for Google Summer of Code - how about pointing a student at an updated version of the FIT proposal? 2008-03-03T09:20:17 miker_: i plan on responding to it today 2008-03-03T09:20:21 ha ... well, if you're going back in there, would you mind putting a big '#XXX miker hates this' next to it? 2008-03-03T09:20:46 miker_: wasn't the FIT proposal yours? 2008-03-03T09:21:20 dbs: parts of it. it was an amalgamation[sic] of ideas 2008-03-03T09:21:58 but FIT was about having an installation tracking system ... if that existed then I wouldn't care where anything live! ;) 2008-03-03T09:24:07 miker_: i have a meeting with aquabrowser and bibliocommons next week -- i'll pitch the opensrf idea to them, as well 2008-03-03T09:24:25 rsinger: what are you buttering me up for?!?! 2008-03-03T09:24:43 rsinger: if you'll be talking to taco, say hi for berick and I 2008-03-03T09:25:10 Hmm. Then maybe a slimmed down student proposal could be: "use autotools for more standard configuration and dependency-checking; create at least one set of system packages (DEB or RPM)" 2008-03-03T09:25:13 miker_: well, we want to avoid any players thinking this is an 'evergreen based app' 2008-03-03T09:25:26 ahh... righto 2008-03-03T09:25:27 miker_: i figure they'd be good candidates to gauge perception 2008-03-03T09:25:45 I re-read the OpenSRF-over-HTTP proposal in the airport and had some (probably dead end) thoughts about exposing (at least parts of it) as a more RESTful interface 2008-03-03T09:25:46 rsinger: forget you know me, then :) 2008-03-03T09:25:55 miker_: :) 2008-03-03T09:26:20 dbs: I like the GSoC idea 2008-03-03T09:26:27 miker_: i'm still leaning towards opensrf, personally, if just for the 'hitting the ground running' aspect 2008-03-03T09:26:58 miker_: but i still have to reconcile the perception 2008-03-03T09:27:15 dbs: yeah, that seems like a good tidy gsoc project 2008-03-03T09:27:29 rsinger: the evergreen perception? 2008-03-03T09:27:35 miker_: yeah 2008-03-03T09:27:43 i mean, to the community 2008-03-03T09:27:47 not to myself 2008-03-03T09:28:15 miker_: is anybody from ESI going to the dlf meeting on thursday? 2008-03-03T09:29:21 rsinger: no sir ... I don't believe we got an invite, nor did we (well, I) know about it other than extremely vaugely 2008-03-03T09:29:49 miker_: i'm trying to weasel out of going (i don't really want to fly back across the country this week) 2008-03-03T09:29:49 Right now OpenSRF-over-HTTP is pretty much XML-RPC (POSTing XML), but wouldn't it be nice to be able to GET plain old JSON back from something like /search/keyword/bubbles (open service), or /patron/checkouts/ (if authenticated over HTTPS) 2008-03-03T09:30:16 dbs: opensrf over http isn't meant to be restful, but the gateway sorta/kinda is 2008-03-03T09:30:35 miker_: jangle seemed to be pretty well received at c4l 2008-03-03T09:30:50 miker_: casey bisson seemed to want it for scriblio, at least 2008-03-03T09:30:54 miker_: okay - I thought I might be tilting at the wrong windmill 2008-03-03T09:31:07 * dbs agrees with rsinger - reception was goot 2008-03-03T09:31:09 dbs: don't we all? 2008-03-03T09:31:39 rsinger: that's the feeling I got from berick, which is really good! 2008-03-03T09:32:21 miker_: i can't tell if the dlf folks got that we weren't trying to step on their toes... 2008-03-03T09:32:38 miker_: xc seemed partially interested, but wary of sharing connectors 2008-03-03T09:33:13 wow, really? wary of sharing connectors why? 2008-03-03T09:33:21 that seems -- dumb 2008-03-03T09:33:24 well, this was over being taken to dinner by talis 2008-03-03T09:33:29 so... 2008-03-03T09:33:43 oh. because talis would benefit? 2008-03-03T09:33:48 oh, so it may have just been a EvilVendor thing 2008-03-03T09:33:53 jangle as jangle hadn't been established 2008-03-03T09:33:58 miker_: right 2008-03-03T09:34:02 (never mind that the rest of the library world would benefit) 2008-03-03T09:34:30 dbs: right :) "We'll open source it, but only if no vendors are involved." 2008-03-03T09:35:20 well, it was the partnering i think they were less keen on 2008-03-03T09:36:05 like i said, it probably came across (on tuesday night) like we were trying to coopt the dlf initiative 2008-03-03T09:37:46 honestly, I've felt that way before with m5rob and rjw ... but now I understand their plight, and hold them no ill will ;) 2008-03-03T09:38:01 dbs: did you see a working SRU link yet? 2008-03-03T09:38:11 miker_: haven't installed yet, so no 2008-03-03T09:38:21 http://dev.gapines.org/opac/extras/sru?version=1.1&query=dc.title+all+%22potter+harry%22+AND+eg.site=PINES&operation=searchRetrieve&maximumRecords=1 2008-03-03T09:38:50 * rsinger chuckles. 2008-03-03T09:38:56 need to move the context set map into the db and build explain and diag messages 2008-03-03T09:39:03 I assume mmmmmRob and tjw just rolled their eyes at the end of my CouchDB presentation when I made the plea to share all kinds of data via OpenLibrary 2008-03-03T09:39:06 and a couple other things, but it's close 2008-03-03T09:39:47 didn't talis dump a huge pile of records on openlib? 2008-03-03T09:40:07 yes they did 2008-03-03T09:40:38 I was talking more about holdings data, and reviews, and comments, and tags, and circ data... 2008-03-03T09:40:46 ahh 2008-03-03T09:41:02 see, not being there I made a bad assumption :( 2008-03-03T09:42:40 I had this crazy idea of a hub and spoke bidirectional replication model, where you could replicate locally all of the data that you're interested in (matching your bibs, perhaps) to avoid network latency and central dependencies 2008-03-03T09:43:06 but to push back new stuff contributed at your site 2008-03-03T09:43:21 of course it would be relatively easy to poison the well 2008-03-03T09:43:23 <-- naive 2008-03-03T09:43:29 <-- going to get coffee 2008-03-03T09:43:47 *** Karen_ has joined #OpenILS-Evergreen 2008-03-03T09:47:31 *** djfiander has joined #OpenILS-Evergreen 2008-03-03T10:23:06 *** Mark__T has quit IRC 2008-03-03T10:41:30 *** jbfink_ has quit IRC 2008-03-03T10:57:51 *** JMCraig has joined #openils-evergreen 2008-03-03T11:14:43 *** agJohn has quit IRC 2008-03-03T11:35:00 if it weren't for connection problems, _nothing_ would happen in here 2008-03-03T11:43:26 djfiander: i'm in today, if you have time to talk acq 2008-03-03T11:44:28 berick: thanks. probably later this afternoon I can carve out some time 2008-03-03T11:44:35 k 2008-03-03T11:52:59 *** dmcmorris_esi has left #OpenILS-Evergreen 2008-03-03T11:53:32 *** dmcmorris_esi has joined #Openils-Evergreen 2008-03-03T12:50:48 *** sarabee has quit IRC 2008-03-03T12:50:48 *** gmcharlt has quit IRC 2008-03-03T12:50:48 *** pmurray_away has quit IRC 2008-03-03T12:51:15 *** sarabee has joined #openils-evergreen 2008-03-03T12:51:15 *** gmcharlt has joined #openils-evergreen 2008-03-03T12:51:15 *** pmurray_away has joined #openils-evergreen 2008-03-03T15:30:42 berick? 2008-03-03T15:31:36 yo 2008-03-03T15:31:43 so, can we talk? 2008-03-03T15:31:54 djfiander: we can 2008-03-03T15:32:09 did my long rambling email of last night make sense? 2008-03-03T15:32:59 no, cuz i haven't read it yet ;) but i can right now 2008-03-03T15:33:04 heh 2008-03-03T15:33:18 glad to see the bad field thing is fixed. 2008-03-03T15:34:00 short version: I think that a bunch of the IDL predates talk about records for individual copies, and should be cleaned up 2008-03-03T15:34:27 define "records" 2008-03-03T15:35:15 the line item details records: fund codes & locations, for individual copies when purchasing multiples 2008-03-03T15:35:38 ok 2008-03-03T15:35:59 right now there's a chain: picklist entry -> line item [summary] -> list of detail records. 2008-03-03T15:36:26 getting rid of the line item summary record and just tying the detail records to the bib data will simplify a bunch, I think 2008-03-03T15:37:31 one of the issues with tying to bib data (say, linking to the picklist_entry) is the requirement that the picklist entry stick around after the user wants to delete it 2008-03-03T15:38:36 the po_lineitem, with its copy of the marc, is meant to solve that problem 2008-03-03T15:39:27 hmmm 2008-03-03T15:40:00 still reading yr email.. 2008-03-03T15:40:26 In my dream workflow, users only delete picklist entries before they have PO data associated with them, since delete means "do not want" 2008-03-03T15:41:12 after a user has marked an item as "approved/please purchase", the bib record definitely shouldn't disappear 2008-03-03T15:41:29 at least, not until there's a bib record in the cat. that can we can point to. 2008-03-03T15:43:08 djfiander: just so i'm clear, in your scenario, the picklist_entry and lineitem are essentially one in the same? once approved for purchase, a picklist_entry elevates to a po_lineitem? 2008-03-03T15:44:09 or, no, make picklist_entries smarter, and just elimiate po_lineitems 2008-03-03T15:44:18 yes, that latter. 2008-03-03T15:44:46 some po_lineitem stuff moves into the picklist, and some moves into the lineitem-details, and cut out the middle. 2008-03-03T15:45:29 djfiander: did you see my response? 2008-03-03T15:45:29 then a PO is a long list of lineitem-details, without the po_lineitems. 2008-03-03T15:45:29 anyway, I have to run to a dr appointment 2008-03-03T15:45:31 so ... don't go changing everything just yet :) 2008-03-03T15:45:34 when we display or print, the system rolls up the details and prints summary data as appropriate. 2008-03-03T15:46:11 you did not see my response ... because I failed to hit send 2008-03-03T15:46:15 sent now, biab 2008-03-03T15:46:25 miker_: that would explain that ;-) 2008-03-03T15:48:50 some of miker_'s response fits in with my thinking, and some doesn't 2008-03-03T15:49:13 For the first part, I'm talking about what a librarian does, or wants to do, rather than system objects. 2008-03-03T15:49:55 When I'm ordering books, sometimes (most of the time) I know the provider, but sometimes I don't and I leave that to the processing staff to figure out 2008-03-03T15:50:14 right, that makes sense 2008-03-03T15:50:53 but when I'm working on selecting, I will be deciding how many copies to order, prior to handoff. and I may or may not know the prices 2008-03-03T15:51:22 mostly I'll know the prices, but if I don't know the vendor, I may not even be able to guess at price, especially for out of print titles 2008-03-03T15:52:16 I think one of my big concerns, once I started with the workflow, was the way the current system _seems_ to convert picklists to POs. 2008-03-03T15:52:51 but with 20 librarians all making selections in a given week, and most of those orders coming from the same vendor, stuff must be merged in the back office. 2008-03-03T15:53:06 processing staff don't care about picklists, they care about items/copies 2008-03-03T15:53:21 and once the order has been placed, it's the copies that we need to track. 2008-03-03T15:54:45 well, except for the librarians that are anxious and go back to review old picklists... 2008-03-03T15:54:50 djfiander: would it make more sense if items selected from a picklist (or a whole picklist) were pushed into a staging area (the handoff), instead of going directly from picklist to PO? 2008-03-03T15:56:10 berick: yes. that's pretty much how I work now, except he picklist is managed by my vendor and then all approved items are d/l'd by processing weekly. 2008-03-03T15:56:20 and it's also how the workflow we saw in the conf call works. 2008-03-03T15:56:26 right 2008-03-03T15:57:46 I've also had some thoughts about the branch ordering scenario. It may be the case that we want to be able to share picklist entries between picklists. 2008-03-03T15:58:22 imagine two different branches that want to order an item. we don't want to have two picklist entries with associated detail records... or do we? 2008-03-03T15:59:05 given enough smarts, the PO stuff could aggregate detail/copy records regardless, but that would probably be harder than libn's adding copies to an existing picklist entry 2008-03-03T16:02:08 i don't see any particular problem with have duplicate picklist entries 2008-03-03T16:02:28 ok 2008-03-03T16:03:18 I think that the question about the bib data boils down to different views of the model again. 2008-03-03T16:03:59 what we're calling picklist entries are really just jacked-up bib records. until they're approved, they're disposable. 2008-03-03T16:04:12 yep 2008-03-03T16:04:37 after they're approved, they're semi-permanent, until there's a cat bib record at least. 2008-03-03T16:04:38 ephemeral even? 2008-03-03T16:04:55 they're disposable as soon as a po_lineitem is created 2008-03-03T16:05:11 berick: except we're not doing that any more ;-) 2008-03-03T16:05:38 ok, you're talking "ideally" 2008-03-03T16:05:41 I mean that the jacked-up bib record we start with is the One True Copy, if we care, and disposable if we don't 2008-03-03T16:05:59 oh, hey, dbs ;) 2008-03-03T16:06:25 for example, the Comp Sci lists that I get from my vendor contain all sorts of crap 2008-03-03T16:06:44 djfiander: if we have one copy of a bib record, are you proposing that people search through picklist entries (anonymously) to find items they want to order? 2008-03-03T16:06:45 if we were using eg-acq, then I'd be leaning on the delete key as I went through the list. 2008-03-03T16:07:14 berick: that goes back to your statement about "not caring if we have multiple picklist entries" 2008-03-03T16:07:21 ok 2008-03-03T16:07:44 if a book appears on my list that I got from my vendor, and it also appears on your list that you got by downloading the latest reviews from Library Journal... 2008-03-03T16:08:01 do we consolidate those or not? I'm leaning more and more to "not"... 2008-03-03T16:08:20 right, for simplicity, let's assume that's the case for now -- ok, on the same page ;) 2008-03-03T16:08:53 but it would also be nice if I could see that Jane's ordered a copy of Harry Potter and the Ass Pirates and just add another copy for my branch. 2008-03-03T16:09:08 * berick chuckles 2008-03-03T16:09:11 * djfiander really needs to stop surfing the slash sites 2008-03-03T16:09:37 -= THIS MESSAGE NOT LOGGED =- 2008-03-03T16:10:07 assuming that things are set up so you can see that order (granted permissions by Jane, or whatever) 2008-03-03T16:10:51 dbs: right. but again, there's interface and workflow issues surrounding some of this stuff. 2008-03-03T16:10:56 djfiander: also, are you imagining free-floating pl_entries, that can live in more than one picklist ? 2008-03-03T16:11:07 more like bookbags 2008-03-03T16:11:08 that's definitely not how we operate - selections are very much the domain of the individual collection librarian 2008-03-03T16:12:04 berick: that's somewhat implied by some of the stuff I've said, but I'm not committed to it... 2008-03-03T16:12:35 before I ask for something to be ordered, I do a quickie search on ISBN and title (in case, say, the person responsible for Psychology has already ordered something that I want for Sport Psychology) 2008-03-03T16:12:52 dbs: you mean in your local catalog? or ACQ system? 2008-03-03T16:12:54 we either have to have pl_entries in multiple lists, or I think the interface needs to automagically create a new pl_entry when I say "add this to my list" 2008-03-03T16:13:34 berick: that's another question... when I'm going through the "new releases" list from the vendor, I'm checking the acq system... 2008-03-03T16:13:53 when I'm dealing with a user request to purchase something on the backlist, I check the cat. 2008-03-03T16:13:55 berick: in both, actually (if you call our vendor's interface the acq system, because I have nothing to do with unicorn's acq interface) 2008-03-03T16:14:03 what dbs said 2008-03-03T16:14:19 "vendor = acq system" for us 2008-03-03T16:15:16 and in that system you can tell if a particular item has already been purchased or approved for you institution, regardless of who selected/purchased/approved the item? 2008-03-03T16:15:24 so a nice little hook that checks the catalog and on-order items would be appreciated :) 2008-03-03T16:15:34 berick: in our case, yes 2008-03-03T16:15:35 berick: yes, roughly 2008-03-03T16:15:55 it's a bit more complicated, but not really, since we use a couple of different vendors. 2008-03-03T16:16:10 I can tell if an order has been placed with the vendor - theoretically it might not be approved, but that would be amazingly unlikely 2008-03-03T16:16:18 makes sense .. and i think that's doable with what we have now, fwiw 2008-03-03T16:16:25 if you'd like to set up a webcast, I could show you what my vendor workflow looks like, in a couple of days 2008-03-03T16:16:56 djfiander: sure 2008-03-03T16:17:16 just to duplicate work, our head of acquisitions will check 1) whether there are funds left for that fund/budget and 2) whether we already have a copy on order before the order is approved 2008-03-03T16:18:50 for things that don't go through the vendor process I use, the older "manual" way, our acq staff checks for dup orders 2008-03-03T16:21:08 the "free float pl_entry" idea makes it simpler to manage the pool of approved items, I think 2008-03-03T16:21:46 it would make removing po_lineitems more do-able as well, i think 2008-03-03T16:21:48 oh, and just fyi, the cat at MPOW is spending a great deal of time informing our users that too many people are logged in and denying them access. 2008-03-03T16:22:22 i'll make sure and add that feature as well 2008-03-03T16:22:24 djfiander: you need to buy more magic cat slots, obviously 2008-03-03T16:22:44 * dbs thinks of american psycho and giggles 2008-03-03T16:22:44 dbs: we keep hitting the concurrent use limit on our own data 2008-03-03T16:23:22 in practice, there are, apparently, ways to get unlimited web access. this is an artifact of a runaway process, I've been told. 2008-03-03T16:24:25 ok, I think that's it for me for now. 2008-03-03T16:24:31 djfiander:one more question.. 2008-03-03T16:24:36 hit me 2008-03-03T16:25:17 as far as 'removing po_lineitems' goes.. if a libn' chooses a pl_entry and says "I want 5 of these", but they are approved yet, where should that "5" live? 2008-03-03T16:25:21 if not a po_lineitem 2008-03-03T16:25:30 some other pre-po_lineitem object of some sort? 2008-03-03T16:25:42 s/are approved/are not approved/ 2008-03-03T16:25:52 no, I'm assuming a bunch of magic on the part of the interface to handle the detail records. 2008-03-03T16:26:17 when Jane says, "5 please", then 5 detail records are created and attached to the jacked-up bib. 2008-03-03T16:27:06 if she changes her mind and deletes the pl_entry before approval, then the detail records just go "poof" 2008-03-03T16:27:15 I'm all about the magic in the computer 2008-03-03T16:27:34 the details point to the pl_entry for the bib data, but how do we know they are a group of 5 to be ordered together? i can still see the use of some preliminary object of some sort 2008-03-03T16:27:36 if the 5 recs are all identical, then changing from 5 to 3 copies is easy 2008-03-03T16:28:19 because the pl_entry still points to the list of detail records? 2008-03-03T16:28:44 I think that the primary way to find the detail records will still be via the pl_entry 2008-03-03T16:28:58 mostly we will go from pl_entry to order details, not the other way around 2008-03-03T16:29:01 I think. 2008-03-03T16:31:18 but, the physical link would exist as a pointer from the detail object to the pl_entry object, right? 2008-03-03T16:31:32 it would probably have to be double-linked. 2008-03-03T16:31:38 detail has a pointer to pl_entry 2008-03-03T16:31:46 pl_entry has a list of details. 2008-03-03T16:32:19 (I'm thinking in data structure terms, not DB terms) 2008-03-03T16:32:25 ok 2008-03-03T16:32:51 right, if we have the former (in db terms) the latter is easily obtained 2008-03-03T16:32:54 in the interface Jane sees a collection of bib records and opens one up to see the order detail records 2008-03-03T16:33:32 hmm... 2008-03-03T16:34:33 having multiple libn's adding detail records (ie copy orders) to a single jacked-up bib (JUB) means that Jane can't delete a JUB unless she owns all the copy requests under it. 2008-03-03T16:34:46 this is all so complicated!!! 2008-03-03T16:35:02 but she could "delete" it ;) i.e. it vanishes from her picklist(s) 2008-03-03T16:35:25 berick: and the detail records she owns all disappear. that would be cool. 2008-03-03T16:35:44 assuming the interface and workflow issues are all addressed 2008-03-03T16:35:51 I guess I need to start working on that, eh? ;-) 2008-03-03T16:36:04 ok, I've gotta head oot. 2008-03-03T16:36:09 assuming that once an item is actually ordered, the detail records never go away, correct? 2008-03-03T16:36:12 ok 2008-03-03T16:36:14 later 2008-03-03T16:36:15 I'll be back this evening. email more. 2008-03-03T16:36:18 cool 2008-03-03T16:36:33 yes, detail records and corresponing bib data never go away after approval 2008-03-03T16:36:39 *** djfiander has quit IRC 2008-03-03T16:53:11 hey, the GSoC host organization page is finally up 2008-03-03T16:56:38 hurrah! 2008-03-03T16:56:52 Gotta run, but let's talk later (if you're around) - or I'll send an email 2008-03-03T16:56:59 *** dbs has quit IRC 2008-03-03T17:26:03 ok ... djfiander is confusing things, I think 2008-03-03T17:28:18 I'm trying really hard to understand how po_lineitems-as-permenant-records are not as good as pl_entries-as-permenant-records 2008-03-03T17:28:48 when the PL can sometimes maybe go away, but only if things weren't ordered because then it's permenant... 2008-03-03T17:29:13 berick: if you can explain that, it'd be great 2008-03-03T17:31:32 miker_: i (personally) think the problem is more about how the po_lineitems are created than the fact that they exist. right now, there's no way to say "i want 5 of these" without creating a purchase order. 2008-03-03T17:32:05 seems like we need an intermediary step fo some sort 2008-03-03T17:32:09 that's what the po-state was for, I thought 2008-03-03T17:32:50 well, djfiander is worried about "I don't knw the vendor" 2008-03-03T17:33:07 i'm thinking of the case where you have 2 staff who have a approved a batch of items for purchase. the actual purchaser then creates a PO for the batch (assuming 1 vendor) 2008-03-03T17:33:19 so, a pl status flag (or multi-state field, like on POs) should address that, no? 2008-03-03T17:34:40 and, again, we can use 'user generated' attributes on both pl entries and po lineitems ... they don't get wiped at record update, IIRC 2008-03-03T17:36:40 there's the other issue of not requiring staff to purchase an entire picklist. I want these 3 items, and I want 2 of each from this picklist --> those go into some place for the handoff --> then the PO is created with those and potentially other items (just thinking out loud) 2008-03-03T17:38:17 what's the purpose of the PL status? 2008-03-03T17:38:52 don't you just add them to one pl and mark it as "order this"? 2008-03-03T17:39:24 the purpose is to hand off pls instead of POs 2008-03-03T17:40:13 "private/mine" vs "handed off to the next guy" 2008-03-03T17:41:05 which means OU owners instead of user owners 2008-03-03T17:41:41 how do you indicate how many copies you want when you hand off the picklist? 2008-03-03T17:47:44 in my mind, i'm picturing a staging area of "pending" orders consisting of pl_entries (from various picklists) and item counts and whatever info is available at the time. the purchaser goes through these and creates POs. 2008-03-03T17:47:59 and adds any missing pieces 2008-03-03T17:49:39 i also like the idea of being able to order a given pl_entry more than once .. re: pl_entry -> po_lineitem (or whatever) mapping table 2008-03-03T17:50:17 re "how do you indicate how many copies you want when you hand off the picklist?" with a well-known, user-generated acq.picklist_entry_attr row having a name of count and a type of 'user' 2008-03-03T17:52:26 ok, i guess that's approaching what djf was calling a smarter (more like a po_lineitem) pl_entry 2008-03-03T17:53:12 I'm not arguing against a pre-PO pl_entry "staging area", but I don't see how that's different from "just another picklist, with a status of 'approved'" 2008-03-03T17:53:22 and some extra attributes on entries 2008-03-03T17:54:55 I know I didn't explain all the parts of the data model while djf and dbs where down here, and I guess this is my punishment -- djf is reinventing what he doesn't know exists (but for which there's not yet an ML api) 2008-03-03T17:55:10 he seems to think that the ML api is complete, though, which surprised me... 2008-03-03T17:55:21 anyway, I have to go feed A ... biab 2008-03-03T17:56:06 right, the pre-PO pl_entry wouldn't be much different and I'm not sure it's necessary. maybe it's just a case of how its presented to the user 2008-03-03T17:56:36 i do think if we're going to be storing item counts on pl_entry's though, we may as well make them a column 2008-03-03T17:56:57 yeah, i'll poke djf about the ML issue in his email 2008-03-03T17:58:10 do we need another nullable column? it doesn't need to be searchable, so my inclination is to just use an attr if it has to be user supplied in any case 2008-03-03T18:00:12 eh, either way is fine, really. it just seemed like a core part of the object 2008-03-03T18:02:35 *** Karen_ has left #OpenILS-Evergreen 2008-03-03T18:04:22 *** greg-g has joined #openils-evergreen 2008-03-03T18:11:53 for POs, I agree ... but I'm not convinced on pl entries 2008-03-03T18:42:22 *** sarabee has quit IRC 2008-03-03T18:46:29 *** sarabee has joined #openils-evergreen 2008-03-03T19:12:58 *** djfiander has joined #OpenILS-Evergreen 2008-03-03T20:39:19 *** sarabee has quit IRC 2008-03-03T20:40:32 *** dbs has joined #OpenILS-Evergreen 2008-03-03T20:41:18 *** sarabee has joined #openils-evergreen 2008-03-03T20:46:20 *** phase_bb has quit IRC 2008-03-03T21:03:35 flickr as virtual whiteboard. 2008-03-03T21:40:18 *** djfiander has quit IRC