Timestamps are in GMT/BST.
[6:35] -verne.freenode.net- *** Looking up your hostname...
[6:35] -verne.freenode.net- *** Checking Ident
[6:35] -verne.freenode.net- *** Found your hostname
[6:35] -verne.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:28] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[9:38] * eddies (~eddies@42.61.209.30) has joined #duraspace
[9:38] * eddies (~eddies@42.61.209.30) Quit (Changing host)
[9:38] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[9:51] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[10:24] * eddies (~eddies@42.61.209.30) has joined #duraspace
[10:24] * eddies (~eddies@42.61.209.30) Quit (Changing host)
[10:24] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:02] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:06] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:12] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[12:27] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[12:27] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[12:27] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:55] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:21] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:27] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:29] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[16:50] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 256 seconds)
[17:37] * eddies (~eddies@cm21.eta98.maxonline.com.sg) has joined #duraspace
[17:37] * eddies (~eddies@cm21.eta98.maxonline.com.sg) Quit (Changing host)
[17:37] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[19:54] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Ping timeout: 276 seconds)
[19:54] * kompewter (~kompewter@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[20:01] <tdonohue> Hi all, it's weekly DSpace Developer Mtg time. Today's (rough) agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-05-29
[20:01] <kompewter> [ DevMtg 2013-05-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-05-29
[20:02] <tdonohue> We'll begin with some Pull Request reviews: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:02] <tdonohue> starting today with #163 : https://github.com/DSpace/DSpace/pull/163
[20:02] <kompewter> [ [DS-1083] Create new users from the command line by mwoodiupui · Pull Request #163 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/163
[20:03] <tdonohue> related to DS-1083 obviously
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1083 ] - [#DS-1083] Create new users from the command line - DuraSpace JIRA
[20:04] <mhwood> No comments on the PR, but I think hpottinger was interested?
[20:04] <tdonohue> So, I love the idea here. Haven't had a chance to look at the code
[20:04] <hpottinger> I like PR163, have pulled it into my production repository
[20:05] <tdonohue> so, that sounds like a +1 from hpottinger. The only thing that seems missing is some basic docs (obviously)
[20:05] <hpottinger> I especially like the ability to list users, will make it easier to hunt down null user records
[20:05] <mhwood> I have tested it a bit.
[20:05] <hpottinger> I'm planning to write a small addition which will delete null user records
[20:06] <tdonohue> based on that feedback, I'd be +1 putting this in for 4.0, assuming we can get some docs. We'll get plenty of testing/improvements along the way
[20:06] <hpottinger> oh, yeah, to make it official +1 from me
[20:06] <mhwood> That's two committer approvals. Shall I pull it now or await developments?
[20:06] <mhwood> Of course I will document it.
[20:07] <tdonohue> I'd say put it in now. Though, the *one* clarification I'd like, is your comment around "It's not obvious from the title, but this PR also addresses recent discussion of streaming multiple commands without loading a JVM and DSpace over and over and over"
[20:07] <tdonohue> I wonder if that comment is related to any other JIRA ticket? I.e. we should somehow track that this improvement would also be going in as part of this PR
[20:08] <mhwood> I will see if I can find one.
[20:08] <mhwood> I think it was all on the ML though.
[20:08] * bollini (~chatzilla@host139-236-dynamic.42-79-r.retail.telecomitalia.it) has joined #duraspace
[20:08] <tdonohue> if there isn't a JIRA ticket, I'd suggest we create one (and link to ML discussion, if it's findable). I just want to be sure it is tracked as an improvement for DSpace 4.0
[20:09] <mhwood> WILCO
[20:10] <tdonohue> the band? :) Kidding. thanks mhwood. Just don't want to be wondering years from now when we made this improvement
[20:10] <tdonohue> beyond that, I'd say Pull #163 is ready for 4.0
[20:11] <tdonohue> Next PR on our list... Pull #180: https://github.com/DSpace/DSpace/pull/180
[20:11] <kompewter> [ DS-1432 back button in Discovery broken in Firefox by helix84 · Pull Request #180 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/180
[20:11] * l_a_p (~chatzilla@91.252.50.25) has joined #duraspace
[20:11] <mhwood> Will do so after searching/creating command-streaming issue so I can annotate the pull properly.
[20:11] <tdonohue> mhwood: yep, sounds like a good plan
[20:12] <tdonohue> pull #180 related to DS-1432 obviously
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-1432 ] - [#DS-1432] back button in Discovery broken in Firefox - DuraSpace JIRA
[20:12] <mhwood> Looks unfinished?
[20:13] <tdonohue> yea, I'm guessing unfinished. Will add a comment for clarification
[20:14] <tdonohue> will do one more today: PR #183: https://github.com/DSpace/DSpace/pull/183 (related to DS-1466)
[20:14] <kompewter> [ DS-1466 private items must be excluded in default discovery search by abollini · Pull Request #183 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/183
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-1466 ] - [#DS-1466] withdrawn and private items are indexed in Solr search - DuraSpace JIRA
[20:15] <bollini> this is related to the more widely discussion about item state
[20:16] <bollini> someone has additional comments to add here: https://wiki.duraspace.org/display/~bollini/DSpace+Item+state+definitions
[20:16] <kompewter> [ DSpace Item state definitions - Andrea Bollini - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~bollini/DSpace+Item+state+definitions
[20:19] <tdonohue> hmm...ok, yea, I'm still trying to get my mind around all this
[20:20] <bollini> ok, should we move on waiting for comments from others?
[20:20] <tdonohue> To me, "Private items" seem like AuthZ issues popping up again. Essentially, "private items" in DSpace are difficult cause our AuthZ policies are a bit "all over" (i.e. build into UIs rather than in a "business logic layer")
[20:21] <hpottinger> if anyone makes a "business logic layer" placeholder ticket in Jira, it should have a link to bollini's wiki page
[20:22] <bollini> tdonohue: I'm thinking too about the richard comment "It seems more like a 'hint' to application code"
[20:23] <bollini> actually also "published" (in_archive) and withdrawn are technical hint and not real state. We don't have a getState method or a State ENUM
[20:23] <tdonohue> I'm still not sure I understand why "private items" are a "hint". Doesn't "private" essentially mean they are "access controlled" (i.e. limited access to only specific users/groups)?
[20:24] <bollini> actually private item is a broken functionality
[20:24] * PeterDietz (~peterdiet@dhcp-164-107-110-134.osuwireless.ohio-state.edu) has joined #duraspace
[20:24] <tdonohue> I agree that we don't really have true item "states". Just a bunch of flags.
[20:24] <mhwood> Not really controlled. More like, "we won't tell you it's there, but if you know it is then you can get it."
[20:25] <bollini> we need to decide how to mange it... I think private item as un-discoverable item (as said in the hint of the submission)
[20:25] <bollini> mhwood: exactly, this is also how I understand them (and I see some useful use case for that)
[20:25] <tdonohue> mhwood: but wouldn't that be better called a "hidden item"? (i.e. if you know the full URL, it's actually public...but, it's not easy to get that full URL). Maybe my whole confusion here is that "private" means something very specific in my mind
[20:25] <mhwood> It's really kind of anonymous access for those who know.
[20:26] <mhwood> I agree that I would not have used the word "private".
[20:26] <bollini> just note that the java attribute name is "discoverable"
[20:27] <bollini> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Item.java#L326
[20:27] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/content/Item.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Item.java#L326
[20:28] <mhwood> So this is just making SOLR aware of something we already had?
[20:29] <tdonohue> Right, Discoverable makes more sense to me. It's either easily discoverable, or it's hidden. But, either way, these items are still technically *public* (i.e. they don't require special authorization -- they are just hard to find)
[20:29] <bollini> not only solr... we need a lot of changes to make all things working well
[20:30] <mhwood> The pull, though, seems to be a one-liner dealing with SOLR.
[20:30] <bollini> OAI-PMH needs to be fixed (as we will go to separate discoverable from withdrawn)
[20:31] <bollini> mhwood: yes the pull is really easy it technical work but it is conceptual wrong
[20:32] <mhwood> So do we want to *not* pull it now, but work out a better method?
[20:32] <tdonohue> what part is "conceptually wrong"? Guess I'm still trying to understand which parts *work* and which parts are broken.
[20:33] <bollini> mhwood: I have realized that after to have looked to the https://github.com/DSpace/DSpace/pull/212
[20:33] <kompewter> [ DS-1360 Porting advanced embargo function to JSPUI by helix84 · Pull Request #212 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/212
[20:33] <bollini> tdonohue: my pull request fix the behavior of solr... but actually if you make an item "private" the item is also marked as withdrawn
[20:34] <mhwood> The voices are telling me that discoverable, withdrawn, etc. should be done using finer-grained ACLs, once we have them. That's not a quick path, though.
[20:34] <tdonohue> mhwood : yea, I agree. But, it is definitely not a quick fix
[20:35] <bollini> this is the line that has shown to me our messy https://github.com/DSpace/DSpace/pull/212/files#L0L363
[20:35] <kompewter> [ DS-1360 Porting advanced embargo function to JSPUI by helix84 · Pull Request #212 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/212/files#L0L363
[20:36] <tdonohue> So, is the only thing that uses "Private" items right now the new Advanced Embargo functionality?
[20:37] <bollini> yes, and the edit item in XMLUI
[20:38] <tdonohue> Just wondering in my head why "embargo" even uses "hidden/private items". If something is under embargo, it's *access restricted*. It's true that it also should not be discoverable...but even if it was discoverable, you should not be able to see it unless you have proper authorization.
[20:39] <bollini> it was related to latest introduction of right control in discovery
[20:39] <tdonohue> so, I'm starting to wonder if this whole "isDiscoverable" thing is a *hack* to get around a lack of a good AuthZ system in Dspace. In other words, if we had a "good" AuthZ system, when something is under embargo (or access restricted) it also should not be discoverable via Discovery/REST/OAI/etc.
[20:39] <bollini> if you don't use discovery, or if you don't use discovery for the browse you need private items to avoid inclusion in the browse
[20:40] * PeterDietz (~peterdiet@dhcp-164-107-110-134.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[20:40] <bollini> actually discoverable (as I mean) is more fine grain than READ permission on metadata
[20:40] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[20:41] <bollini> if anonymous doesn't have READ permission on the ITEM discovery already doesn't include the item in anonymous search and browsing (if the SOLRBrowseDAO implementation is used)
[20:42] <bollini> but without READ permission on the item an anonymous user is not able to look the item splash page also if she know the exact url
[20:43] <mhwood> I still wonder why the user cannot just register and be granted permission that others do not.
[20:43] <tdonohue> yea, I understand both those points. But, that second point (looking at an item splash page if you know the exact url), sounds like a *new feature* to me. Which, is why I don't understand what is "broken" currently
[20:44] <bollini> look at the end of this message
[20:44] <bollini> http://sourceforge.net/mailarchive/message.php?msg_id=30862002
[20:44] <kompewter> [ SourceForge.net: DSpace: ] - http://sourceforge.net/mailarchive/message.php?msg_id=30862002
[20:45] <bollini> actually private items are not usable at all... when the item is published it is just accessible to the administrator so what mean private, what add respect to the withdrawn item
[20:47] <tdonohue> bollini: I think the answer to that question is... I though that for embargoes, a "private item" was meant to be an "access restricted item". It's correct that we should NOT be displaying a "withdrawn item" page (it should instead display a page saying "this item is under embargo"). But, at the same point in time, if something is under embargo, you shouldn't be able to get to it by knowing the exact URL (you should always get a
[20:47] * See (5229dd28@gateway/web/freenode/ip.82.41.221.40) has joined #duraspace
[20:48] <bollini> but if the item is under embargo you don't need to mark it as private
[20:48] <tdonohue> So, I'm worried here we are conflating / confusing two different things... Embargoes (which require access restrictions), and this concept of "hidden items" (ones which are not discoverable, but are still accessible if you know the exact URL)
[20:48] <bollini> if you set the policy of the embargo on the bitstream and/or on the item accordly all work well! if you mark the item as private actually you just broke the embarg
[20:49] <bollini> when the embargo is expired on a private item actually you are not able to access it. I don't think that this is working well
[20:50] <tdonohue> oh, yea, that's a bug then. When embargoes expire, the item should be accessible.
[20:50] <mhwood> It should be *accessible*. *Discoverable* seems to be another dimension.
[20:50] <tdonohue> I'm not arguing here that the embargo functionality is "bug free". I'm just arguing that I don't think the definition you provide for "private items" is the same definition that the Advanced Embargo functionality has for "private items"
[20:51] <tdonohue> But, to be clear, I actually *do* like the Item State document you've written, bollini. I think it's great. I just think your definition for "private items" is something that is a *new feature*, and we might want to call it "hidden items" or something to avoid confusion with Embargo
[20:52] <bollini> tdonohue: yes. Sorry probably I'm not clear. I agree with the definition (=hint) of the advanced embargo functionality but this is not what the embargo functionality actually do
[20:53] <bollini> the private flag is not really required by the advanced embargo functionality... we don't need it. Actually it is only a way to mark an item in submission for withdrawning just before publish it. But if this is the intention we should not duplicate the withdrawn flag
[20:53] <mhwood> This is also tangled with differing interpretations of "embargo". Some want it to mean discoverable but not readable; others want it to mean not discoverable or readable.
[20:54] <bollini> we are able to manage discoverable also playing with read permission on the item
[20:55] <tdonohue> mhwood: you might be right. My definition of embargo = "not discoverable nor readable". But, once the embargo period is ended, the item becomes both discoverable & readable (assuming no other limiting access restrictions)
[20:57] <bollini> wait... if you set the item READ permission with a start date you will get what you say without set the private item flag
[20:57] <hpottinger> I've got a Repo Manager following along with this discussion now, and she's proposing that we just drop the "private" flag from the interface on our repository
[20:58] <bollini> this work when discovery is enabled and access right awareness is configurated
[20:58] <tdonohue> bollini: I think I'm better understanding. I'd agree that it seems like "isDiscoverable" may not be needed by the Advanced Embargo functionality, if you can manage the discoverability via read permissions. I guess I wonder why that "isDiscoverable" flag is there then -- is it a "hack" to get around an issue somewhere? Was it a mistake to add?
[20:59] <bollini> most probably it was introduced to hide item also in the browse system... but also this is not really necessary as we now have the SOLRBrowseDAO that is right aware as well
[20:59] * tdonohue sidenote: obviously we're spending the entire meeting on this one topic. I just felt we are having a good & worthwhile discussion here.
[21:00] <tdonohue> bollini: right, that also makes sense. I wonder then if it is a mistake (or whoever added it wasn't aware of the SOLRBrowseDAO)
[21:00] <bollini> so, my final opinion is: we have make a wrong to introduce this flag... now we can decide if we should remove it or make it useful (that is what was described in the embargo hint)
[21:00] <mhwood> So do we really need to fix the browse system?
[21:01] * l_a_p (~chatzilla@91.252.50.25) Quit (Ping timeout: 264 seconds)
[21:02] <bollini> mhwood: sorry, haven't understand your question
[21:03] <mhwood> SOLR browsing works. Traditional browsing doesn't. Do we need to fix traditional browsing so it works like SOLR browsing?
[21:03] <mhwood> Or do we just say, "traditional browsing is broken, if you need this behavior then now is a good time to switch to the new code."
[21:04] <bollini> traditional browsing is not able to support rights awareness but it manages well private items
[21:04] <bollini> same for lucene search
[21:05] <mhwood> Do you mean that traditional browsing cannot be *made* aware of rights?
[21:05] <bollini> rights awareness is out-of-scope of the browse dbms implementations (it will add to much overhead)
[21:05] <bollini> yes
[21:06] <tdonohue> If I'm understanding...I think there are a few intertwined issues here: (1) Advanced Embargo doesn't seem to be working properly in all cases, or there may be some bugs. (2) Advanced Embargo actually may not need to be using the "isDiscoverable" flag. Rather it should be able to manage discoverability via access restrictions (in order to set embargos). (3) We then need to decide if we keep around this "isDiscoverable" flag and
[21:06] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[21:07] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[21:07] <tdonohue> Regarding "traditional browse". We almost replaced the default to Discovery in DSpace 3.0 (but had to revert it). I'd actually suggest we stop trying to support multiple browse options centrally. I'd be much more in favor of supporting Discovery only going forward
[21:08] <mhwood> I think I agree, and I think that "private (nondiscoverable) items" ought to be removed too, until we can do it right.
[21:09] * See (5229dd28@gateway/web/freenode/ip.82.41.221.40) Quit (Quit: Page closed)
[21:10] <tdonohue> In my opinion, the old DSpace concept of "supporting multiple options" for everything is getting to be unsustainable. We just don't have enough active Committers to do so. I'd rather we look towards Committers supporting one *main* option (and if other developers want to build/maintain other "plugins" to provide other options for DSpace, they are welcome to)
[21:11] <bollini> mhwood: sorry, I'm not really in strong favor of a "discoverable" features but... we already have introduced it and it is not like to remove it. And, we are able to manage it properly if we agree about what it means
[21:12] * l_a_p (~chatzilla@91.255.34.174) has joined #duraspace
[21:12] <bollini> tdonohue: I agree. We should move fast to "SOLR" as the only "active" implementation for all our discoverable (search, browse) subsystems
[21:13] <mhwood> So, can we just declare this broken, won't-fix in the traditional browse and concentrate on making the new browse work correctly (whatever that means)?
[21:14] <tdonohue> bollini: I'm OK with redefining what this "isDiscoverable" flag means, but we'd need to do it in stages: (1) first change Embargo to no longer be dependent on "isDiscoverable" flag (2) then, redefine "isDiscoverable" and implement a new feature around it.
[21:14] <hpottinger> looks like I'll have to expedite migration of some old themes to work with Discovery :-)
[21:14] <bollini> mhwood: it is really nothing broken in traditional browse system. There is an usupported feature (rights awareness, but this is documented as you need to enable it explicitly on discovery)
[21:15] <mhwood> Every time I think I understand it, the problem moves.
[21:16] <bollini> tdonohue: the advanced embargo feature is already not dependent on the isdiscoverable flag.
[21:16] <mhwood> I'd better go away and think about it. I need to leave anyway. I'll check the log later.
[21:16] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:16] <bollini> tdonohue: the private items has been put in together with the embargo feature but it is not really related.
[21:16] <bollini> mhwood: bye... sorry to have confused you
[21:16] <tdonohue> bollini: oh, it isn't? For some reason, I thought it was calling the "isDiscoverable" code?
[21:18] <bollini> yes it call the isDiscoverable code because it is the step that enable also the use of this feature. But you don't need to use it to make use of the cool things of the advanced embargo
[21:18] <tdonohue> Right. So, what I meant was that (1) First we need to make sure the Embargo doesn't call the isDiscoverable code anymore. (2) Then we can redefine what "isDiscoverable" means, and create a new feature around it.
[21:19] <tdonohue> My whole issue here is that we cannot just *redefine* "isDiscoverable", if it's being called by the Embargo code. First we need to *fix* Embargo, then we can decide whether we want to keep around "isDiscoverable" (and implement something new), or remove it
[21:20] <bollini> tdonohue: ok we can do that... but there is a sense to make the two features together
[21:21] <tdonohue> I'm not sure I understand the sense in making them together yet.. But, maybe we have a different definition of "embargo"
[21:21] <bollini> in the embargo step you define the permission on the objects (item, bitstream) and we can enable the user to make a more fine grain control on where the item read permission apply (limit metadata access to only direct page)
[21:22] * l_a_p_ (~chatzilla@91.255.34.174) has joined #duraspace
[21:22] <tdonohue> I think one of the things that confuses me still is that you (bollini) haven't defined "embargo" in your "Item State Definitions": https://wiki.duraspace.org/display/~bollini/DSpace+Item+state+definitions I'm not sure how you define embargo, and how you see it as relating (or not relating) to "private items"
[21:22] <kompewter> [ DSpace Item state definitions - Andrea Bollini - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~bollini/DSpace+Item+state+definitions
[21:22] * l_a_p_ (~chatzilla@91.255.34.174) Quit (Client Quit)
[21:23] * l_a_p (~chatzilla@91.255.34.174) Quit (Ping timeout: 264 seconds)
[21:23] <tdonohue> (I also hope we can drop the terminology "private items". I still think that phrase means too much already -- it tends to mean that something is "non-Public", but that's not the same as what is defined in the "Item State Definitions")
[21:23] <bollini> tdonohue: good point! I can add information about embargo items this could help
[21:23] <tdonohue> bollini: yes, I think that would be great help
[21:25] <bollini> tdonohue: I agree too... we should strip out the word "private item" and talk about discoverable (but I need to use it in terminology because we are trying to fix it ;-) )
[21:26] <bollini> tdonohue: my other concern is that if someone has used the private items features as it is now, changing the behavior we will make accessible some item that now are effectively withdrawn
[21:26] <tdonohue> yea, it might be good to clarify then when you are talking about "private item" (as defined by Advanced Embargo), versus the "fixed" version (which is more a "discoverable item" or "hidden item"). Sometimes I find it hard to tell which version we are talking about (Advanced Embargo "private items" or the "non-discoverable items" you are suggesting)
[21:28] <bollini> private item are defined by the Advanced Embargo as the discoverable item... but the advanced embargo don't implement the thing as it says
[21:28] <tdonohue> bollini: I think we'd need a migration path. if someone has used the "private items" as they currently stand, then those would need to be migrated to a more proper "state" (whether that state is "embargoed" or "non-discoverable" or something else)
[21:29] <bollini> the most conservative path could be move "old private item" in the withdrawn state
[21:30] <tdonohue> bollini: I think my question about which version of "private items" we are talking about is related to the fact that I don't fully understand how Advanced Embargo functionality currently implements them, versus how you feel they actually should be implemented
[21:30] <tdonohue> so, it might be worth trying to describe that better somewhere (or at least describe what you understand so far, and others can help too)
[21:31] <tdonohue> but, overall, I do think the "Item State Definitions" document you've written is a great start
[21:31] <bollini> current implementation is just mark the item withdrawn and add an additional flag (so that as administrator you have two separated list)
[21:33] <bollini> the submission step says "Private Item: If selected, the item won't be searchable"
[21:35] <tdonohue> yea, I understand what it says there... but, I think that definition is rather "vague". It could mean either "this item won't be searchable, but you can still access it if you know the exact URL". OR it could mean "this item won't be searchable or accessible to anyone"
[21:35] <bollini> yes... but actually it mean the item will be withdrawn
[21:36] * hpottinger fully intends to remove that checkbox from the interface on our repository
[21:36] <bollini> so if we want that just remove the new flag and use the withdrawn flag (I have avoid to use the private item word :-) )
[21:37] <tdonohue> I think that part may actually be a *bug* (That it ends up "withdrawn"). But, maybe I'm wrong.
[21:38] <bollini> in my definition/proposal we can combine discoverable attribute with read access
[21:38] <tdonohue> Either way though, I agree though that checking that box should *not* withdraw the item.
[21:39] <bollini> so that you can set an item as not discoverable but also not accessible with directly link to other than eperson in specific group
[21:40] <bollini> anyway, sorry to have monopolized the meeting today... I will surely add a definition for how I have understand embargo item to the wiki page. Hope this could help to better understand so that we can make a consensual decision about that
[21:40] <tdonohue> yea, I think this discussion was very helpful. So, it was worthwhile to spend all this time on it
[21:40] <tdonohue> I have to leave here shortly. So, I'm gonna be signing off here in a bit
[21:41] <bollini> it is fairly late in Italy so I'm going to leave too
[21:42] <tdonohue> have a nice evening! Thanks for joining us so late, bollini!
[21:42] <bollini> bye! good night from Italy :-)
[21:42] * bollini (~chatzilla@host139-236-dynamic.42-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803])
[21:51] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
[21:52] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.