Timestamps are in GMT/BST.
[0:08] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[0:12] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[0:35] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[0:41] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[0:55] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[0:56] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[1:02] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[1:03] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[4:05] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[6:55] * ChanServ (ChanServ@services.) Quit (lindbohm.freenode.net irc.freenode.net)
[6:55] * ChanServ (ChanServ@services.) has joined #duraspace
[9:58] * barmintor (i=barminto@128.59.156.13) has joined #duraspace
[10:01] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[10:09] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[10:39] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[10:46] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[10:49] * barmintor (i=barminto@128.59.156.13) Quit (Read error: 131 (Connection reset by peer))
[10:49] * barmintor (i=barminto@specdl11.cul.columbia.edu) has joined #duraspace
[11:10] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[11:18] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[11:18] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (lindbohm.freenode.net irc.freenode.net)
[11:18] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[11:24] -christel- [Global Notice] Hi all, Sorry for the delay in updating you -- wanted to get confirmation from sponsors about the actual issue, we are indeed still experiencing heavy DDoS and our upstream providers are working to curb it at the borders were possible. Further info will be via wallops. Thank you.
[14:31] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[14:42] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[14:55] * jtrimble (n=jtrimble@maag127.maag.ysu.edu) has joined #duraspace
[14:58] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[14:59] <kshepherd> meeting today?
[14:59] <stuartlewis> AFAIK
[14:59] <lcs> that's what i'm here for
[15:00] <kshepherd> looks like rrodgers should be along to convene it soon
[15:01] <stuartlewis> If he doesn't arrive, we'll just perform a post-testathon JIRA review.
[15:01] * kshepherd nods
[15:04] * richardrodgers (n=richardr@pool-173-76-16-252.bstnma.fios.verizon.net) has joined #duraspace
[15:04] <stuartlewis> List of JIRA issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-4w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[15:04] <stuartlewis> Starting with DS-400
[15:05] <stuartlewis> Is everyone OK if we just plough through the outstanding issues for this meeting, and try to get as many assigned as possible for 1.6?
[15:05] <richardrodgers> sure
[15:05] <kshepherd> sounds good to me
[15:05] <lcs> so long as we can assign them to people who aren't here :-)
[15:05] <stuartlewis> rochardrodgers: Sorry - didn't see you arrive.
[15:06] <stuartlewis> Did you want to take over chairing the meeting?
[15:06] <richardrodgers> no go ahead
[15:06] <stuartlewis> OK...
[15:07] <stuartlewis> Bug DS-400 Webui item browse (date, title or similar) reduces displayed issue date by one day http://jira.dspace.org/jira/browse/DS-400
[15:07] <lcs> re DS-400, i'll look into a fix if someone can locate the offending code in jspui for me; i don't know my way around the underbrush.
[15:08] <stuartlewis> I'll try and locate it, comment on it, then assign to Larry.
[15:08] <stuartlewis> Next...
[15:08] <stuartlewis> http://jira.dspace.org/jira/browse/DS-401
[15:08] <stuartlewis> Wrong date issued during submission
[15:09] <stuartlewis> Old bug, leave for after 1.6 (unless anyone wants to tackle it?)
[15:09] <kshepherd> how 'valid' is valid? just making a hard liit of 31?
[15:10] <kshepherd> do we need to know if it's a leap year before decidnig the max Feb date someone can enter?
[15:10] <kshepherd> etc
[15:10] <richardrodgers> Let's get the showstoppers first..
[15:10] <lcs> it'd be better to solve it right, and then there's the problem of error handling.
[15:10] <stuartlewis> Exactly, so too big for 1.6?
[15:10] <lcs> teh GregorianCalendar class can help you validate dates. but agreed, not 1.6.
[15:10] <kshepherd> (the bug is just gregoriancalendar doing what its designed to do.. roll over to next month when it gets a number that overflows)
[15:11] <stuartlewis> Ok - will leave open
[15:11] <stuartlewis> http://jira.dspace.org/jira/browse/DS-402 Item mapper search case sensitive (jspui only)
[15:11] <stuartlewis> I'm happy to look at this one, unless anyone else has a burning desire to do so?
[15:12] <stuartlewis> (although again, not a new bug or showstopper)
[15:12] <richardrodgers> knock yourself out ;)
[15:13] <stuartlewis> :)
[15:13] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[15:13] <stuartlewis> http://jira.dspace.org/jira/browse/DS-403 Registration Notification with null data for eperson created by the administrator
[15:13] <stuartlewis> Leave for post 1.6 unless anyone wants to tackle it? (not new / not showstopper)
[15:14] <richardrodgers> +1
[15:14] <kshepherd> +1
[15:14] <lcs> +1
[15:15] <stuartlewis> OK +3leave for post 1.6
[15:15] <stuartlewis> http://jira.dspace.org/jira/browse/DS-404 Notifications for submitter and workflow task responsible on workflow abortion through administrator
[15:15] <stuartlewis> Same again - post 1.6?
[15:15] <lcs> +1 later - to big a change not to test
[15:15] <richardrodgers> +1 later
[15:16] <kshepherd> +1 later
[15:16] <stuartlewis> OK +4 leave for post 1.6
[15:16] <stuartlewis> http://jira.dspace.org/jira/browse/DS-405 New 1.6 Statistics settings in dspace.cfg need Documentation
[15:16] <jtrimble> Done
[15:16] <stuartlewis> Can the issue be closed?
[15:16] <jtrimble> There were missing notes in the documentation.
[15:17] <jtrimble> The skeleton documentation is done.
[15:17] <stuartlewis> Excellent - thanks
[15:17] <stuartlewis> Does the issue need to remain open?
[15:17] <jtrimble> I'd like to remain open until my dear Friend Mark sends me the nitty gritty details.
[15:18] <stuartlewis> OK - shall I assign it to Mark then?
[15:18] <jtrimble> >EG< Yes.
[15:18] <stuartlewis> OK
[15:18] <stuartlewis> Assigned to mdiggory
[15:19] <stuartlewis> http://jira.dspace.org/jira/browse/DS-406 View Statistics button does not work in item page
[15:19] <stuartlewis> +1 to get this committed
[15:19] <richardrodgers> +1 isn't there a patch?
[15:19] <lcs> +1 yup, there's a patch
[15:19] <stuartlewis> Yes - patch looks ready to go
[15:20] * caryn (i=80c8e115@gateway/web/freenode/x-xdzwpgdyqwmnrxzo) has joined #duraspace
[15:20] <stuartlewis> OK + 3 to have it committed. kshepherd: You ok to do that?
[15:20] <kshepherd> it's done
[15:20] <kshepherd> i'll commit after meeting
[15:21] <stuartlewis> Thanks :)
[15:21] <stuartlewis> http://jira.dspace.org/jira/browse/DS-407 Install or Upgrade on existing server throws errors for "mvn package"
[15:21] <stuartlewis> Does Tim's advice of using mvn -U package sound right? (it does to me)
[15:21] <jtrimble> Yes, but should that be a default behavior for a fresh install??
[15:21] <richardrodgers> so it's a doc issue?
[15:21] <jtrimble> Well, maybe...
[15:22] <stuartlewis> This is for upgrades
[15:22] <jtrimble> Upgrades it makes sense to make sure you get the freshest software
[15:22] <stuartlewis> OK - so assign to jtrimble for doc update?
[15:23] <mdiggory> my apologies, I have to lurk ATM
[15:23] <kshepherd> i think it needs to be recommended in doc
[15:23] <jtrimble> My question is the install.... shouldn't maven look for the matching package out there? I just did a fresh install with 1.5.2 and didn't need the -U
[15:23] <jtrimble> The ticket say for INSTALL or UPGRADE
[15:23] <jtrimble> Doc is already updated.
[15:23] <stuartlewis> I guess it depends if it is the first time you have run fresh_install on that particular server.
[15:23] <jtrimble> So, now with 1.6 we need the -U for the install?
[15:24] <jtrimble> OH gotcha....that could really catch someone off gard.
[15:24] <jtrimble> guard
[15:24] <stuartlewis> No harm in specifying the -U I suppose?
[15:24] <jtrimble> Not IMHO. Everyone else with using mvn -U fresh_install? (Can you do that with the -U flag??)
[15:24] <jtrimble> else = else ok
[15:25] <stuartlewis> +1
[15:25] <kshepherd> +1
[15:25] <lcs> +1
[15:25] <caryn> +1
[15:25] <jtrimble> Okay all docs will be updated over the weekend to reflect the change.
[15:25] <stuartlewis> Carried: 5x +1, assigned to jtrimble
[15:25] <stuartlewis> Thanks Jeff.
[15:25] <jtrimble> I'll test a fresh install for 1.6 to make it works.
[15:25] <mdiggory> mvn -U clean upgrade
[15:25] <richardrodgers> +1 could be better I agree, bit we can live with this
[15:26] <mdiggory> if you do not clean the dspace/target/dspace-build.... directory, old files (especially jars, are still present)
[15:26] <lcs> is there an option you can set in the POM that tells it to go re-check remote repositories?
[15:26] <jtrimble> are you saying to do that instead of mvn -U package or a antecedent
[15:26] <stuartlewis> Do the docs mention an 'svn update' build option, which is where that problem would occur?
[15:27] <jtrimble> no..there is no mvn update...just mvn package
[15:27] <mdiggory> -U
[15:27] <stuartlewis> Do we need to add a note about users who upgrade using svn, that they need to run 'mvn -U clean package' ?
[15:27] <lcs> iirc, "update" is the ant target.
[15:28] <stuartlewis> lcs: This is svn update, for pulling down the latest code on top of old code.
[15:28] <stuartlewis> In that case, mvn clean needs to be run to clean out old dependcy jars.
[15:29] <jtrimble> So, you want additional instructions for those who are pulling down the code too?
[15:29] <stuartlewis> I don't think we do - will confuse the manual too much.
[15:29] <jtrimble> so for upgrade, are you suggesting mvn -U package or Mark's mvn -U clean upgrade?
[15:30] <stuartlewis> Shall we put the clean in, again, does no harm?
[15:30] <jtrimble> leave the svn out of it...just the public download of the zip/bz2/gz files...
[15:30] <mdiggory> you better run "clean" it should be a requirement
[15:31] <stuartlewis> OK - use 'mvn -U clean package'
[15:31] <jtrimble> Okay...So the step to Rebuild DSpace is 'mvn -U clean update' instead of mvn -U package? I just want to get this right.
[15:31] <stuartlewis> http://jira.dspace.org/jira/browse/DS-409 JSPUI Statistics Display ignores "statistics.item.authorization.admin"
[15:32] <stuartlewis> Patch looks fine. +1 commit it
[15:32] <richardrodgers> Looks like kshepherd has a patch +1
[15:32] <kshepherd> patch ready to go
[15:32] <lcs> +1
[15:32] <kshepherd> ok
[15:32] <stuartlewis> OK: 3 x +1, patch to be committed
[15:32] <mdiggory> I'd also toss in that using the path /statistics in the XMLUI blocks access to the older reporting, we should adjust this
[15:33] <stuartlewis> mdiggory: Is that a new issue?
[15:33] <stuartlewis> (separate issue to 409)
[15:34] <stuartlewis> http://jira.dspace.org/jira/browse/DS-410 Updates to Upgrade Instructions necessary
[15:34] <mdiggory> yes, different issue, but stats related
[15:34] <kshepherd> mdiggory: i chose 'displaystats' for JSPUI.. wasn't 100% on that name either, should we try and get both UIs using the same path for usage stats to avoid confusion?
[15:35] <mdiggory> thats probibly fine... "/usage" might be good too.
[15:35] <kshepherd> hmm yes i like /usage
[15:35] <stuartlewis> Can one of you open a new issue for it?
[15:35] <kshepherd> let's log as a new issue and we can both submit patches?
[15:35] <mdiggory> note, we prepend this path onto the end of the URL... whereas you parameterize it, we might want to consider if it can be prepended in the JSPUI?
[15:35] <kshepherd> true
[15:35] <mdiggory> ok, I'll look when I have a moment
[15:36] <kshepherd> that should be fairly trivial
[15:36] <jtrimble> Assign DS-410 to me. I've already incorporated them into the documentation.
[15:36] <stuartlewis> jtrimble: OK - thanks.
[15:36] <stuartlewis> http://jira.dspace.org/jira/browse/DS-411 XMLUI itemSummaryList-DIM only matches first possible author metadata field
[15:37] <richardrodgers> notes say postpone?
[15:37] <stuartlewis> Yup - just seen that. Ok will skip it.
[15:37] <kshepherd> yeah last week we decided to postpone
[15:37] <stuartlewis> http://jira.dspace.org/jira/browse/DS-412 Xpdf MediaFilter: generate UTF-8 text, and improve error reporting
[15:37] <kshepherd> and i'll make some alternative templates available for those that need extra handling
[15:38] <stuartlewis> +1 - looks a useful patch
[15:38] <kshepherd> +1
[15:38] <richardrodgers> +1 seems low risk, have patch
[15:38] <kshepherd> UTF8 > Latin1 ;)
[15:38] <kshepherd> especially for the text i work with ;)
[15:38] <lcs> fwiw, i've tested this patch in production, it's been fine, and picking out the encrypted pdfs is handy.
[15:38] <lcs> ok, i'll commit it.
[15:38] <stuartlewis> 3 x +1 - OK to commit
[15:39] <stuartlewis> http://jira.dspace.org/jira/browse/DS-413 solr statistics evaluation timespan displayed
[15:39] <kshepherd> rather 'brief' description ;)
[15:41] <stuartlewis> I think it means rather than 'Views 317', it should say '317 views this year / month / for ever' etc
[15:42] <stuartlewis> (kshepherd: That reminds me - think I've found a big with jspui stats and file names - remind me to show you later)
[15:42] <stuartlewis> What do we think of that issue?
[15:42] <stuartlewis> Leave it low priority? Not a show stopper?
[15:42] <richardrodgers> Good idea, but don't hold 1.6 for it
[15:42] <kshepherd> well.. some context is necessary, i agree
[15:42] <stuartlewis> Or a simple change that will improve the reports a lot?
[15:43] <lcs> it's a valid point, and would be helpful.
[15:43] <kshepherd> it shoudn't be hard to just give a start date for stats reporting
[15:43] <richardrodgers> so it is always life of server?
[15:43] <jtrimble> With this being a new better feature, it should be very clear and not need improving in a next release.
[15:43] <stuartlewis> kshepherd: Can we assign it to you to look at the jspui, then you can assign it to mdiggory to fix the xmlui?
[15:44] <kshepherd> uh
[15:44] <kshepherd> is that data available from org.dspace.statistics already?
[15:44] <kshepherd> i didn't see it in any datasets
[15:44] <stuartlewis> richardrodgers: Undecided I think. There is not the possiblility to purge or aggregate old stats yet, but this feature will no doubt be needed in future versions to cope with huge stats solr indexes.
[15:44] <richardrodgers> k
[15:45] <kshepherd> i guess we can just make an assumption and use "life of server"
[15:45] <kshepherd> othewrise it'll need to go back to dspace-stats first, not the UIs
[15:45] <stuartlewis> Sounds sensible, as hopefully we'll use stats aggregation later.
[15:45] <kshepherd> that's one good thing about dspace-stats.. the way we're building it, people can upgrade dspace-stats without affecting the rest of their installation... if my understanding is correct
[15:45] <stuartlewis> Who shall we assign the issue to: mdiggory or kshepherd?
[15:47] <kshepherd> if you want a quick hack for 'life of solr server' or some other assumption, you can pass it to me first.. if you want it to be an accurate time period that is included in the actual stats datasets, pass to mdiggory/@mire
[15:47] <stuartlewis> I guess we need some nice words that mean 'forever' / 'life of solr server' etc?
[15:48] <kshepherd> i plan on feeding about 18 months worth of old logs
[15:48] <kshepherd> so life of solr server won't be accurate for me..
[15:48] <stuartlewis> I'll assign to kshepherd for now, and we can discuss wordsmithing in JIRA
[15:48] <stuartlewis> http://jira.dspace.org/jira/browse/DS-414 solr statistics file downloads listed in statistics display of communites and collections
[15:48] <kshepherd> i'd still like a consensus on what our best assumption for 'oldest stats record' is and how we reach it
[15:48] <mdiggory> I'm sorry, I've been in a phone conference all this time. Do not stop logging. keep logs in parallel, we need to complete stuartlewis work on rebuilding the solr index from the logs
[15:49] <stuartlewis> mdiggory: No plans to stop stop logging. We're just discussing text labels.
[15:49] <mdiggory> I'm still in call sorry, I will comment on these topics afterward via JIRA
[15:49] <kshepherd> mdiggory: ds-413 requests stats time periods in the reports
[15:49] <stuartlewis> http://jira.dspace.org/jira/browse/DS-414 solr statistics file downloads listed in statistics display of communites and collections - kshepherd: OK if we assign this to you?
[15:50] <kshepherd> stuartlewis: yep
[15:50] <richardrodgers> Could I raise a non-testathon 1.6 issue?
[15:50] <stuartlewis> Thanks :)
[15:50] <kshepherd> sorry, didn't see that one was jspui-only
[15:50] <stuartlewis> richardrodgers: OK
[15:51] <richardrodgers> I'm concerned about DS-253 and it's disposition IIRC we were even going to do a 1.5.3 to fix it
[15:51] <richardrodgers> How does it now stand in 1.6?
[15:52] <richardrodgers> (Guess this is for one of the Marks...)
[15:52] <richardrodgers> mdiggory: can you comment in JIRA later? Know you are in a call
[15:53] <stuartlewis> Yes - looks like we need a resolution for 1.6
[15:53] <stuartlewis> Next issue: http://jira.dspace.org/jira/browse/DS-415 Create groups via admin UI authorization denied
[15:54] <kshepherd> i have to go soon
[15:54] <stuartlewis> Do we need to ask for a set of steps to replicate? (not sure if this issue is using delegated admin)
[15:54] <caryn> i wondered that too...
[15:54] <stuartlewis> 0: Ask for more detail
[15:54] <lcs> it says "as a member of the administrator group"..
[15:54] <kshepherd> but i'm happy to have DS-425 assigned to me since i'm doing some other small JSPUI patching soon anyway (just in case i'm gone by then)
[15:55] <stuartlewis> kshepherd: Thanks :)
[15:55] <stuartlewis> Yup - can confim this.
[15:55] <stuartlewis> This for a normal admin user.
[15:55] <stuartlewis> Just recreated this bug on testathon.net/xmlui :(
[15:56] <stuartlewis> This is a show stopper
[15:56] <kshepherd> that's... a showstopper
[15:56] <kshepherd> jinx!
[15:56] <stuartlewis> Any volunteers? Guess it might have something to do with delegated admin patch?
[15:56] <richardrodgers> can we volunteer andrea?
[15:57] <stuartlewis> We can try. If not Tim also looked at that code I think.
[15:57] <richardrodgers> was just thinking shortest path..
[15:57] <stuartlewis> http://jira.dspace.org/jira/browse/DS-417 1-day (or passed) embargo dates give error upon submission
[15:58] <lcs> I can look into that.
[15:58] <stuartlewis> I wonder if this was because he was working on testathon.net which is in the NZ timezone, so 12+ hours ahead of US time.
[15:58] <stuartlewis> lcs: Thanks. Will assign to you.
[15:59] <lcs> I may need you to help test a patch in NZ.. :-)
[15:59] <stuartlewis> http://jira.dspace.org/jira/browse/DS-418 i18n broken in jspui
[15:59] <caryn> BTW - on DS-415 I just successfully created on on testathon.net/jspui
[15:59] <stuartlewis> Is DS-418 a new issue, or an old one? If old, leave for post 1.6?
[16:00] <stuartlewis> caryn: Thanks. That confirms it is an xmlui only bug.
[16:00] <kshepherd> i want to test i18n issues more
[16:00] <richardrodgers> +1 stuartlewis
[16:00] <stuartlewis> OK - 418 we'll ask for more info from Claudia.
[16:00] <stuartlewis> We have passed the 1 hour mark now.
[16:00] <kshepherd> i've noticed some wierd behaviour
[16:01] <stuartlewis> Shall we stop, or is anyone happy to continue for a while to get through a few more issues?
[16:01] <richardrodgers> I'd do a few more
[16:01] <lcs> more, please
[16:01] <kshepherd> when logging out of.. i can;t remember if it was JSPUI or XMLUI, the i18n immediately swapped to chinese, which is my 2nd preference in my browser settings
[16:01] <kshepherd> i think that's what happened, anyway. i need tot est more.
[16:01] <kshepherd> but i also have to go now :( will try to be back soon
[16:02] <stuartlewis> OK - we'll carry on for a while.
[16:02] <stuartlewis> http://jira.dspace.org/jira/browse/DS-419 Setting embargo.field.terms to an unqualified field throws uncaught exception on item submission
[16:02] <stuartlewis> Looks like the patch can be applied?
[16:02] <lcs> yup, it's all ready
[16:03] <richardrodgers> +1
[16:03] <caryn> +1
[16:03] <lcs> +1
[16:03] <stuartlewis> Excellent: 4 x +1 - can be comitted
[16:04] <stuartlewis> http://jira.dspace.org/jira/browse/DS-420 Community admin unable to delete items mapped to other collections.
[16:04] <stuartlewis> Ask Andrea if he'll look at this one too?
[16:04] <lcs> Is it necessarily even a bug? Should admin A have to ask admin B to unmap them?
[16:05] <richardrodgers> yes, I agree it's borderline
[16:05] <stuartlewis> Yes - a moot point.
[16:05] <stuartlewis> Shall I open up a discussion on JIRA?
[16:05] <lcs> +1 stuartlewis
[16:06] <richardrodgers> yep - cmmutative stuff can be unintuituve
[16:06] <caryn> +1 needs to be discussed
[16:06] <stuartlewis> http://jira.dspace.org/jira/browse/DS-421 Setting solr.metadata.item.X property to an unqualified field generates exception in SolrLogger.post on item view and prevents Solr from logging the event
[16:06] <stuartlewis> dspace.cfg has been fixed now?
[16:07] <lcs> good grief, we need some utility routines that can break down the stupid DC field specifiers without these bugs.. embargo had the same problem.
[16:08] <mdiggory> I'll take it
[16:08] <lcs> the routines in embargomanager are fixed now :-)
[16:08] <stuartlewis> mdiggory: Thanks
[16:09] <stuartlewis> http://jira.dspace.org/jira/browse/DS-422 Directory 'etc' missing from Ant target 'init_installation'.
[16:09] <stuartlewis> Anyone happy to look into this one?
[16:10] <richardrodgers> sure should be trivial
[16:10] <stuartlewis> Thanks.
[16:10] <stuartlewis> http://jira.dspace.org/jira/browse/DS-423 Ant target 'clean_database' doesn't drop all tables'.
[16:11] <stuartlewis> Shall we ask Claudia to commit the patch, then assign to (lcs?) to look at the Oracle side?
[16:11] <richardrodgers> +1
[16:11] <caryn> +1
[16:12] <lcs> I have an ugly solution for Oracle; a separate script that generates teh SQL to clean out tables.
[16:12] <lcs> otherwise there's no way to catch all the BI-* tables. but oracle folks ought to be used to such horrors by now. and, yeah, i'll take it after Claudia.
[16:13] <stuartlewis> Thanks
[16:13] <stuartlewis> http://jira.dspace.org/jira/browse/DS-424 Export metadata button displayed in JSPUI Administration List of withdrawn items
[16:13] <stuartlewis> I'm happy to look at this?
[16:14] <stuartlewis> http://jira.dspace.org/jira/browse/DS-425 JSP UI cosmetics: horizontal scroll bar
[16:14] <richardrodgers> +1 seems simple
[16:14] <stuartlewis> kshepherd said he was happy to do this one if we're happy with the fix?
[16:14] <stuartlewis> +1
[16:14] <caryn> +1
[16:14] <lcs> +1
[16:15] <stuartlewis> 4 x +1 - assigned to Kim
[16:15] <stuartlewis> http://jira.dspace.org/jira/browse/DS-426 Item's submission license accessible without beiing configured to be public
[16:16] <stuartlewis> Old bug? Leave for post 1.6?
[16:16] <lcs> it _is_ shown in teh xmlui, and has been since 1.5..
[16:16] <mdiggory> http://jira.dspace.org/jira/browse/DS-422 etc was never actually used/run in [dspace-dir] it gets run during ant install in [dspace-src]
[16:17] <mdiggory> so having etc in [dspace-dir]/etc doesn't actually serve a purpose unless we decide we want to recommend that should be where it is always executed from
[16:18] <lcs> so the information in the license which "might conflict with privacy laws" is the email address of the submitter, right? I think that is now configurable; i was working on it with andrea a while ago.
[16:18] <richardrodgers> ok so mistaken report?
[16:18] <mdiggory> or more specifically where the sql files on fresh_install are aquired from
[16:19] <stuartlewis> What shall we do with ds-422?
[16:19] <mdiggory> 426 .... take it out of XMLUI template +1 for fixing in 1.6
[16:19] <richardrodgers> Update issue with this explanation
[16:19] <stuartlewis> Sorry - yes, 426 (not 422!)
[16:19] <mdiggory> sorry, I'm now here for a bit
[16:20] <stuartlewis> Who shall we assign 426 to?
[16:20] <mdiggory> focusr on 426 first
[16:20] <lcs> oops, it looks like DS-217, the license work, got dropped on the floor.
[16:21] <stuartlewis> Does 217 fix 426? (can it be marked as duplicate and closed?)
[16:21] <lcs> they are related -- 217 allows you to prevent the confidential info from getting into licenses. but it doesn't necessarily fix it.
[16:22] <jtrimble> <==has to leave. Nighty night all...
[16:22] <stuartlewis> Thanks Jeff. Bye.
[16:22] <mdiggory> no 426 is about exposing the Collection submission license in the presentation of the collection view
[16:22] <richardrodgers> bye
[16:22] * jtrimble (n=jtrimble@maag127.maag.ysu.edu) Quit ("Leaving")
[16:22] <stuartlewis> Anyone happy for us to assign 426 to them?
[16:22] <mdiggory> it shows only if it has been customized... claudia brought it up
[16:22] <lcs> d'oh, i thought it was in the Item, you're right..
[16:23] <mdiggory> hmm, wait this is stlightly different than that
[16:24] <mdiggory> this is about access rights on license bitstreams
[16:24] <lcs> nope again, ds-426 _is_ about the Item's deposit license.
[16:25] <caryn> so, if u can customize item license (as prescribed in 217), does this solve it?
[16:25] <lcs> if we change the access so it is not public than we should remove the links in the xmlui item page (full view at least has it).
[16:25] <mdiggory> thought this was... http://jira.dspace.org/jira/browse/DS-398
[16:26] <lcs> this is getting complicated enough that perhaps it ought to be put off to the next release.
[16:26] <mdiggory> I want to caution that, we are now talking about individual organization policies here, not neccessarily what the DSpace application should be hardwired to do
[16:26] <mdiggory> we want to be cautious and support configurability
[16:26] <caryn> mdiggory: +1
[16:27] <caryn> for some, the license could be considered part of metadata, which is typically openly available... (w/o confidential info, of course)
[16:27] <lcs> +1 mdiggory
[16:27] <stuartlewis> So to conclude: What (if anything) do we do for 1.6?
[16:28] <lcs> i would like to postpone it and combine it with DS-217 - already drew the link in jira.
[16:28] <stuartlewis> OK - thanks.
[16:28] <caryn> +1 lcs - having a good sense of "requirements" would be useful
[16:29] <stuartlewis> ANd the same for http://jira.dspace.org/jira/browse/DS-427 ?
[16:29] <mdiggory> I would like to postpone it and consider that maybe what we want are "Item templates" that define what the policies should be on various bundles / bitstreams
[16:29] <stuartlewis> "Item license per default displayed in item display of the xmlui"
[16:30] <lcs> Re -427, does the JSPUI display a link to the license? If not, we could bring them to "parity"..
[16:30] <stuartlewis> IIRC, jspui only does if configured to do so in dspace.cfg (can't remember the key)
[16:30] <mdiggory> note, in XMLUI there is a configuration option to expose presentation / access and editing the License bundle across the whole repo...
[16:30] <stuartlewis> # whether to display the contents of the licence bundle (often just the deposit
[16:30] <mdiggory> Content, License, Metadata, Text, etc
[16:30] <stuartlewis> # licence in standard DSpace installation
[16:30] <stuartlewis> webui.licence_bundle.show = false
[16:31] <kshepherd> back
[16:31] <caryn> postpone - document the options currently available in jira
[16:31] <mdiggory> so 427 : fix default setting for xmlui
[16:31] <mdiggory> to behave same as jspui
[16:32] <richardrodgers> yes
[16:32] <stuartlewis> 427: Any volunteers?
[16:32] <mdiggory> gosh that took a alot of talk to clarify
[16:33] <richardrodgers> could do
[16:33] <caryn> just so i have my head around it, license will be hidden by default in both xmlui and jspui display (need change in dspace.cfg for xmlui), but will be bundled in download, right?
[16:33] <stuartlewis> richardrodgers: Thanks :)
[16:34] <mdiggory> I'm not sure, but I think this should be ItemViewer in the XMLUI
[16:35] <mdiggory> At least, this is where that logic "should" be
[16:35] <richardrodgers> k, thanks for pointer
[16:35] <stuartlewis> http://jira.dspace.org/jira/browse/DS-429 Item withdrawal/tombstoning
[16:35] <stuartlewis> (8 more issues to go BTW)
[16:35] <stuartlewis> Not new / leave for post 1.6?
[16:36] <mdiggory> post 1.6 +1
[16:36] <kshepherd> hrm, so this is mroe of a feature request -- adding proper tombstoning to withdrawal process?
[16:36] <kshepherd> if ss, post 1.6 +1
[16:36] <lcs> +1 later
[16:36] <kshepherd> s/ss/so/
[16:37] <richardrodgers> +1 later
[16:37] <caryn> +1 l8r
[16:37] <stuartlewis> Ok - will mark as a feature request
[16:37] <stuartlewis> http://jira.dspace.org/jira/browse/DS-431 Restricted Bitstream prompts for login, then forwards user to MyDSpace
[16:37] <richardrodgers> Is this new?
[16:37] <stuartlewis> Don't think so
[16:38] <kshepherd> it'd be pretty nice to fix
[16:38] <caryn> +1 kshepherd (would be more elegant)
[16:39] <caryn> probably not a show stopper, if it's complicated to resolve
[16:39] <stuartlewis> Any volunteers? If not, we'll leave it.
[16:40] <stuartlewis> Ok - we'll leave for now. Not a showstopper.
[16:40] <kshepherd> not quite familiar enough with JSPUI to volunteer just yet.. if it turns out to be easy, i'll grab the JIRA issue later?
[16:40] <stuartlewis> OK - thanks :)
[16:40] <stuartlewis> http://jira.dspace.org/jira/browse/DS-430 'Embargo'
[16:41] <stuartlewis> Can this issue be closed? Has the documentation been improved?
[16:41] <kshepherd> (send a 'previousPage' path with auth request, iwth My DSpace as the default 'previousPage' or so)
[16:41] <richardrodgers> Haven't looked recently
[16:41] <lcs> me neither..
[16:42] <stuartlewis> Assign to Jeff to check?
[16:42] <richardrodgers> yep
[16:42] <stuartlewis> OK
[16:42] <lcs> maybe change title to "Embargo Docu8menation".
[16:42] <lcs> um, the "8" is silent.
[16:42] <stuartlewis> :)
[16:42] <kshepherd> heh
[16:42] <stuartlewis> http://jira.dspace.org/jira/browse/DS-432 No mention of config/news-xmlui.xml in manual
[16:43] <richardrodgers> Should probably get a mention
[16:43] <caryn> fwiw, i didn't see any documentation of embargo at http://digital.maag.ysu.edu/jspui/doc/
[16:43] <stuartlewis> Anyone happy to write some text for Jeff?
[16:43] <caryn> i can take that one
[16:44] <richardrodgers> caryn: he did write some, maybe not incorporated
[16:44] <kshepherd> http://digital.maag.ysu.edu:8080/jspui/doc/ch08.html#N15853
[16:44] <caryn> thanks, richardrogers - i'll follow up with him, and give him text if he needs it
[16:44] <kshepherd> embargo CLI reference is there
[16:44] <kshepherd> and dspace.cfg properties are also documented in his lastest doc
[16:44] <caryn> kshepherd: config stuff is documented, but not ui
[16:45] <richardrodgers> Maybe some simple 'use-cases' would help
[16:45] <kshepherd> hm, well.. there isn't really a UI supplied from my understanding, we're supposed to just incorporate it into submission and standard metadata editing, right?
[16:45] * kshepherd realises he might be out of date with embargos ;)
[16:45] <lcs> kshepherd: right.
[16:46] <stuartlewis> caryn: Thanks.
[16:46] <stuartlewis> http://jira.dspace.org/jira/browse/DS-433 Update DublinCore Registry to Implement lates DC Standards
[16:46] <lcs> re -432, i'll take a stab at it if nobody who knows xmlui better jumps in.
[16:47] <caryn> in the issue, jim provides some basic info about how to get at the embargo settings in the ui (it's basically, look for a button), but i didn't see anything about it in the docs...
[16:47] <caryn> lcs: let me know how i can help... i work in a library, so there are all kinds of dc experts around here!
[16:47] <caryn> actually, sorry - i was thinking you were responding to 433
[16:48] <stuartlewis> http://jira.dspace.org/jira/browse/DS-433 Update DublinCore Registry to Implement lates DC Standard - leave for post 1.6?
[16:48] <lcs> +1 stuartlewis - this is a can-o-worms.
[16:48] <richardrodgers> not sure the exact thrust of 433 - just default reg settings?
[16:48] <caryn> definitely leave for post-1.6 - it might get very complicated very fast
[16:48] <kshepherd> lcs: one thing that might be a good note for DS-432 is to note that links need to be <xref> to render correctly, i've seen that trip a few people up
[16:48] <lcs> kshepherd: thanks!
[16:48] <stuartlewis> OK - DS-433 - leave for now
[16:49] <kshepherd> 433 is HUGE, and definitely needs addressing, but not now ;)
[16:49] <stuartlewis> http://jira.dspace.org/jira/browse/DS-434 Browse use of jump to navigation leeds to NPE
[16:50] <stuartlewis> Can't reproduce this in xmlui
[16:50] <kshepherd> i can't replicate in my jspui either
[16:50] <richardrodgers> needs requalification then
[16:50] <kshepherd> and the affected versions aren't noted...
[16:50] <stuartlewis> Close as can't reproduce? Claudia can re-open if needed.
[16:50] <lcs> sometimes that happens when you change browse config and don't rebuild indexes.
[16:50] <kshepherd> lcs: good point
[16:51] <kshepherd> +1 can't reproduce, need more info
[16:51] <lcs> +1 kshepherd
[16:51] <stuartlewis> 3 issues left...
[16:52] <caryn> +1 kshepherd
[16:52] <stuartlewis> http://jira.dspace.org/jira/browse/DS-435 UI cosmetics, "My Exports" displayed in navigation bar, when no user is logged in
[16:52] <stuartlewis> Doesn't seem to occur at http://testathon.net/xmlui
[16:52] <stuartlewis> Or http://eldorado2.tu-dortmund.de:8080/xmlui
[16:53] <kshepherd> nor mine
[16:53] * kshepherd blames cocoon caching
[16:53] <stuartlewis> Or http://tspacetest.library.utoronto.ca:14080/xmlui
[16:53] <lcs> It's happened to me intermittently with a very hacked 1.5.2, but i never had time to track it down. still don't.
[16:53] <stuartlewis> Ok - close - can't reproduce?
[16:53] <lcs> ooh, yeah, i like "blame cocoon caching".
[16:53] <kshepherd> i get all sorts of funny issues after logging out/in until i do full browser refreshes, etc.
[16:54] <caryn> i get it this at our instance of dspace 1.5.1 - http://dspace.nacs.uci.edu/xmlui/
[16:54] <stuartlewis> http://jira.dspace.org/jira/browse/DS-436 SWORD Authenticator don't support the special groups infrastructure
[16:54] <caryn> not in jspui though...
[16:54] <kshepherd> caryn: thanks, well spotted... perhaps we fixed this in 1.5.2 or 1.6, i'll check
[16:54] <stuartlewis> Looks like Andrea has this one sorted.
[16:54] <lcs> re -436, i'd like to see that if it's not too destabilizing.
[16:55] <stuartlewis> 436: +1
[16:55] <richardrodgers> +1
[16:55] <kshepherd> +1
[16:55] <lcs> +1
[16:55] <stuartlewis> Thanks - 4 x +1
[16:55] <stuartlewis> Last one...
[16:55] <stuartlewis> http://jira.dspace.org/jira/browse/DS-437 Oracle DB Schema has artifacts from past releases
[16:56] <stuartlewis> +1
[16:56] <lcs> +1 but it's my patch
[16:56] <kshepherd> i don't use oracle, patch looks sensible though
[16:56] <richardrodgers> +1
[16:56] <caryn> +1
[16:56] <stuartlewis> OK - thanks. 4 x +1
[16:57] <stuartlewis> WOW - thanks - we've covered a lot of ground today :)
[16:57] <kshepherd> yep good work :)
[16:57] <caryn> woohoo!
[16:57] <lcs> first tiem we've caught up with JIRA!
[16:57] <kshepherd> quick, let's make it read-only before anyone logs another issue!
[16:57] <kshepherd> ;)
[16:57] <caryn> lol
[16:57] <stuartlewis> I've got a new one - but I'll leave it until after lunch!
[16:58] <stuartlewis> OK - meeting over?
[16:58] <kshepherd> stuartlewis: oh, what was the filename/jspui stats issue you mentioned?
[16:58] <lcs> +1
[16:58] <kshepherd> hehe +1
[16:58] <stuartlewis> kshepherd: Yup - that's the one ;)
[16:58] <stuartlewis> Thank you all! A pleasure as always :)
[16:58] <richardrodgers> I've gotta go - thanks all
[16:58] * stuartlewis heads off for a mid-morning coffee...
[16:58] <kshepherd> stuartlewis: feel free to just log it and assign to me
[16:58] <lcs> KTHXBYE
[16:58] * richardrodgers (n=richardr@pool-173-76-16-252.bstnma.fios.verizon.net) has left #duraspace
[16:58] <kshepherd> thanks all
[16:59] * lcs (n=lcs@serenity.hul.harvard.edu) has left #duraspace
[16:59] <caryn> thanks, everyone! l8r!
[16:59] * caryn (i=80c8e115@gateway/web/freenode/x-xdzwpgdyqwmnrxzo) Quit ("Page closed")
[17:09] * grahamtriggs (n=grahamtr@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit ()
[17:53] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit ()
[19:26] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[21:19] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.