| # | Time | Nick | Message |
|---|
| # | 00:51:10 | greg-g has quit IRC |
| # | 02:16:46 | Mark__T has joined #openils-evergreen |
| # | 08:51:03 | dbs has joined #OpenILS-Evergreen |
| # | 08:55:20 | dbs | 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. |
| # | 08:56:58 | dbs | I'll need to, at least, add a test for the existence of the file and bail with an appropriate error message |
| # | 09:00:42 | miker_ | dbs: when was this? |
| # | 09:04:13 | dbs | about 10 hours ago |
| # | 09:04:49 | dbs | I've got the defensive programming bit working now, will check that in |
| # | 09:05:39 | dbs | After that, I could add checks for file ownership & visibility |
| # | 09:07:50 | dbs | okay, checked in |
| # | 09:08:58 | dbs | miker_: btw - SRU! SRU! |
| # | 09:10:46 | miker_ | yeah |
| # | 09:11:27 | miker_ | a couple things are still broken, but it's getting there |
| # | 09:12:42 | dbs | 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 |
| # | 09:13:29 | miker_ | yeah, I'm not crazy about that ... /etc/opensrf_core.xml is a likely location down the road |
| # | 09:13:33 | dbs | 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 |
| # | 09:13:50 | miker_ | the whole 'conf' thing bugs me... |
| # | 09:14:02 | dbs | 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. |
| # | 09:14:49 | dbs | 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 |
| # | 09:14:57 | miker_ | I'm not talking about FHS, just "put stuff in a more standard location" ... and I really only care about opensrf for that |
| # | 09:15:34 | miker_ | maybe that explains berick and me (3.5yr) |
| # | 09:15:38 | dbs | heh |
| # | 09:16:35 | berick | heh |
| # | 09:16:39 | miker_ | and autotools should take care of most of the fhs pain anyway |
| # | 09:16:55 | miker_ | --prefix, --bindir, etc |
| # | 09:17:11 | miker_ coughs in asmodai's general direction ;) |
| # | 09:19:01 | rsinger has joined #OpenILS-Evergreen |
| # | 09:19:33 | miker_ | rsinger: have you come to beat me about the head and neck, sir? |
| # | 09:19:36 | dbs | miker_: true that - while we wait for that, though, I'll be happy to save my fingers the minor strain |
| # | 09:20:07 | rsinger | miker_: nossir, i thought that was a good post |
| # | 09:20:09 | dbs | oh, and for Google Summer of Code - how about pointing a student at an updated version of the FIT proposal? |
| # | 09:20:17 | rsinger | miker_: i plan on responding to it today |
| # | 09:20:21 | miker_ | ha ... well, if you're going back in there, would you mind putting a big '#XXX miker hates this' next to it? |
| # | 09:20:46 | dbs | miker_: wasn't the FIT proposal yours? |
| # | 09:21:20 | miker_ | dbs: parts of it. it was an amalgamation[sic] of ideas |
| # | 09:21:58 | miker_ | but FIT was about having an installation tracking system ... if that existed then I wouldn't care where anything live! ;) |
| # | 09:24:07 | rsinger | miker_: i have a meeting with aquabrowser and bibliocommons next week -- i'll pitch the opensrf idea to them, as well |
| # | 09:24:25 | miker_ | rsinger: what are you buttering me up for?!?! |
| # | 09:24:43 | miker_ | rsinger: if you'll be talking to taco, say hi for berick and I |
| # | 09:25:10 | dbs | 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)" |
| # | 09:25:13 | rsinger | miker_: well, we want to avoid any players thinking this is an 'evergreen based app' |
| # | 09:25:26 | miker_ | ahh... righto |
| # | 09:25:27 | rsinger | miker_: i figure they'd be good candidates to gauge perception |
| # | 09:25:45 | dbs | 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 |
| # | 09:25:46 | miker_ | rsinger: forget you know me, then :) |
| # | 09:25:55 | rsinger | miker_: :) |
| # | 09:26:20 | miker_ | dbs: I like the GSoC idea |
| # | 09:26:27 | rsinger | miker_: i'm still leaning towards opensrf, personally, if just for the 'hitting the ground running' aspect |
| # | 09:26:58 | rsinger | miker_: but i still have to reconcile the perception |
| # | 09:27:15 | berick | dbs: yeah, that seems like a good tidy gsoc project |
| # | 09:27:29 | miker_ | rsinger: the evergreen perception? |
| # | 09:27:35 | rsinger | miker_: yeah |
| # | 09:27:43 | rsinger | i mean, to the community |
| # | 09:27:47 | rsinger | not to myself |
| # | 09:28:15 | rsinger | miker_: is anybody from ESI going to the dlf meeting on thursday? |
| # | 09:29:21 | miker_ | rsinger: no sir ... I don't believe we got an invite, nor did we (well, I) know about it other than extremely vaugely |
| # | 09:29:49 | rsinger | miker_: i'm trying to weasel out of going (i don't really want to fly back across the country this week) |
| # | 09:29:49 | dbs | 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/<barcode> (if authenticated over HTTPS) |
| # | 09:30:16 | miker_ | dbs: opensrf over http isn't meant to be restful, but the gateway sorta/kinda is |
| # | 09:30:35 | rsinger | miker_: jangle seemed to be pretty well received at c4l |
| # | 09:30:50 | rsinger | miker_: casey bisson seemed to want it for scriblio, at least |
| # | 09:30:54 | dbs | miker_: okay - I thought I might be tilting at the wrong windmill |
| # | 09:31:07 | dbs agrees with rsinger - reception was goot |
| # | 09:31:09 | miker_ | dbs: don't we all? |
| # | 09:31:39 | miker_ | rsinger: that's the feeling I got from berick, which is really good! |
| # | 09:32:21 | rsinger | miker_: i can't tell if the dlf folks got that we weren't trying to step on their toes... |
| # | 09:32:38 | rsinger | miker_: xc seemed partially interested, but wary of sharing connectors |
| # | 09:33:13 | miker_ | wow, really? wary of sharing connectors why? |
| # | 09:33:21 | dbs | that seems -- dumb |
| # | 09:33:24 | rsinger | well, this was over being taken to dinner by talis |
| # | 09:33:29 | rsinger | so... |
| # | 09:33:43 | dbs | oh. because talis would benefit? |
| # | 09:33:48 | miker_ | oh, so it may have just been a EvilVendor thing |
| # | 09:33:53 | rsinger | jangle as jangle hadn't been established |
| # | 09:33:58 | rsinger | miker_: right |
| # | 09:34:02 | dbs | (never mind that the rest of the library world would benefit) |
| # | 09:34:30 | miker_ | dbs: right :) "We'll open source it, but only if no vendors are involved." |
| # | 09:35:20 | rsinger | well, it was the partnering i think they were less keen on |
| # | 09:36:05 | rsinger | like i said, it probably came across (on tuesday night) like we were trying to coopt the dlf initiative |
| # | 09:37:46 | miker_ | honestly, I've felt that way before with m5rob and rjw ... but now I understand their plight, and hold them no ill will ;) |
| # | 09:38:01 | miker_ | dbs: did you see a working SRU link yet? |
| # | 09:38:11 | dbs | miker_: haven't installed yet, so no |
| # | 09:38:21 | miker_ | 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 |
| # | 09:38:50 | rsinger chuckles. |
| # | 09:38:56 | miker_ | need to move the context set map into the db and build explain and diag messages |
| # | 09:39:03 | dbs | 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 |
| # | 09:39:06 | miker_ | and a couple other things, but it's close |
| # | 09:39:47 | miker_ | didn't talis dump a huge pile of records on openlib? |
| # | 09:40:07 | dbs | yes they did |
| # | 09:40:38 | dbs | I was talking more about holdings data, and reviews, and comments, and tags, and circ data... |
| # | 09:40:46 | miker_ | ahh |
| # | 09:41:02 | miker_ | see, not being there I made a bad assumption :( |
| # | 09:42:40 | dbs | 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 |
| # | 09:43:06 | dbs | but to push back new stuff contributed at your site |
| # | 09:43:21 | dbs | of course it would be relatively easy to poison the well |
| # | 09:43:23 | dbs | <-- naive |
| # | 09:43:29 | dbs | <-- going to get coffee |
| # | 09:43:47 | Karen_ has joined #OpenILS-Evergreen |
| # | 09:47:31 | djfiander has joined #OpenILS-Evergreen |
| # | 10:23:06 | Mark__T has quit IRC |
| # | 10:41:30 | jbfink_ has quit IRC |
| # | 10:57:51 | JMCraig has joined #openils-evergreen |
| # | 11:14:43 | agJohn has quit IRC |
| # | 11:35:00 | djfiander | if it weren't for connection problems, _nothing_ would happen in here |
| # | 11:43:26 | berick | djfiander: i'm in today, if you have time to talk acq |
| # | 11:44:28 | djfiander | berick: thanks. probably later this afternoon I can carve out some time |
| # | 11:44:35 | berick | k |
| # | 11:52:59 | dmcmorris_esi has left #OpenILS-Evergreen |
| # | 11:53:32 | dmcmorris_esi has joined #Openils-Evergreen |
| # | 12:50:48 | sarabee has quit IRC |
| # | 12:50:48 | gmcharlt has quit IRC |
| # | 12:50:48 | pmurray_away has quit IRC |
| # | 12:51:15 | sarabee has joined #openils-evergreen |
| # | 12:51:15 | gmcharlt has joined #openils-evergreen |
| # | 12:51:15 | pmurray_away has joined #openils-evergreen |
| # | 15:30:42 | djfiander | berick? |
| # | 15:31:36 | berick | yo |
| # | 15:31:43 | djfiander | so, can we talk? |
| # | 15:31:54 | berick | djfiander: we can |
| # | 15:32:09 | djfiander | did my long rambling email of last night make sense? |
| # | 15:32:59 | berick | no, cuz i haven't read it yet ;) but i can right now |
| # | 15:33:04 | djfiander | heh |
| # | 15:33:18 | djfiander | glad to see the bad field thing is fixed. |
| # | 15:34:00 | djfiander | short version: I think that a bunch of the IDL predates talk about records for individual copies, and should be cleaned up |
| # | 15:34:27 | berick | define "records" |
| # | 15:35:15 | djfiander | the line item details records: fund codes & locations, for individual copies when purchasing multiples |
| # | 15:35:38 | berick | ok |
| # | 15:35:59 | djfiander | right now there's a chain: picklist entry -> line item [summary] -> list of detail records. |
| # | 15:36:26 | djfiander | getting rid of the line item summary record and just tying the detail records to the bib data will simplify a bunch, I think |
| # | 15:37:31 | berick | 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 |
| # | 15:38:36 | berick | the po_lineitem, with its copy of the marc, is meant to solve that problem |
| # | 15:39:27 | djfiander | hmmm |
| # | 15:40:00 | berick | still reading yr email.. |
| # | 15:40:26 | djfiander | In my dream workflow, users only delete picklist entries before they have PO data associated with them, since delete means "do not want" |
| # | 15:41:12 | djfiander | after a user has marked an item as "approved/please purchase", the bib record definitely shouldn't disappear |
| # | 15:41:29 | djfiander | at least, not until there's a bib record in the cat. that can we can point to. |
| # | 15:43:08 | berick | 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? |
| # | 15:44:09 | berick | or, no, make picklist_entries smarter, and just elimiate po_lineitems |
| # | 15:44:18 | djfiander | yes, that latter. |
| # | 15:44:46 | djfiander | some po_lineitem stuff moves into the picklist, and some moves into the lineitem-details, and cut out the middle. |
| # | 15:45:29 | miker_ | djfiander: did you see my response? |
| # | 15:45:29 | djfiander | then a PO is a long list of lineitem-details, without the po_lineitems. |
| # | 15:45:29 | miker_ | anyway, I have to run to a dr appointment |
| # | 15:45:31 | miker_ | so ... don't go changing everything just yet :) |
| # | 15:45:34 | djfiander | when we display or print, the system rolls up the details and prints summary data as appropriate. |
| # | 15:46:11 | miker_ | you did not see my response ... because I failed to hit send |
| # | 15:46:15 | miker_ | sent now, biab |
| # | 15:46:25 | djfiander | miker_: that would explain that ;-) |
| # | 15:48:50 | djfiander | some of miker_'s response fits in with my thinking, and some doesn't |
| # | 15:49:13 | djfiander | For the first part, I'm talking about what a librarian does, or wants to do, rather than system objects. |
| # | 15:49:55 | djfiander | 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 |
| # | 15:50:14 | berick | right, that makes sense |
| # | 15:50:53 | djfiander | 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 |
| # | 15:51:22 | djfiander | 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 |
| # | 15:52:16 | djfiander | 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. |
| # | 15:52:51 | djfiander | 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. |
| # | 15:53:06 | djfiander | processing staff don't care about picklists, they care about items/copies |
| # | 15:53:21 | djfiander | and once the order has been placed, it's the copies that we need to track. |
| # | 15:54:45 | djfiander | well, except for the librarians that are anxious and go back to review old picklists... |
| # | 15:54:50 | berick | 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? |
| # | 15:56:10 | djfiander | 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. |
| # | 15:56:20 | djfiander | and it's also how the workflow we saw in the conf call works. |
| # | 15:56:26 | berick | right |
| # | 15:57:46 | djfiander | 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. |
| # | 15:58:22 | djfiander | 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? |
| # | 15:59:05 | djfiander | 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 |
| # | 16:02:08 | berick | i don't see any particular problem with have duplicate picklist entries |
| # | 16:02:28 | djfiander | ok |
| # | 16:03:18 | djfiander | I think that the question about the bib data boils down to different views of the model again. |
| # | 16:03:59 | djfiander | what we're calling picklist entries are really just jacked-up bib records. until they're approved, they're disposable. |
| # | 16:04:12 | berick | yep |
| # | 16:04:37 | djfiander | after they're approved, they're semi-permanent, until there's a cat bib record at least. |
| # | 16:04:38 | dbs | ephemeral even? |
| # | 16:04:55 | berick | they're disposable as soon as a po_lineitem is created |
| # | 16:05:11 | djfiander | berick: except we're not doing that any more ;-) |
| # | 16:05:38 | berick | ok, you're talking "ideally" |
| # | 16:05:41 | djfiander | 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 |
| # | 16:05:59 | berick | oh, hey, dbs ;) |
| # | 16:06:25 | djfiander | for example, the Comp Sci lists that I get from my vendor contain all sorts of crap |
| # | 16:06:44 | berick | 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? |
| # | 16:06:45 | djfiander | if we were using eg-acq, then I'd be leaning on the delete key as I went through the list. |
| # | 16:07:14 | djfiander | berick: that goes back to your statement about "not caring if we have multiple picklist entries" |
| # | 16:07:21 | berick | ok |
| # | 16:07:44 | djfiander | 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... |
| # | 16:08:01 | djfiander | do we consolidate those or not? I'm leaning more and more to "not"... |
| # | 16:08:20 | berick | right, for simplicity, let's assume that's the case for now -- ok, on the same page ;) |
| # | 16:08:53 | djfiander | 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. |
| # | 16:09:08 | berick chuckles |
| # | 16:09:11 | djfiander really needs to stop surfing the slash sites |
| # | 16:09:37 | djfiander | -= THIS MESSAGE NOT LOGGED =- |
| # | 16:10:07 | dbs | assuming that things are set up so you can see that order (granted permissions by Jane, or whatever) |
| # | 16:10:51 | djfiander | dbs: right. but again, there's interface and workflow issues surrounding some of this stuff. |
| # | 16:10:56 | berick | djfiander: also, are you imagining free-floating pl_entries, that can live in more than one picklist ? |
| # | 16:11:07 | berick | more like bookbags |
| # | 16:11:08 | dbs | that's definitely not how we operate - selections are very much the domain of the individual collection librarian |
| # | 16:12:04 | djfiander | berick: that's somewhat implied by some of the stuff I've said, but I'm not committed to it... |
| # | 16:12:35 | dbs | 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) |
| # | 16:12:52 | berick | dbs: you mean in your local catalog? or ACQ system? |
| # | 16:12:54 | djfiander | 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" |
| # | 16:13:34 | djfiander | berick: that's another question... when I'm going through the "new releases" list from the vendor, I'm checking the acq system... |
| # | 16:13:53 | djfiander | when I'm dealing with a user request to purchase something on the backlist, I check the cat. |
| # | 16:13:55 | dbs | 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) |
| # | 16:14:03 | djfiander | what dbs said |
| # | 16:14:19 | djfiander | "vendor = acq system" for us |
| # | 16:15:16 | berick | 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? |
| # | 16:15:24 | dbs | so a nice little hook that checks the catalog and on-order items would be appreciated :) |
| # | 16:15:34 | dbs | berick: in our case, yes |
| # | 16:15:35 | djfiander | berick: yes, roughly |
| # | 16:15:55 | djfiander | it's a bit more complicated, but not really, since we use a couple of different vendors. |
| # | 16:16:10 | dbs | I can tell if an order has been placed with the vendor - theoretically it might not be approved, but that would be amazingly unlikely |
| # | 16:16:18 | berick | makes sense .. and i think that's doable with what we have now, fwiw |
| # | 16:16:25 | djfiander | if you'd like to set up a webcast, I could show you what my vendor workflow looks like, in a couple of days |
| # | 16:16:56 | berick | djfiander: sure |
| # | 16:17:16 | dbs | 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 |
| # | 16:18:50 | djfiander | for things that don't go through the vendor process I use, the older "manual" way, our acq staff checks for dup orders |
| # | 16:21:08 | djfiander | the "free float pl_entry" idea makes it simpler to manage the pool of approved items, I think |
| # | 16:21:46 | berick | it would make removing po_lineitems more do-able as well, i think |
| # | 16:21:48 | djfiander | 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. |
| # | 16:22:22 | berick | i'll make sure and add that feature as well |
| # | 16:22:24 | dbs | djfiander: you need to buy more magic cat slots, obviously |
| # | 16:22:44 | dbs thinks of american psycho and giggles |
| # | 16:22:44 | djfiander | dbs: we keep hitting the concurrent use limit on our own data |
| # | 16:23:22 | djfiander | in practice, there are, apparently, ways to get unlimited web access. this is an artifact of a runaway process, I've been told. |
| # | 16:24:25 | djfiander | ok, I think that's it for me for now. |
| # | 16:24:31 | berick | djfiander:one more question.. |
| # | 16:24:36 | djfiander | hit me |
| # | 16:25:17 | berick | 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? |
| # | 16:25:21 | berick | if not a po_lineitem |
| # | 16:25:30 | berick | some other pre-po_lineitem object of some sort? |
| # | 16:25:42 | berick | s/are approved/are not approved/ |
| # | 16:25:52 | djfiander | no, I'm assuming a bunch of magic on the part of the interface to handle the detail records. |
| # | 16:26:17 | djfiander | when Jane says, "5 please", then 5 detail records are created and attached to the jacked-up bib. |
| # | 16:27:06 | djfiander | if she changes her mind and deletes the pl_entry before approval, then the detail records just go "poof" |
| # | 16:27:15 | djfiander | I'm all about the magic in the computer |
| # | 16:27:34 | berick | 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 |
| # | 16:27:36 | djfiander | if the 5 recs are all identical, then changing from 5 to 3 copies is easy |
| # | 16:28:19 | djfiander | because the pl_entry still points to the list of detail records? |
| # | 16:28:44 | djfiander | I think that the primary way to find the detail records will still be via the pl_entry |
| # | 16:28:58 | djfiander | mostly we will go from pl_entry to order details, not the other way around |
| # | 16:29:01 | djfiander | I think. |
| # | 16:31:18 | berick | but, the physical link would exist as a pointer from the detail object to the pl_entry object, right? |
| # | 16:31:32 | djfiander | it would probably have to be double-linked. |
| # | 16:31:38 | djfiander | detail has a pointer to pl_entry |
| # | 16:31:46 | djfiander | pl_entry has a list of details. |
| # | 16:32:19 | djfiander | (I'm thinking in data structure terms, not DB terms) |
| # | 16:32:25 | berick | ok |
| # | 16:32:51 | berick | right, if we have the former (in db terms) the latter is easily obtained |
| # | 16:32:54 | djfiander | in the interface Jane sees a collection of bib records and opens one up to see the order detail records |
| # | 16:33:32 | djfiander | hmm... |
| # | 16:34:33 | djfiander | 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. |
| # | 16:34:46 | djfiander | this is all so complicated!!! </whine> |
| # | 16:35:02 | berick | but she could "delete" it ;) i.e. it vanishes from her picklist(s) |
| # | 16:35:25 | djfiander | berick: and the detail records she owns all disappear. that would be cool. |
| # | 16:35:44 | djfiander | assuming the interface and workflow issues are all addressed |
| # | 16:35:51 | djfiander | I guess I need to start working on that, eh? ;-) |
| # | 16:36:04 | djfiander | ok, I've gotta head oot. |
| # | 16:36:09 | berick | assuming that once an item is actually ordered, the detail records never go away, correct? |
| # | 16:36:12 | berick | ok |
| # | 16:36:14 | berick | later |
| # | 16:36:15 | djfiander | I'll be back this evening. email more. |
| # | 16:36:18 | berick | cool |
| # | 16:36:33 | djfiander | yes, detail records and corresponing bib data never go away after approval |
| # | 16:36:39 | djfiander has quit IRC |
| # | 16:53:11 | berick | hey, the GSoC host organization page is finally up |
| # | 16:56:38 | dbs | hurrah! |
| # | 16:56:52 | dbs | Gotta run, but let's talk later (if you're around) - or I'll send an email |
| # | 16:56:59 | dbs has quit IRC |
| # | 17:26:03 | miker_ | ok ... djfiander is confusing things, I think |
| # | 17:28:18 | miker_ | I'm trying really hard to understand how po_lineitems-as-permenant-records are not as good as pl_entries-as-permenant-records |
| # | 17:28:48 | miker_ | when the PL can sometimes maybe go away, but only if things weren't ordered because then it's permenant... |
| # | 17:29:13 | miker_ | berick: if you can explain that, it'd be great |
| # | 17:31:32 | berick | 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. |
| # | 17:32:05 | berick | seems like we need an intermediary step fo some sort |
| # | 17:32:09 | miker_ | that's what the po-state was for, I thought |
| # | 17:32:50 | miker_ | well, djfiander is worried about "I don't knw the vendor" |
| # | 17:33:07 | berick | 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) |
| # | 17:33:19 | miker_ | so, a pl status flag (or multi-state field, like on POs) should address that, no? |
| # | 17:34:40 | miker_ | and, again, we can use 'user generated' attributes on both pl entries and po lineitems ... they don't get wiped at record update, IIRC |
| # | 17:36:40 | berick | 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) |
| # | 17:38:17 | berick | what's the purpose of the PL status? |
| # | 17:38:52 | miker_ | don't you just add them to one pl and mark it as "order this"? |
| # | 17:39:24 | miker_ | the purpose is to hand off pls instead of POs |
| # | 17:40:13 | miker_ | "private/mine" vs "handed off to the next guy" |
| # | 17:41:05 | miker_ | which means OU owners instead of user owners |
| # | 17:41:41 | berick | how do you indicate how many copies you want when you hand off the picklist? |
| # | 17:47:44 | berick | 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. |
| # | 17:47:59 | berick | and adds any missing pieces |
| # | 17:49:39 | berick | 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 |
| # | 17:50:17 | miker_ | 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' |
| # | 17:52:26 | berick | ok, i guess that's approaching what djf was calling a smarter (more like a po_lineitem) pl_entry |
| # | 17:53:12 | miker_ | 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'" |
| # | 17:53:22 | miker_ | and some extra attributes on entries |
| # | 17:54:55 | miker_ | 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) |
| # | 17:55:10 | miker_ | he seems to think that the ML api is complete, though, which surprised me... |
| # | 17:55:21 | miker_ | anyway, I have to go feed A ... biab |
| # | 17:56:06 | berick | 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 |
| # | 17:56:36 | berick | 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 |
| # | 17:56:57 | berick | yeah, i'll poke djf about the ML issue in his email |
| # | 17:58:10 | miker_ | 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 |
| # | 18:00:12 | berick | eh, either way is fine, really. it just seemed like a core part of the object |
| # | 18:02:35 | Karen_ has left #OpenILS-Evergreen |
| # | 18:04:22 | greg-g has joined #openils-evergreen |
| # | 18:11:53 | miker_ | for POs, I agree ... but I'm not convinced on pl entries |
| # | 18:42:22 | sarabee has quit IRC |
| # | 18:46:29 | sarabee has joined #openils-evergreen |
| # | 19:12:58 | djfiander has joined #OpenILS-Evergreen |
| # | 20:39:19 | sarabee has quit IRC |
| # | 20:40:32 | dbs has joined #OpenILS-Evergreen |
| # | 20:41:18 | sarabee has joined #openils-evergreen |
| # | 20:46:20 | phase_bb has quit IRC |
| # | 21:03:35 | djfiander | flickr as virtual whiteboard. |
| # | 21:40:18 | djfiander has quit IRC |
April 10-13