Timestamps are in GMT/BST.
[6:46] -verne.freenode.net- *** Looking up your hostname...
[6:46] -verne.freenode.net- *** Checking Ident
[6:46] -verne.freenode.net- *** Found your hostname
[6:46] -verne.freenode.net- *** No Ident response
[6:46] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:46] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:46] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:30] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[12:42] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has joined #duraspace
[13:10] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[13:30] * elschlomo (~fas@HSI-KBW-46-223-224-234.hsi.kabel-badenwuerttemberg.de) has joined #duraspace
[16:07] * elschlomo (~fas@HSI-KBW-46-223-224-234.hsi.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[16:16] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[19:42] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) has joined #duraspace
[19:43] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) has joined #duraspace
[19:48] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:51] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[19:51] <tdonohue> Hi all, reminder the DSpace Devel Mtg is at the top of the hour: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-24
[19:51] <kompewter> [ DevMtg 2011-08-24 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-24
[19:53] * whays (~chatzilla@FEORNESWID.MIT.EDU) has joined #duraspace
[20:00] <tdonohue> Hi all, time for the weekly DSpace Developers Meeting.
[20:00] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-24
[20:00] <kompewter> [ DevMtg 2011-08-24 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-08-24
[20:01] <tdonohue> Today is basically just set aside for more 1.8.0 discussion (things that still need to get in, tickets we need to discuss, whether we are still on-schedule or need to change schedule, etc)
[20:01] <tdonohue> I posted the info that I know on the agenda itself (didn't run this by robint though, so he may have other updates to share) :)
[20:02] <robint> Looked good to me
[20:02] * bojans (~Bojmen@62.68.103.128) has joined #duraspace
[20:02] <robint> Shall I report on the stuff I know about ?
[20:02] <tdonohue> You'll also notice I added a note at the top for areas that we can use help -- mainly Documentation (which is not at all up-to-date), and also looking through JIRA to see if anything else (esp. bugs) can be quickly fixed for 1.8.0
[20:03] <tdonohue> sure, go ahead robint. That's all I had to share right now
[20:03] <robint> DS-749
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-749 ] - [#DS-749] allow for bitstream display order to be changed - DuraSpace JIRA
[20:03] <robint> Commited. Thanks to KevinVdV for the fast work.
[20:04] <robint> DS-994
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:04] <robint> Hardy is still fighting with this. I think he has stumbled across at least one bug in the code.
[20:04] <robint> Needs more investigation.
[20:04] <hpottinger> I'm on track for a revised patch, will be able to post tonight
[20:04] <robint> Good stuff
[20:05] * sandsfish (~sandsfish@18.111.65.163) has joined #duraspace
[20:05] <robint> DS-964
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-964 ] - [#DS-964] Implement Creative Commons Web Service API with the Submission Process - DuraSpace JIRA
[20:05] <hpottinger> wrapping my head around the changes to config styles
[20:05] <robint> Wendy hopes to have a new patch today.
[20:06] <robint> Its quite a big piece of work the CC Rewrite.
[20:06] <robint> Mark Diggory has helped with some XMLUI advice but I may have to call on others for help
[20:06] <tdonohue> but, it sounds like Ds-964 should still be on track for 1.8.0? Or is it 'iffy'?
[20:07] <robint> TBH Dont know until the new patch arrives
[20:07] <robint> But I think it should be ok
[20:07] <tdonohue> ok. sounds good. I can also offer up some help on XMLUI stuff too
[20:07] <robint> And that me done really.
[20:07] <robint> that/thats
[20:08] <robint> Ah, one more !
[20:08] <robint> The Sword guys want to get their new Sword2 module included
[20:09] <robint> Sounds good to me but communication is a bit slow due to time differences and holidays
[20:09] <robint> So we will just have to see how it goes
[20:09] <robint> Done :)
[20:09] <PeterDietz_OSU> I have one that is completed, I just missed on the cutoff deadline. DS-816
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-816 ] - [#DS-816] Order of search types in XMLUI Advanced Search is arbitrary - DuraSpace JIRA
[20:09] <hpottinger> one point I'd like some advice on, robint found the bug that was plaguing me with DS-994, and I think we should open a new issue for it, and patch it separately from 994
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:10] <tdonohue> Yes, it'd be good to get a formal approval on that addition (SWORD2), very soon.
[20:10] <robint> hpottinger: agreed. Although I'm not exactly sure what the bug is yet
[20:11] <robint> tdonohue: I emailed Stuart and Richard today suggesting a workaround for the Maven issues so I'll see what he says
[20:11] <tdonohue> PeterDietz_OSU -- that looks like a bug? If so, it's not missed any deadlines (Deadline was only for new features or improvements). Bugs can still be fixed.
[20:11] <tdonohue> robint: sounds good
[20:12] <hpottinger> robint: I'll open the issue and write it up, the problem is the Shib auth module incorrectly says that users can self-register by it
[20:13] <robint> I notice mdiggory is not here
[20:13] <tdonohue> Ok, I wonder if we should take some time now to talk through Tombstone patches -- DS-587 (and related issue DS-969). This has hit some controversy, but I wonder if we can get a quick consensus.
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:13] <kompewter> [ https://jira.duraspace.org/browse/DS-969 ] - [#DS-969] Add ability to monitor & clear Cocoon's Cache from XMLUI Control Panel - DuraSpace JIRA
[20:14] <tdonohue> ack, I mean DS-587 and DS-996
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-587 ] - [#DS-587] add the capability to indicate a withdraw reason to an item ( tombstone ) - DuraSpace JIRA
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-996 ] - [#DS-996] Add optional reason text to tombstone page - DuraSpace JIRA
[20:14] <sandsfish> note: Richard Rodgers is away at a conference and won't be able to attend/discuss today.
[20:15] <tdonohue> Thanks for the note, sandsfish
[20:15] <robint> Sorry, haven't been following the thread
[20:15] <sandsfish> not to say it shouldn't be discussed of course
[20:15] <robint> Is it possible to summarise the issue(s)?
[20:15] <tdonohue> summary coming... need time to type ;)
[20:16] <mhwood> Discussion seems to be comments on Ds-996
[20:16] <tdonohue> Summary: JSPUI Tombstone Messages/Reasons is a feature supported by DCAT. RichardR took time to try and improve upon the implementation by UMich. Unfortunately, his implemenation has been slightly controversial in some ways...
[20:17] <tdonohue> essentially RichardR has suggested storing a "tombstone reason" in a metadata field (configurable in dspace.cfg). mdiggory opposes this approach, and thinks it should be a database column/field
[20:17] <tdonohue> But, at the same time, we have some other issues going on here -- see my final comment at the bottom of DS-969
[20:17] <kompewter> [ https://jira.duraspace.org/browse/DS-969 ] - [#DS-969] Add ability to monitor & clear Cocoon's Cache from XMLUI Control Panel - DuraSpace JIRA
[20:18] <tdonohue> DS-996
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-996 ] - [#DS-996] Add optional reason text to tombstone page - DuraSpace JIRA
[20:18] <tdonohue> (can't type today)
[20:19] <tdonohue> parts of this work seem non-controversial. But, one area is controversial. So, I wonder how we best move forward for 1.8.0 (do we do the non-controversial stuff, and wait on other stuff...do we accidentally 'do nothing' cause of the controversial piece, etc)
[20:20] <robint> +1 for doing the non-controversial stuff
[20:20] <mhwood> Certainly, if the XMLUI tombstone page could be done quickly without invoking the controversy, that would be good.
[20:20] <mhwood> Then augment it later when we have a decision as to how.
[20:21] <KevinVdV> I am always willing to do the XMLUI tombstone page porting from the JSPUI
[20:21] <tdonohue> yep, that's the essence of it mhwood. That's the approach I'm leaning towards
[20:21] <whays> The XMLUI tombstone page is already submitted as a patch to the ticket.
[20:22] <KevinVdV> Oh missed it
[20:22] <KevinVdV> Sorry
[20:22] <tdonohue> KevinVdV -- Richard Rodgers has already started the XMLUI work -- but, right now it includes both the non-controversial stuff & the controversial stuff. It's at DS-1004
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-1004 ] - [#DS-1004] Add optional reason text to tombstone page (XMLUI) - DuraSpace JIRA
[20:22] <KevinVdV> Yeah just saw it please ignore my comment
[20:22] <KevinVdV> Being over eager again.....
[20:22] <tdonohue> So, the question here is whether we take a step back and just implement a very basic XMLUI Tombstone, and possibly leave the other stuff for post-1.8.0 (until we can figure out a better way to implement it)
[20:23] <tdonohue> it sounds like we have a few folks agreeing with that approach
[20:23] <robint> I think its very very unlikely we will reach consensus on the controversial stuff at this late stage
[20:24] <tdonohue> I agree -- plus, we have no more time to do significant implementation changes
[20:24] <hpottinger> just thought I'd point out that the non-controversial approach will involve a DB change... which means next year, yes?
[20:24] <robint> hpottinger: As things stand, yes
[20:25] <tdonohue> yea, essentially, after 1.8.0, we only have bug fix releases until the next major version (next year). So, no new features until then (whether they change DB or not).
[20:26] <robint> Although its surprising how quickly a year goes by (a sign of age)
[20:26] <grahamtriggs> I need to reply to that thread - I basically have the completely opposite opinion about making it part of the domain.
[20:26] <mhwood> Please do.
[20:27] <tdonohue> feel free to continue the discussion on that thread
[20:27] <tdonohue> just, by default, if we don't reach a reasonable consensus soon, we'll just have to go with a basic XMLUI Tombstone page, and enhance it later
[20:28] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:28] <tdonohue> ok. it sounds like this part is wrapping up...so we can move on to the next thing I had to mention, DS-881
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-881 ] - [#DS-881] DSpace doesn't build properly with Maven 3 - DuraSpace JIRA
[20:28] <tdonohue> (and here's mdiggory!)
[20:29] * mdiggory wonders why his ears were burning
[20:29] <tdonohue> basically, I don't have any updates to give on Ds-881, but I *really* want to get this fixed (it's annoying to be limited to Maven 2.2.x).
[20:29] <mdiggory> What I have is the following...
[20:30] <mdiggory> 1.) removal of the "module" includes from dspace-parent and move of DSpace parent to its own directory
[20:30] <mdiggory> 2.) Move the release assembly descriptors to dspace/src with the other one
[20:31] <mdiggory> 3.) execute both release and assembly from dspace project
[20:31] <mdiggory> This works pretty well in my prototype
[20:31] <mdiggory> for both 2.2 and 3.0
[20:32] <tdonohue> Let me see if I understand all this :) (famous last words)
[20:32] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:32] <tdonohue> 1. We move [dspace-src]/pom.xml to it's own [dspace-src]/dspace-parent/ folder (and remove the <module> stuff from that pom)
[20:33] <tdonohue> 2. we move all the Maven stuff that lets us actually "cut a new release" over into [dspace-src]/dspace/ folder
[20:33] <mdiggory> yes
[20:33] <tdonohue> 3. From that point forward, everything gets executed from [dspace-src]/dspace/ folder (whether you are doing a package or cutting a new release)
[20:34] <mdiggory> correct
[20:34] <robint> Would the dspace-parent folder live in trunk or modules ?
[20:34] <mdiggory> trunk
[20:34] <mdiggory> http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace-parent/pom.xml
[20:34] <tdonohue> That all sounds good to me
[20:34] <mdiggory> It has the dependencyManagement still present in it
[20:35] <tdonohue> One question, would the [dspace-src]/dspace-parent/ folder actually exist in the Source Release (dspace-x.x.x-src-release.zip)? Or would it only be in SVN?
[20:35] <mdiggory> yes, it would exist in the source release
[20:36] <mdiggory> It would be great to completely abolish dspace-parent in favor of dspace-pom, but at this time I'm not sure how to manage the dependencies as a group without it
[20:36] <robint> So there would be no pom in the root directory ?
[20:37] <mdiggory> right
[20:37] <grahamtriggs> What do you mean by cutting the release? There are two (kind of three) spearate things going on - updating the Maven project versions, tagging, etc. - and creating the zip files for re-distribution.
[20:37] <sandsfish> and the one in the dspace folder doesn't change, correct?
[20:37] <robint> Just a daft observation but my IDE complained about that when I tested it
[20:38] <mdiggory> because you didn't select "search subtree for maven projects
[20:38] <sandsfish> robint: what's your IDE, out of curiosity?
[20:38] <robint> IDEA
[20:38] <tdonohue> grahamtriggs: by 'cutting the release' , i meant actually running 'mvn release:*' commands to actually tag the new release & send it off to Maven central
[20:38] <mdiggory> grahamtriggs: the whole thing is run in /dspace
[20:38] <mdiggory> all stages
[20:38] <robint> You can get round the problem easily but I just wondered if there was a better way
[20:38] <mdiggory> each does something different
[20:39] <mdiggory> but all run from that directory
[20:40] <mdiggory> removing the pom also achieves a "checkout only what you need" approach for working with the svn projects
[20:40] <mdiggory> not that it didn't already exist
[20:40] <tdonohue> Currently, when "cutting a release" (mvn release) you have to run it from [dspace-src] (root directory). But, when building DSpace (mvn package), you run it from [dspace-src]/dspace/. Mark is suggesting that we make it so that both are run from [dspace-src]/dspace/
[20:41] <grahamtriggs> What other examples exist of cutting multi-module releases from a peer module, rather than a parent? It's rather illogical for the Maven project hierarchy, and leads to issues like having to use specific options for opening / importing projects into IDEs.
[20:42] <mhwood> Actually I had often wondered why we do the packaging down in dspace (but so far have been too lazy to work it out for myself).
[20:42] <robint> It would be nice if it could be done from a pom at the root of the project. Feels more intuitive.
[20:43] <mdiggory> grahamtriggs: I did a dspace-release peer, that works ok too
[20:44] <mdiggory> http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace-release/
[20:44] <kompewter> [ repo - Revision 6584: /dspace/branches/dspace-async-release/dspace-release ] - http://scm.dspace.org/svn/repo/dspace/branches/dspace-async-release/dspace-release/
[20:44] <sandsfish> robint: i agree. if handed any random maven project, i would expect to be able to run a mvn package in the root. don't know if it's worth shifting things toward this so late in the game though. something to think about though.
[20:44] <tdonohue> So, taking a step back here -- what is the root issue around Maven 3 + DSpace? Is there a simple fix we can apply, and then rework other stuff later as needed?
[20:45] <mdiggory> The problem with the pom at the root of the project is that it is easily confused with dspace/pom.xml
[20:45] <mhwood> Heh, you would be disappointed if you tried to build Cocoon. I never *did* find the place it all builds from.
[20:45] <grahamtriggs> mhwood: currently, it's possible to do a 'mvn package' in the root, and it will build all the modules, and then do the assembly in 'dspace'. 'dspace' doesn't actually need the profile / module definitions that it has, and can take the artifacts from the repository. But the assembly it's doing is something quite specific, and apart from what you would want to do in the parent.
[20:46] <grahamtriggs> mdiggory: That's good to know. But specifically, I would like to know what other projects in the real world have been organised in this fashion, rather than 'is it possible'.
[20:47] <mdiggory> Another point in moving the parent pom is to eliminate reliance upon it over time, to reach a point where add modules can be checked out as sibling directories next to your dspace-xxx projects and easily included in dspace/pom.xml without getting your svn tree confused.
[20:47] <grahamtriggs> tdonohue: yes, there is a simple solution. Remove the profile / modules from the dspace/pom.xml that activate dspace-api, dspace-jspui, etc. if present. You can build across everything by doing 'mvn package' in root, or simply assemble from the artifacts in your local Maven repository by doing the package in 'dspace'.
[20:48] <mdiggory> grahamtriggs: I've encountered bugginess in Intellij when doing this approach, that si why I moved the dspace-parent to its own project
[20:50] <tdonohue> what sort of 'bugginess'? admittedly, grahamtriggs approach does sound simple for 1.8.0 -- although, it sounds like 'mvn package' now would need to happen from [dspace-src] (root folder)
[20:50] <mdiggory> it doesn't detect the dspace-xx projects as present in the filesystem
[20:51] <mdiggory> and thus doesn't add them tot he maven reactor
[20:51] <grahamtriggs> mdiggory: what kind of bugs? I've seen a very occassional issue with it renaming projects, but normally it's fine. And deleting .idea files and re-importing is not especially onorous if needs be, as you should be relying on the definitions within the Maven files, rather than settings directly within IDEA
[20:51] * tdonohue doesn't know what that means, as a NetBeans user
[20:52] <mhwood> Don't look at /me, an Eclipse user.
[20:52] <mdiggory> you know, whatever... every time I come up with a solution recently, it gets bombarded by you guys.
[20:52] <mdiggory> don't you want a better DSpace?
[20:52] <grahamtriggs> I've never had a problem with detecting projects by loading the pom.xml in the root directory. If you are loading it from 'dspace', then maybe I can see why it might have problems activating the profiles
[20:53] <mhwood> I think some want five small solutions that add up, rather than one big one that's harder to grasp.
[20:53] <tdonohue> i'm not taking sides here, honestly. Just looking for *simple* (as we are so late in the game). Either is good by me, or something "in between". At this point, my preference falls to "whatever doesn't drastically change things or confuse people"
[20:53] <mdiggory> no, I think generally, everyone just starts panicing as soon as you suggest moving a file somewhere else
[20:54] <mdiggory> you guys are welcome to provide your own solutions
[20:54] <mhwood> The current way we build stuff just kind of appeared, and I know that I at least don't feel that I fully understand it even after, what, a couple of years?
[20:54] <mdiggory> I proposed mine.
[20:56] <grahamtriggs> Err... I proposed mine in the same email that I first reported the issue with building using Maven 3 on the 14th January....
[20:57] <tdonohue> I can take some time to dig into Ds-881 this week as well, and we can move this discussion to DS-881
[20:57] <kompewter> [ https://jira.duraspace.org/browse/DS-881 ] - [#DS-881] DSpace doesn't build properly with Maven 3 - DuraSpace JIRA
[20:57] <sandsfish> gotta run all.
[20:57] * sandsfish (~sandsfish@18.111.65.163) Quit (Quit: sandsfish)
[20:58] <tdonohue> Since we are nearing the end of our hour here...the big question is: Are we still on schedule for 1.8.0? https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:58] <kompewter> [ DSpace Release 1.8.0 Notes - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:58] <robint> tdonohue: I think so :)
[20:59] <tdonohue> Specifically, are we all still comfortable with a Testathon starting Sept 5 (NOTE: this is Labor Day Holiday in USA)
[20:59] <robint> tdonohue:whats your view ?
[20:59] <tdonohue> The reason I ask, is that we probably need to announce Testathon *at least* a week in advance. One week in advance would be on Monday
[21:00] <robint> tdonohue: Do you think you will be able to pick up the Tombstone stuff ?
[21:00] <mdiggory> grahamtriggs: why didn't you just commit it then
[21:00] * hpottinger is gearing up for an Oracle-backed testathon instance
[21:01] <tdonohue> my view is that we are starting to get to a point where it might be more "comfortable" to think about moving Testathon back a week. (which I know moves everything else back) I worry that we won't have our Documentation all ready (which should preferrably be ready for testathon)
[21:01] <robint> tdonohue: I know what you mean. Could we delay a decision until Friday ?
[21:02] <tdonohue> we can do that. I just wanted to note a concern and see what others thought :)
[21:02] <hpottinger> for entirely selfish reasons, I'd love it if testathon didn't start on my birthday (Sept 5) :-)
[21:02] <robint> I suspect I am in denial :)
[21:03] <tdonohue> List of things left to be done before testathon: announce testathon, stabilize code (seems stable though), get a first draft of all docs done, Release 1.8.0RC1, update demo.dspace.org with RC1, get other test instances as necessary
[21:03] <robint> hpottinger: As good a reason as any !
[21:04] <tdonohue> most of this isn't too bad... but our documentation is sorely lacking. I'm not sure all new features have docs yet, and our Configuration docs are all wrong now (with the config file changes), and we haven't started Update or Install docs yet
[21:05] <tdonohue> just wanted to note this all :) (not trying to complain, just being realistic about where we are at)
[21:05] <robint> tdonohue: If you think it would be advisable to make the decision now then let do it
[21:06] <tdonohue> we can wait until Friday. If we make some headway before then, we may be fine. But, if not much has been changed, we may want to push back
[21:06] <robint> I would till be keen to not delay the feature freeze much longer
[21:06] <tdonohue> obviously we're over time here. So, best to wrap this all up for today. Any parting thoughts?
[21:06] <robint> So that any extra time would be used for the things you list
[21:06] <tdonohue> robint: agreed
[21:07] <robint> Thanks to KevinVdV and hpottinger for the extended working hours !
[21:07] <tdonohue> sounds like we're done for today then. I'll hang out a bit if anything comes up. But, feel free to head out if you need to
[21:08] <tdonohue> yes, thanks KevinVdV & hpottinger for the hard work on these last few features
[21:08] <mhwood> Gotta go. Thanks, everyone!
[21:08] <robint> hpottinger: Back to DS994
[21:08] * mhwood (~mhwood@2001:18e8:3:10ab:21e:4fff:feba:a425) has left #duraspace
[21:08] <robint> I'm not sure ShibAuthentication should return false
[21:09] <hpottinger> for canSelfRegister?
[21:09] * whays (~chatzilla@FEORNESWID.MIT.EDU) has left #duraspace
[21:09] <robint> yeah
[21:10] <robint> Its strangely named method
[21:10] <stuartlewis> It also duplicates the dspace.cfg settings about can self register.
[21:10] <stuartlewis> So some authN methods, like shib and ldap, always return true, but handle that logic in the authenticate() method.
[21:10] <KevinVdV> Signing off see you guys later
[21:10] <grahamtriggs> mdiggory: I asked for comments, and someone came back with an alternative proposal!!
[21:11] * KevinVdV (~KevinVdV@d54C156FD.access.telenet.be) Quit (Quit: KevinVdV)
[21:12] <hpottinger> I've changed it to return false, and my patch for DS-994 works, stuartlewis, what does ldap return for canselfregister?
[21:12] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[21:12] <robint> grahamtriggs: Could you post your alternative proposal to Jira so people can compare at liesure ?
[21:13] <stuartlewis> return ConfigurationManager.getBooleanProperty("authentication-ldap", "autoregister");
[21:13] <robint> hpottinger: I think the problem is that AuthenticationManager.canselfregister checks them all at once
[21:14] <stuartlewis> robint - yes, sounds likely.
[21:14] <hpottinger> robint: yes, and any true is considered good enough
[21:14] <stuartlewis> The authentication stack isn't good at separating out which bit of config applies to which authN method, and only applying the correct one.
[21:14] <robint> If the user is going to authenticate using using passowrd authentication then ...
[21:15] <robint> the fact that they can selfregister using ShibAuthentication shouldn't come into it
[21:15] <robint> Note:- I'm making this up as I go along !
[21:15] <stuartlewis> Yep - that's correct.
[21:16] <robint> Not sure how easy it is to split this stuff up though
[21:17] <hpottinger> I was unsure of a "proper" solution, but I do know that there's no such thing as a way to self-register via Shib, so figured returning false for that method was accurate, and happened to help me
[21:17] <stuartlewis> Do you have both password and shib authN options enabled?
[21:17] <hpottinger> yes, we do, stuartlewis
[21:18] <robint> Comments from the code, aplogies for the length...
[21:18] <robint> Doh! Won't paste properly
[21:18] <hpottinger> Shib for campus auth, password for everything else (visiting folks, or "just because")
[21:19] <robint> Look at the comments for canselfregister in AuthenticationMethod
[21:19] <robint> I think all Shib people do 'selfRegister'
[21:19] <robint> So true is the correct return value
[21:20] <robint> selfRegister just appears to mean that an admin doesn't have to define you as an eperson
[21:20] <hpottinger> ah
[21:20] <robint> and that is true for people using Shib
[21:20] <hpottinger> gulp
[21:21] <robint> the eperson rec will get created aautomatically when they first login
[21:21] <robint> ... I think
[21:21] * grahamtriggs new game - lets make hpottinger gulp....
[21:22] <hpottinger> this is correct, and I am drinking tea
[21:22] <robint> The problem is that if the person logging in will not, or could not, use Shib
[21:22] <robint> then AuthorisationManager shouldn't be checking to see what ShibAuthentication returns
[21:23] <robint> Its that darn loop in AuthenticationManager.caanselfregisster
[21:24] <robint> Don't know what the fix is though :)
[21:25] <hpottinger> hmm... as it stands now, does the canSelfRegister method on PasswordAuthentication actually work?
[21:26] <robint> Yes, if its not part of a stack
[21:26] <robint> My guess is they all work individually
[21:28] <robint> That is each implementer of AuthenticationMethod
[21:29] <robint> At this point my knowledge gets sketchy
[21:30] <robint> If you have a stack does the user always get presented with a list of methods to choose from ?
[21:30] <grahamtriggs> Right, well, if we're going to solve this, you need to [be able to] define a source for each of the authorization rules
[21:30] <robint> Or does it fall through the stack ?
[21:30] <robint> Explain more G ?
[21:31] <grahamtriggs> the authorization rules need to be tied back to an authenticationmethod, or be marked as manually assigned. That way, we can always update the authorization rules associated to any specific authenticationmethod whenever someone logs on via that method
[21:32] <grahamtriggs> but logging on via Shibboleth (for example) wouldn't then clear out any other rules created via other means (ie. manually)
[21:33] <robint> I'm getting out of my depth :)
[21:35] <robint> Very sorry but I'm going to have to duck out now. We can resume again tomorrow. Cheers
[21:35] * robint (5229fe9f@gateway/web/freenode/ip.82.41.254.159) Quit (Quit: Page closed)
[21:35] <hpottinger> grahamtriggs that would address the problem that DS-994 is attempting to address, it would not address this as-yet-to-be-reported issue with canSelfRegister and the implicit OR logic of the loop in the stackable auth
[21:35] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[21:50] <hpottinger> so, I'm thinking the way past this is to perhaps change the logic that's allowing selfregistration for password to not use authentication manager's canSelfRegister method, but instead use the canSelfRegister method for the password module
[21:53] <grahamtriggs> although changing the authorization rules representation is a database change, and fixing the logic / configuration of the authentication methods isn't - which means that either needs to be addressed now, or wait a year. The logic fixes can happen in a bug fix release.
[21:53] <hpottinger> my brain is trying to tell me I should be looking at flowscript for XMLUI, and I'm out of my depths for JSPUI
[21:57] <hpottinger> grahamtriggs, I think I'm hearing that we don't really need these new rules for password auth, and can tackle the real issue identified in Ds-994 in any release, new or bugfix
[21:58] <PeterDietz_OSU> grahamtriggs I'm planning to merge Robert's GSOC changes into webmvc trunk some time this week. I've already left my final eval in the gsoc app.
[22:01] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:13] <hpottinger> grahamtriggs, I'm thinking I'll make two new issues, one regarding the problem with authorizations being lost when using mixed authentication methods, and another a new issue for the problem with AuthenticationManager's canSelfRegister method, I think you're right
[22:14] <hpottinger> Ds-994 can then be closed
[22:15] * bojans (~Bojmen@62.68.103.128) Quit (Remote host closed the connection)
[22:20] * hpottinger has to go, another appointment, thanks folks!
[22:21] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[22:34] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[22:53] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[23:32] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.