Timestamps are in GMT/BST.
[6:26] -hobana.freenode.net- *** Looking up your hostname...
[6:26] -hobana.freenode.net- *** Checking Ident
[6:26] -hobana.freenode.net- *** Found your hostname
[6:26] -hobana.freenode.net- *** No Ident response
[6:26] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:26] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:26] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[13:30] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:02] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[15:48] * ntorres (c1895861@gateway/web/freenode/ip.193.137.88.97) has joined #duraspace
[15:51] * ntorres (c1895861@gateway/web/freenode/ip.193.137.88.97) Quit (Client Quit)
[19:01] * terry-b (~chrome@97-113-118-39.tukw.qwest.net) has joined #duraspace
[19:55] * tdonohue REMINDER: The weekly DSpace DevMtg is in ~5mins. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-02-15
[20:01] <tdonohue> Welcome all to our weekly DevMtg. Agenda linked already above
[20:02] <tdonohue> Looks like a small group here (yet again). Pinging our Committers in the room though (helix84, mhwood, terry-b)
[20:02] <mhwood> Yo!
[20:02] <terry-b> hello
[20:02] <tdonohue> Perhaps we'll have a few others trickle in shortly ;)
[20:03] <tdonohue> So, let's start with the usual reminders. Tomorrow at 16UTC is our next DSpace 7 UI Mtg. This one will be in Slack via text chat.
[20:05] <tdonohue> Speaking of Slack, should the DSpace 7 Mtg go well in Slack, & if these IRC meetings are being less and less attended.... then I may start digging around into a way to hook up our IRC channels to Slack
[20:05] <tdonohue> In other words, maybe we think of moving *these* meetings also to Slack (but ensure they still get logged into IRC for folks who want to follow along later).
[20:06] <tdonohue> But, let's see how tomorrow's meeting goes, etc. and we can revisit this in the coming weeks
[20:06] <mhwood> Can't think why Slack would be *more* attractive, but that's just me....
[20:07] <tdonohue> My thought is that there will minimally be "more eyes", mhwood. I'm a bit disappointed that recent weeks we've had so few "live" people in these chat meetings. Either everyone is just reading logs, or these meetings are being ignored
[20:08] <terry-b> Perhaps I have a bad IRC client, but Slack is much more attractive and usable to me
[20:08] <tdonohue> So, moving to Slack is a way to potentially remind folks of the ongoing work to *maintain* DSpace 6 (and previous versions). That we aren't just only doing DSpace 7 now (as exciting as that is, and as much as we want more folks involved there)
[20:09] <terry-b> It feels like DSpace 6 needs some more attention to make sure it is adopted by folks.
[20:09] <mhwood> terry-b: Pidgin is clean and simple.
[20:11] <tdonohue> But, we can take one step at a time here...let's see how Slack works for DSpace 7 UI chat meetings. If that goes well, then I'll start digging into whether we can hook up IRC & Slack more directly...so that folks in Slack and see what's happening in IRC (and maybe visa versa to some extent)
[20:12] <tdonohue> In any case, I've taken us away from our agenda ;)
[20:12] <mhwood> There is a way to do that. I wound up with a tab in Pidgin for each Slack channel. I gave that up and started running the Slack client, to keep them separated.
[20:13] <tdonohue> mhwood: right, I've also heard of projects actually "hooking up" IRC channels into Slack channels. I.e. folks could have a discussion between Slack and IRC (with individuals taking part from either Slack or IRC). Not sure how well that works, but I might dig around
[20:14] <terry-b> Code4Lib has such a set up, but I do not really track conversations there
[20:16] <tdonohue> In any case, for our agenda...not sure if we want to dig into each "High Priority" ticket. But here's the list of our Highest priority, ordered by fix release: https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20ORDER%20BY%20fixVersion%20ASC
[20:16] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20ORDER%20BY%20fixVersion%20ASC
[20:17] <tdonohue> whoops, that's not the order I wanted
[20:17] <tdonohue> I want descending order...here it is: https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20ORDER%20BY%20fixVersion%20DESC%2C%20priority%20ASC
[20:17] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20ORDER%20BY%20fixVersion%20DESC%2C%20priority%20ASC
[20:18] <mhwood> I've been consumed by a move to a new server, and I need to test & merge that one this week.
[20:18] <tdonohue> Do we have any updates to share on these tickets?
[20:18] <mhwood> That one = top of the list, 3367
[20:19] <tdonohue> DS-3367
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-3367 ] - [DS-3367] Configurable Workflow authorization denied error - DuraSpace JIRA
[20:19] <tdonohue> Thanks for the update there, mhwood
[20:21] <terry-b> Should we close DS-2687 since the Administrator id was protected earleir? This ticket seems to have grown in size
[20:21] <kompewter> [ https://jira.duraspace.org/browse/DS-2687 ] - [DS-2687] When deleting a collection role the group is also deleted, which is not appropriate for non-system-created groups - DuraSpace JIRA
[20:21] <terry-b> I was concerned about the UI presentation which will eventually become irrelevant.
[20:23] <tdonohue> terry-b: I think that ticket now accurately describes the real bug (in XMLUI). It does have a lot of extra discussion now though (which is less relevant as it's fixed)
[20:23] <mhwood> 2687 is perhaps less urgent, since you can't trash your instance by accidentally deleting Administrators, but it is still broken.
[20:24] <tdonohue> We might want to simply deschedule it from 6.1 though (taking this off the "high priority" list)...as there's no activity on it and/or interest
[20:24] <mhwood> OK.
[20:24] <terry-b> I agree
[20:24] <tdonohue> ok, I'll deschedule then
[20:25] <tdonohue> I will also call attention to a new ticket I added to our list this week: DS-3378 (Another Oracle bug!)
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-3378 ] - [DS-3378] Oracle migration indexes lost - DuraSpace JIRA
[20:25] <tdonohue> It's marked "volunteer needed", but Adan (the submitter) has a patch that seems like it fixes the issue
[20:26] <tdonohue> I've asked him (earlier today) to create a PR for testing, but haven't heard back yet
[20:26] <tdonohue> mhwood: not sure if you would want to take a closer look at this, since you've been testing other Oracle migration issues (that have been similar)
[20:27] <mhwood> I can do that one. I seem to be the only regular who has Oracle handy.
[20:27] <tdonohue> (It's a similar issue to another one reported by Adan, and already merged. But, it's a different issue...where migrations take forever cause of accidentally dropped indexes)
[20:27] <mhwood> (NOT the same as being handy with Oracle. I am not. But I try.)
[20:27] <tdonohue> thanks, mhwood! It sounds like it really just needs verification tests
[20:29] <tdonohue> Are there other tickets we want to discuss today? (If not, I may suggest we move to looking at some PRs and doing some reviews here, if possible)
[20:30] <terry-b> How will we decide when we have a complete 6.1?
[20:32] <tdonohue> Ideally, we should get in most (if not all) of the "high priority" 6.1 tickets. These 11: https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20AND%20fixVersion%3D6.1%20ORDER%20BY%20fixVersion%20DESC%2C%20priority%20ASC
[20:32] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=filter%20%3D%2013904%20AND%20fixVersion%3D6.1%20ORDER%20BY%20fixVersion%20DESC%2C%20priority%20ASC
[20:32] <tdonohue> Now, we might be able to "trim" that list, or reschedule some for 6.2. But, it seems like there's still some significant bugs in that list we'd want fixed
[20:33] <tdonohue> Especially the remaining Oracle bug: DS-3378
[20:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3378 ] - [DS-3378] Oracle migration indexes lost - DuraSpace JIRA
[20:33] <tdonohue> Likely this one too: DS-3356
[20:33] <kompewter> [ https://jira.duraspace.org/browse/DS-3356 ] - [DS-3356] DatabaseUtils should turn off the authz system - DuraSpace JIRA
[20:34] <tdonohue> And I think DS-3367 too
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-3367 ] - [DS-3367] Configurable Workflow authorization denied error - DuraSpace JIRA
[20:34] <terry-b> Is the ElasticSearch one likely to stay in?
[20:34] <tdonohue> The other bugs are also significant...but we could potentially think of them as 6.2 if we cannot get any immediate "traction" on them.
[20:35] <tdonohue> ElasticSearch needs to stay on the list as it's entirely broken. However, it's one I'd say we could reschedule to 6.2 if we have no traction
[20:36] <tdonohue> So, for 6.1, I think we are highlighting significant fixes to upgrades (e.g. db migrations) and other major bugs. I would like to see ElasticSearch in there too, but if we cannot find a volunteer, we'll leave that for 6.2
[20:37] <terry-b> DS2952 had an alternative PR from Tom Desair that had looked good to me.
[20:38] <tdonohue> I just realized one of our 11 was already merged. I just closed DS-3446 as Fixed. So, that's just 10 tickets on the 6.1 wishlist ;)
[20:38] <kompewter> [ https://jira.duraspace.org/browse/DS-3446 ] - [DS-3446] Non-admin submitter cannot remove uploaded bistreams during the submission - DuraSpace JIRA
[20:38] <terry-b> Perhaps that would be an easy one to get to closure
[20:38] <tdonohue> Ok, let's look at DS-2952 then
[20:38] <kompewter> [ https://jira.duraspace.org/browse/DS-2952 ] - [DS-2952] SOLR: Full text indexing only includes the text on the last bitstream - DuraSpace JIRA
[20:38] <tdonohue> DSPR#1595
[20:38] <kompewter> [ https://github.com/DSpace/DSpace/pull/1595 ] - DS-2952 SOLR full text indexing multiple bitstreams by tomdesair
[20:39] <tdonohue> terry-b: so, you tested the PR and had an outstanding question here. Was that a concern?
[20:40] <terry-b> I did not see a reply from Tom. What is your opinion of that question?
[20:40] <terry-b> I can't say that I have tested this carefully in my own instance
[20:42] <tdonohue> Either it should (a) not index non-public bitstreams (which is slightly less than ideal if you want to search inside files as an Admin), OR (b) the indexed copy should end up with the same permissions as the original bitstream (so only admins can search within admin restricted files)
[20:42] <tdonohue> I'm not entirely sure whether this PR checks permissions at all...if it doesn't that'd be problematic (as you don't want private files indexed as public)
[20:43] <terry-b> With this implementation, all full text is merged into the item record in solr, so nuanced permissions would be lost
[20:43] <terry-b> (when multiple bitstreams exist)
[20:44] <terry-b> I have just assumed that full text bitstreams had permissions mirroring their originals, but that is impossible with the solr representation
[20:45] <tdonohue> Hmm...this worries me a bit. I would really like to see a Unit Test which shows what happens when restricted bitstreams are encountered. It's nice this has UnitTests, but I see nothing in this code that looks at permissions (at all)
[20:46] <tdonohue> So, I'm worried this might index private bitstreams as public....or it might just fail on private bitstreams (not sure)
[20:46] <terry-b> It sounds like we should make it a requirement to look at permissions.
[20:46] <terry-b> It would also be good to verify that items with a single restricted bitstream do not end up in the full text index
[20:46] <tdonohue> I'll add a new review to the PR requiring that we have the code updated for that.
[20:46] <mhwood> Do we get one index record per bitstream, or one per item? If the latter, we have a real problem.
[20:47] <mhwood> I.e. what permissions do we put on the index record?
[20:47] <terry-b> One per item with this PR.
[20:47] <mhwood> Then the index record should have the union of all the restrictions of the bitstreams that it represents.
[20:48] <terry-b> I think the full text in solr would have the permissions of the item itself
[20:48] <tdonohue> terry-b++ This seems to append all extracted text as *one* index record
[20:48] <terry-b> I will take a todo to test existing behavior and provide you all with an update
[20:48] <mhwood> Thanks!
[20:50] <terry-b> https://jira.duraspace.org/browse/DS-3495
[20:50] <kompewter> [ [DS-3495] Verify full text accessibility in SOLR with bitstreams with various access rights - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-3495
[20:51] <kompewter> [ https://jira.duraspace.org/browse/DS-3495 ] - [DS-3495] Verify full text accessibility in SOLR with bitstreams with various access rights - DuraSpace JIRA
[20:51] <terry-b> Assigned this to myself
[20:51] <tdonohue> I've also added a review to DSPR#1595 asking for dealing with restrictions
[20:51] <kompewter> [ https://github.com/DSpace/DSpace/pull/1595 ] - DS-2952 SOLR full text indexing multiple bitstreams by tomdesair
[20:52] <tdonohue> Back to our list of 6.1 High Priority..
[20:53] <tdonohue> here's another needing code review: DS-3356 / DSPR#1553
[20:53] <kompewter> [ https://github.com/DSpace/DSpace/pull/1553 ] - DS-3356 add turnoff authz system by lap82
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-3356 ] - [DS-3356] DatabaseUtils should turn off the authz system - DuraSpace JIRA
[20:54] <tdonohue> The PR here is tiny, but it seems correct. We need to turn off authorization checks when an automatic reindex (post upgrade) is triggered
[20:54] <mhwood> Yes indeed. 1 line and looks right.
[20:55] <tdonohue> And for the record, that Context object is cleaned up in a "finally { }" check later on...which is why AuthZ isn't turned back on
[20:55] <mhwood> Ah, I was working my way toward that....
[20:55] <tdonohue> Here's that full code: https://github.com/4Science/DSpace/blob/127f79f2efd65344246c8219d2941d951f58eded/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseUtils.java#L1307
[20:55] <kompewter> [ DSpace/DatabaseUtils.java at 127f79f2efd65344246c8219d2941d951f58eded · 4Science/DSpace · GitHub ] - https://github.com/4Science/DSpace/blob/127f79f2efd65344246c8219d2941d951f58eded/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseUtils.java#L1307
[20:56] <tdonohue> You'll see the finally a bit down from that
[20:56] <tdonohue> So, shall we just merge this one (and cherry-pick to 5.x and master)?
[20:56] <mhwood> Yup, there it is.
[20:56] <mhwood> Yes?
[20:57] <tdonohue> I'd vote yes here..this seems extremely obvious to me
[20:57] <tdonohue> ok, I'll take this on (My Dev environment is now working again, I think). I'll merge & cherry-pick elsewhere
[20:58] <tdonohue> We're nearing the end of our hour. So, I think we'll stop there. Any last topics/comments from anyone?
[20:59] <terry-b> Have a good week!
[20:59] <tdonohue> Yes, have a good one! And don't forget to join the DSpace 7 meetings tomorrow (16:00UTC / 11am EST) in Slack, if you are interested!
[20:59] <tdonohue> Thanks mhwood & terry-b!
[21:00] <terry-b> I will be there!
[21:00] <mhwood> Thanks all.
[21:00] * terry-b (~chrome@97-113-118-39.tukw.qwest.net) Quit (Remote host closed the connection)
[22:08] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:48] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
[23:01] * dyelar (~dyelar@biolinux.mrb.ku.edu) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.