Timestamps are in GMT/BST.
[1:32] * peterdietz (uid52203@gateway/web/irccloud.com/x-oitrlhwzdizzxqjo) Quit (Quit: Connection closed for inactivity)
[6:34] -weber.freenode.net- *** Looking up your hostname...
[6:34] -weber.freenode.net- *** Checking Ident
[6:34] -weber.freenode.net- *** Found your hostname
[6:34] -weber.freenode.net- *** No Ident response
[6:34] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:34] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:34] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:52] * kostasp (5e44ebe6@gateway/web/freenode/ip.94.68.235.230) has joined #duraspace
[12:17] * kostasp (5e44ebe6@gateway/web/freenode/ip.94.68.235.230) Quit (Quit: Page closed)
[13:30] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:56] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[15:35] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) has joined #duraspace
[18:15] * peterdietz (uid52203@gateway/web/irccloud.com/x-wvjorucmumympfsb) has joined #duraspace
[19:41] * hpottinger (~hpottinge@mu-162188.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[19:55] * mdiggory (~mdiggory@cpe-76-176-128-229.san.res.rr.com) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-02-18
[20:01] <kompewter> [ DevMtg 2015-02-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-02-18
[20:01] <tdonohue> semi-small crowd today it seems...but hopefully others will pop in shortly ;)
[20:02] * cknowles (~cknowles@cpc67742-sgyl32-2-0-cust219.18-2.cable.virginm.net) has joined #duraspace
[20:02] <tdonohue> First and foremost though, mostly a reminder that the plan for DSpace 5.1 is to release by end of this week, and announce on Monday (Feb 23). I *think* we are mostly still on schedule with various fixes that need to go in.
[20:03] <tdonohue> I plan to cut the release on Friday though. So, if there's anything you are aware of that NEEDS to be in 5.1, and isn't ready or needs more eyes, please let myself (and committers) know
[20:04] <tdonohue> And in the agenda, I did note yet again that it looks like we need help in fixing the LDAP plugin for DS-2421. So, if you have a local LDAP & some time, please feel free to volunteer
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2421 ] - [DS-2421] LDAPAuthentication Plugin only supports auto-registration for Hierarchical LDAP settings - DuraSpace JIRA
[20:05] <tdonohue> Anything else folks want to mention regarding 5.1?
[20:06] <tdonohue> Ok, hearing nothing...guess we move along. If there are any outstanding questions/concerns though, please do get in touch
[20:08] <tdonohue> Next up, I wanted to give a "final call" for Google Summer of Code ideas/mentors. As of yet, it seems like we don't have much interest (that I've heard) amongst DSpace Committers. But, if I'm mistaken, please feel free to correct me :) Or of anyone has comments on GSoC in general
[20:09] <peterdietz> Excitement and interest. I haven't settled on a single focused project I'd want to shepherd though
[20:10] <peterdietz> I do have a busy schedule this summer though already. So a bit limited in ability to help
[20:10] <peterdietz> ...which is not a great recipe
[20:10] <tdonohue> To be clear, at this point in time, I do NOT plan to submit an application on behalf of DSpace/DuraSpace. No other DuraSpace projects (Fedora, VIVO, DuraCloud) plan to take part. As interest is lacking here too, it seems like it's a year to "sit this one out"
[20:10] * kohts (~kohts@141.124.158.98.client.dyn.strong-in23.as13926.net) has joined #duraspace
[20:11] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:11] <aschweer> I did put my name down for one of the ideas, but I will probably have very limited bandwidth for mentoring also. So sitting this one out sounds fair enough to me.
[20:11] <tdonohue> any last comments on GSoC?
[20:12] <tdonohue> ok, thanks aschweer
[20:13] <tdonohue> Those were essentially the two main topics on our agenda for today. At this point, I'd like to open up the floor to any other topics you all want to discuss?
[20:14] <tdonohue> Wow, don't everyone jump at once ;)
[20:14] <tdonohue> we are a very quiet group today it seems (or very distracted)
[20:15] <kohts> Hello everyone, if I'm the only one with the topic, I would appreciate if we could discuss once again the batch changes of permissions of the items.
[20:16] <tdonohue> kohts: sure, is there a ticket which references this (to refresh us)? Or would you be willing to summarize?
[20:16] <cknowles> Hi, can I please encourage everyone to submit to the Dev Track at OR15 :)
[20:17] <tdonohue> cknowles: definitely! Also, has an email gone to dspace-devel about it yet?
[20:17] <aschweer> cknowles: working on it :)
[20:18] <tdonohue> More on the new Dev Track at OR15: http://www.or2015.net/developer-track/
[20:18] <kompewter> [ Developer Track at OR2015 | OPEN REPOSITORIES 2015 ] - http://www.or2015.net/developer-track/
[20:18] <cknowles> One has definitely gone to general and tech, shall I send to dev as well?
[20:19] <cknowles> aschweer :)
[20:19] <tdonohue> cknowles: yea, you may want to, as it's our official developers list. Chances are those folks should also be on -tech or -general, but you never know
[20:19] <cknowles> ok will do
[20:20] <kohts> Sure, few words about my task/problem: I need to change access permissions to several items in my repository at once (at least all the bitstreams of one item), and I would need to do this on a regular basis. I could definitely do this by running SQL queries against Postgres database, but that doesn't seem to be a good solution (it's not durable, it probably will break once dspace evolves,
[20:20] <kohts> it would be hard to teach other people to do it, etc.) So basically I need support of the feature in DSpace. I could do some development (PR) but not a lot - Java is not my primary language and I really won't have a lot of time for this. I'm trying to understand what would be the most effecient way to address this problem. I will follow up with several ticket in Jira, just a moment
[20:20] <kohts> (sorry for a long message)
[20:21] <peterdietz> Sounds like wanting to recursively apply permissions to a whole collection
[20:22] <aschweer> I have curation tasks for this sort of thing -- for "my" repositories, the requirements are quite specific (and different for each institution)
[20:24] <tdonohue> There is also the built in "Item wildcard policy admin tool" (off the "Administrative" menu -> "Authorizations"). The tools is clunky, but it does work to do bulk permission changes on Items or bitstreams
[20:24] <peterdietz> There's a couple of variations on this problem. Another is wanting to make the bitstreams of an item openly accessible. Or, changing an open item (or closed) to be accessible to a particular group. The current process involves lots of clicking
[20:25] <peterdietz> hmm, yeah wildcard is pretty powerful.
[20:26] <tdonohue> In general here, I do agree it'd be nice to build more tools (UI Admin tools, or Curation Tasks) to ease the management of permissions (in bulk). If anyone has any code they think could be advantageous to other institutions, we might want to consider whether it could be made "generic" enough to add to DSpace for everyone
[20:27] <peterdietz> ...and vice versa. If someone has generic enough use-cases on the subject. It might help to formalize/finalize an approach
[20:27] <mhwood> I suspect that many uses of bulk permission editing would evaporate if we had dynamic permission inheritance instead of static. But tools would still be quite useful in more complex cases.
[20:27] <aschweer> totally agree. I know usually I'm all "let's see what the use cases / roadmap say" but I'm pretty sure handling permissions on all DSpace objects is going to stay important no matter what :)
[20:27] <tdonohue> +1 peterdietz, generic enough use cases could start to be gathered on the wiki. Then we could work to build a tool based on those use cases
[20:29] <kohts> Thanks for the comments, very useful, especially for the admin tool, I will check it out. In the meanwhile, here's Jira issue: https://jira.duraspace.org/browse/DS-2028 It's not directly about the problem, but if I understand correctly there's an underlying architectural problem with doing one thing with (all the items|some number of items): current class methods try to fetch/cache every
[20:29] <kohts> item, which becomes a serious bottleneck for a big repo, on the other hand we do want to apply all the item/bitstream business logic to an item and don't want to modify database directly aside from the standard class methods -- so making a simple patch doesn't seem to be as simple as it might look at the first glance
[20:29] <kompewter> [ [DS-2028] Suppress items without anonymous access from the sitemap - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2028
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-2028 ] - [DS-2028] Suppress items without anonymous access from the sitemap - DuraSpace JIRA
[20:31] <mhwood> One problem we have with large operations is indeed caching. We need to limit the size of some of the caches in Context. It makes little sense to cache 100,000 objects if the server grinds to a halt due to thrashing.
[20:32] <mhwood> Or runs out of heap.
[20:33] <kohts> Personally I like the idea of gathering uses cases on the wiki - I could start this page with my use case: consider an archive of a scientist (gone) where some documents were created by him and we know we could publish them openly, and there are items which are correspondence of this person with other people, some of them might even be alive, so we're not sure whether we are allowed to make
[20:33] <kohts> them public. But once other parties who participated in creation of the item are contacted and give their permission - related item(s) could be published. One item could consists of several tens of files (heap of letters).\
[20:33] <tdonohue> kohts: have you seen the gathering of various DSpace Use Cases here? https://wiki.duraspace.org/display/DSPACE/Use+Cases
[20:34] <kompewter> [ Use Cases - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Use+Cases
[20:34] <peterdietz> That might be embargo use-case
[20:34] <tdonohue> It's a rather large list, but it might be worth adding your use cases to that list...we plan to have someone analyze it in the near future to develop a "long term roadmap" for DSpace on how it could start to achieve some of those more popular use cases
[20:35] <aschweer> My curation task for that use case is: https://github.com/lconz-irr/Curation-Tasks/blob/lconz-curation-tasks-4.6/src/main/java/nz/ac/lconz/irr/curate/task/ProtectSensitiveBundles.java -- we're scheduling the task on every bitstream change event via an event consumer
[20:35] <kompewter> [ Curation-Tasks/ProtectSensitiveBundles.java at lconz-curation-tasks-4.6 · lconz-irr/Curation-Tasks · GitHub ] - https://github.com/lconz-irr/Curation-Tasks/blob/lconz-curation-tasks-4.6/src/main/java/nz/ac/lconz/irr/curate/task/ProtectSensitiveBundles.java
[20:35] <mhwood> A powerful, efficient way to modify permissions in bulk mostly boils down to a powerful, efficient way to identify the objects of interest. After that it's just walking a list.
[20:36] <mhwood> So, how do you identify the problematic letters?
[20:36] <mhwood> Mechanically.
[20:36] <aschweer> for us, I've set up a new bundle called "Evidence", and have added functionality for admins to move bitstreams between bundles.
[20:36] <aschweer> so it's the repo admins' responsibility to figure out which bitstreams are sensitive and to move them into that bundle
[20:37] <aschweer> (well plus I've written a custom submission step that lets people upload into the evidence bundle directly)
[20:37] <kohts> tdonohue: will have a closer look at the use cases, thanks
[20:37] <aschweer> then my curation task applies the permissions according to the bundle name (original is public, evidence isn't)
[20:38] <aschweer> now that we have metadata for all, maybe there could be better mechanisms (especially if we eventually want to get rid of bundles)
[20:38] <mhwood> +1 bundles must die!
[20:38] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[20:38] <kohts> mhwood: I would say generally it's an manual procedure, and there's quite a number of items in the repo, so I plan to make all (almost all of them) closed for the public and then enable one by one -- but I really don't want to make it for every bitstream, because usually the decision could be made on an item level.
[20:38] <aschweer> mhwood that's not what I said ;) but yes I do use bundles as "tags" mainly
[20:39] <mhwood> OK. I have yet to see an application in which Bundles actually *contain* anything.
[20:39] <kohts> talking to you now I actually see that even the possibility to modify all of the bistreams for 1 item would solve my original problem
[20:40] <aschweer> mhwood: maybe in the versioning? but even there really the relationship is between bitstreams and items
[20:41] <mhwood> Exactly. Bundles are labels, and it is strange that we can't paste more than one label on a bitstream.
[20:41] <aschweer> kohts: maybe ask on the -tech list whether anyone has a scripted curation task for this (since Java isn't your favourite language)?
[20:42] <aschweer> mhwood well theoretically a bitstream can be in more than one bundle. Just good luck with nothing breaking in the code if you actually do that.
[20:42] <peterdietz> In REST API I didn't model bundles. Items have bitstreams, and bitstreams belong to items. (Aside from collection logos)
[20:42] <kohts> aschweer: I don't like the idea of curation tasks for two reasons: 1) it happens somewhere behind the scenes; I would like to have the control right in the UI 2) don't want custom code in my dspace installation, I have no resources to support it
[20:43] <aschweer> I have this curation task here to copy community policies down to their child collections, maybe it could be adapted to transfer to items: https://github.com/lconz-irr/Curation-Tasks/blob/master/src/main/java/nz/ac/lconz/irr/curate/task/CopyCommunityPoliciesToCollections.java
[20:43] <kompewter> [ Curation-Tasks/CopyCommunityPoliciesToCollections.java at master · lconz-irr/Curation-Tasks · GitHub ] - https://github.com/lconz-irr/Curation-Tasks/blob/master/src/main/java/nz/ac/lconz/irr/curate/task/CopyCommunityPoliciesToCollections.java
[20:43] <aschweer> kohts: fair enough -- just if it's a one-off, it might be useful as a curation task. remember that you can invoke curation tasks in the UI. As to custom code, just convince us to add something like my curation tasks to standard DSpace ;)
[20:44] * hpottinger still catching up, but the wildcard policy admin tool is a bit "funky" in its vagueness, people invest it with their hopes and dreams and end up being disappointed
[20:44] <mhwood> hpottinger: can we characterize the disappointment? So we can fix it?
[20:44] <aschweer> yes the wildcard policy admin tool has some room for improvement it feels like (I actually don't use it, I just write curation tasks)
[20:45] <peterdietz> One example curation task I've done is to extract mp3 duration from the file, and stuff into item metadata. Way easier to do in Java, then hacking with SQL. Its clean, portable. Could be contributed upstream, and eventually no longer being my responsibility (but community asset)
[20:45] <tdonohue> The wildcard policy admin tool needs better explanation & docs. It also tends to require several steps...often you have to (1) Remove existing access rights, and then (2) Add new, correct access rights. So, it's often at least a two step process
[20:46] <aschweer> for "my" repo managers, it always feels like resource policies don't mesh with how they think, maybe because they are "allow" logic not "deny" logic. While moving to an evidence bundle, they have no trouble remembering that even when they only do it once every half year. Maybe that's just because it's one step vs many.
[20:46] <helix84> hi, sorry I'm late, I just wanted to say that I'd volunteer as a GSoC mentor
[20:48] <hpottinger> I think the disappointment comes in with the wildcard tool in that it only applies to items, and many times other policies want changing (collection and community defaults, mostly) and then you walk into the whole "policiies only inherit on item submission" trap, and... disappointment
[20:48] <aschweer> yes, I think inheriting policies comes up on dspace-tech a lot, and that's when people are pointed to the wildcard tool
[20:49] <cknowles> "policiies only inherit on item submission" trap - often catches our repo admins out
[20:49] <kohts> tdonohue: 2 steps process is fine for me, it's indefinitely better than N steps process where N is the number of bitstreams in the item...
[20:49] <aschweer> to me it sounds like functionality to propagate policies down would be good, as would a way of identifying items whose policies aren't what they would be if they were archived now
[20:50] <hpottinger> "people chang their minds" about policies, we need a tool to let them change the policies
[20:50] <hpottinger> aschweer++ far more articulate than I
[20:50] <aschweer> I've heard some unhappiness that the DSpace admin help pages aren't in XMLUI (from repo admins who started on JSPUI). Most screens are pretty self explanatory, but the wildcard tool for sure isn't
[20:51] <aschweer> thanks hpottinger, and here I was worrying about my English ;)
[20:51] <hpottinger> just finding the tool is an adventure
[20:52] <helix84> cknowles: just an early heads-up - I might have a submission for dev track, still have to write it all down
[20:52] <hpottinger> I *think* there is a JIRA issue that wrangles all this up, actually
[20:53] <cknowles> helix84 - that’s great.
[20:53] <hpottinger> DS-1119 now closed
[20:53] <kompewter> [ https://jira.duraspace.org/browse/DS-1119 ] - [DS-1119] xmlui "wildcard policy admin tool" does nothing - DuraSpace JIRA
[20:54] <kohts> as a side note: the best in my opinion policy management I've seen is in Windows (sorry): it's quite flexible and user generally might understand how it works. The approach boils down to the following rule: item (directory or file) inherits permissions unless custom permissions are set for it. Also there's a special button (tool) to propagate permissions from the given item down to all the
[20:54] <kohts> children items overriding (destroying) their custom permissions. DSpace kinda has similar approach but it feels like it's not finalized.
[20:55] <kohts> (not sure I should have explained Windows permissions here so badly, but just in case there're people who haven't worked with Windows)
[20:55] <mhwood> I agree that permission inheritance is one of the things that the Windows crew got very right.
[20:56] <mhwood> I think many people expect permissions to always work that way and are puzzled when they don't.
[20:56] <hpottinger> that's part of the issue, DSpace is *close* to the Windows behavior, during the submission process... and then... nevermore
[20:56] <helix84> kohts: regarding what you said earlier, if you need it addressed before a systematic solution is developed and released, you may want to consider writing a curation task in jython, groovy or jruby (which has potentially faster build cycle than java), see https://wiki.duraspace.org/display/DSDOC5x/Curation+System#CurationSystem-ScriptedTasks
[20:57] <kompewter> [ Curation System - DSpace 5.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC5x/Curation+System#CurationSystem-ScriptedTasks
[20:57] <tdonohue> It seems like we have several ideas/threads here (similar in nature) but we might want to boil them down into either a JIRA ticket (or two), or Use Cases (if it's still just an early idea)
[20:57] <peterdietz> /dspace/bin/dspace chmod 777 -i 123456789/45
[20:57] * tdonohue just wants to be sure to find a way to track the ideas here, so they are not forgotten
[20:57] <aschweer> tdonohue++
[20:57] <mhwood> Static vs. dynamic. DSpace copies permissions onto the child object. Windows climbs the object tree each time it wants to check permissions, until it finds a policy that applies to this type of object.
[20:58] <tdonohue> peterdietz: wow, a 'dspace chmod' ;)
[20:58] <aschweer> the hierarchy climbing would be interesting with items mapped into a collection with different permissions. but I guess there are ways of dealing with that in file systems too (symlinks)
[20:58] <aschweer> well I think we want chmod -R :)
[20:59] <tdonohue> of course
[20:59] <hpottinger> mhwood: that's the heart of the matter right there, the choices Windows makes are appropriate for various objects an OS might encounter, but the rules are different for a repository
[20:59] <hpottinger> watch that executable bit, though, peterdietz
[20:59] <tdonohue> So, is there anyone(s) who'd be willing to take the task of creating a JIRA ticket (for bulk policy editor, if needed, or a new curation task) and/or start up some Use Case docs?
[21:00] <tdonohue> (I know "anyones" isn't a real English word, by the way)
[21:00] <helix84> chmod is not good enough for us, we need ACLs. ACLs are hard. Is there a library we can leverage?
[21:00] <aschweer> helix84: can we start with the use cases before the technology please? (ha I got to trot that line out again)
[21:01] <tdonohue> helix84: "there's a ticket for that" (but no ideas yet): DS-2041
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-2041 ] - [DS-2041] Use ACLs not code to control object visibility in sitemaps, RSS, etc. - DuraSpace JIRA
[21:01] <hpottinger> helix84: aha, the old "let's change AuthN and AuthZ to something standard" idea, I like it.
[21:01] <mhwood> Google comes up with some interesting hits for "java acl framework"
[21:01] <kohts> tdonohue: I could definitely document my use case and the "ideal" solution as I see it, if you think it would help
[21:01] <mhwood> That one is not really authnz; it's access control.
[21:02] <tdonohue> kohts: I think it could help. You may want to read through some of the existing similar use cases (around authorization or embargo) as well, to see if they can just be enhanced to also describe yours
[21:05] <tdonohue> So, I'm realizing we're now to the end of our meeting (and unfortunately I have to step away for a moment). If anyone is willing to start up even a JIRA placeholder (assuming 2041 isn't "good enough") for this discussion/summary, it might help us keep this on the radar
[21:05] <hpottinger> I have an internal ticket for working on the wildcard policy admin tool at some point, in my notes I see that mdiggory mentioned in December of 2011 that they had done some prior work in this area
[21:05] <kohts> tdonohue: ok, I got your idea. I'll try to do it. I actually tried to do it before - but it was a bit hard since currently DSpace permissions are somewhere inbetween of somewhere... (look like Windows on submission, but not after; there're also bugs which break permissions and it's hard to understand whether it is be design or a bug indeed - not ranting, just stating that I tried and it was
[21:05] <kohts> no easy task).
[21:05] <tdonohue> hpottinger: could you copy your internal ticket over into our JIRA ;)
[21:05] <kohts> s/be design/by design/
[21:05] <kompewter> kohts meant to say: tdonohue: ok, I got your idea. I'll try to do it. I actually tried to do it before - but it was a bit hard since currently DSpace permissions are somewhere inbetween of somewhere... (look like Windows on submission, but not after; there're also bugs which break permissions and it's hard to understand whether it is by design or a bug indeed - not ranting, just stating that I tried and it was
[21:05] <hpottinger> it's a Trac ticket, but I'd happily transfer notes
[21:05] <aschweer> sorry everyone, I need to leave. I can try and find some time to contribute our use cases if someone makes a start.
[21:06] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:06] <hpottinger> it sounds like kohts is volunteering to write the JIRA issue?
[21:08] <tdonohue> kohts said he'd do a Use case (over in https://wiki.duraspace.org/display/DSPACE/Use+Cases)
[21:08] <kohts> hpottinger: I would really like to start with use case in wiki if no one minds; we could copy it to jira if it looks fine afterwards? (wiki seems to be a more relaxed place for me, while JIRA seems to oblige people to "solve" anything input into it)
[21:08] <hpottinger> related issues: DS-510, DS-520, DS-908
[21:08] <kohts> tdonohue: right
[21:08] <kompewter> [ https://jira.duraspace.org/browse/DS-510 ] - [DS-510] Streamline UI for community/collection role assignment - DuraSpace JIRA
[21:08] <kompewter> [ https://jira.duraspace.org/browse/DS-520 ] - [DS-520] Allow for bulk/mass authorization/policy changes on items/bitstreams - DuraSpace JIRA
[21:08] <kompewter> [ https://jira.duraspace.org/browse/DS-908 ] - [DS-908] Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace - DuraSpace JIRA
[21:08] <tdonohue> I was asking for a JIRA ticket about anything more immediate (e.g. changes to wildcard policy tool that might be good "quick fixes", etc)
[21:11] <hpottinger> tdonohue: I can make that ticket
[21:12] <tdonohue> thanks!
[21:13] <kohts> thanks for the discussion, seems really useful for me
[21:13] <tdonohue> thanks too for bringing it up!
[21:13] <tdonohue> The meeting is now officially closed (cause I need to step away for a bit). But, I will be back later if anyone has post-meeting topics to discuss. Thanks all!
[21:14] <hpottinger> silly question: is this tool XMLUI-only, or is there another similar tool in the JSPUI?
[21:14] <kohts> I would follow up with my use case and let you know (several weeks though, to be realistic)
[21:18] * cknowles (~cknowles@cpc67742-sgyl32-2-0-cust219.18-2.cable.virginm.net) has left #duraspace
[21:21] <mhwood> Back to dspace-vagrant: this poor noob is now looking at "Verify SSH connection to GitHub works?" and wondering how it ever succeeded.
[21:26] * kohts (~kohts@141.124.158.98.client.dyn.strong-in23.as13926.net) Quit (Quit: gotta go)
[21:28] <hpottinger> mhwood: you're in the logged channel ;-)
[21:31] <hpottinger> DS-2460
[21:31] <kompewter> [ https://jira.duraspace.org/browse/DS-2460 ] - [DS-2460] wildcard policy admin tool should be easier to find, and should work for collections and coummunities as well as items and bitstreams - DuraSpace JIRA
[21:32] <mhwood> 2460 looks good to me. Thanks!
[21:33] <hpottinger> look at this pile of related issues: DS-510, DS-520, DS-909, DS-1119
[21:33] <kompewter> [ https://jira.duraspace.org/browse/DS-510 ] - [DS-510] Streamline UI for community/collection role assignment - DuraSpace JIRA
[21:33] <kompewter> [ https://jira.duraspace.org/browse/DS-520 ] - [DS-520] Allow for bulk/mass authorization/policy changes on items/bitstreams - DuraSpace JIRA
[21:33] <kompewter> [ https://jira.duraspace.org/browse/DS-909 ] - [DS-909] Collection DEFAULT_ITEM_READ and DEFAULT_BITSTREAM_READ handling - DuraSpace JIRA
[21:33] <kompewter> [ https://jira.duraspace.org/browse/DS-1119 ] - [DS-1119] xmlui "wildcard policy admin tool" does nothing - DuraSpace JIRA
[21:34] <hpottinger> that right there is an itch that needs scratching
[21:34] <mhwood> Indeed.
[21:34] * hpottinger waves to the crowd, then ducks out into the next room, bye!
[21:41] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) Quit (Quit: Leaving, later taterz!)
[22:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:47] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:55] * hpottinger (~hpottinge@161.130.188.73) has joined #duraspace
[23:02] * hpottinger (~hpottinge@161.130.188.73) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.