Time/Place

This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• Audio/Video Conference Link: https://duraspace.zoom.us/my/fedora 
  

  • Dial-in: 
    +1 408 638 0968
    +1 646 876 9923
    +1 669 900 6833
    Meeting ID:
    812 835 3771

• Join fedora-project.slack.com on the "tech" channel

Attendees

1. Danny Bernstein
2. Peter Eichman
3. Bethany Seeger
4. Jared Whiklo 
5. David Wilcox
6. James Silas Creel
7. Andrew Woods
8. Kevin Ford
9. Aaron Birkland
10. Michael Durbin
11. Ben Pennell
12. Longshou Situ

Agenda

...

1. Announcements

2. Weekly Progress Update

   1. JIRAs Closed

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2825

      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2801

   Accessing Modeshape layer WebACFilter :  
   1. 2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-

      2717

    Fedora 5.0.0 Preparation Tasks

   1. 1. 2797

      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2633

   2. JIRAs in Review

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2718

   3. Work completed in the last week

      1. CTS - 2 tests written
      2. Review State of the API Alignment Effort
         1. Outstanding PRs
         2. Review the Jira List
         3. Documentation
   4. In Review: 
      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-28212824

   5. CTS Progress Report 

      1. 14 new tests added by two contributors

   6. Documentation Efforts

3. State of WebAC

4. State of JIRA

   1. (Fedora 5.0.0 Preparation Tasks)

5. Review of Pre-Sprint Opportunities for Contribution (In other words: what can we do this week)
   
   1. Review the Jira List

   1.  Ideas for coming

   2. Status of key Jiras:  

   3.  Ideas for this week

      1. Low hanging fruit (once 2742 is merged)

         1. Jira
            server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-27182843

         2. Jira
            server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2824

         3. Do a code review 
         4. Join the CTS Challenge:  Write two tests before the next meeting:Look at how easy it is to add tests: https://github.com/fcrepo/Fedora-API-Test-Suite/commit/18a58618a856c6796fed69765d796985048f345b

            2844

            
            
            
      2. A little higher in the tree:

         1. Jira
            server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2743

         2. Jira
            server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2698

   September Sprint Planning 
6. Why is the OriginalResource link header required for creating a Versionable object?

Ticket Summaries

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Minutes

1.  Brief discussion about Amherst College's acrepo apache camel services: https://gitlab.amherst.edu/acdc/repository-extension-services
   1. perhaps more conversation about what these are at a later meeting. 
2. Accessing Modeshape layer WebACFilter:  issue
   1. adding Acl:append checking - there are some difference in how Acl:append works in POST: for example you can post to a RDF source but not a non-RDF source.   In looking up the nodes in modeshape, via spring configuration, things are not actually getting injected into the webac filter.  Peter may have been using the wrong configuration file to do this with. 
   2. webac code is in the WebACFilter - but perhaps some of the checks belong in the FedoraLdp class, so that access to node data is readily available.  Concern with doing that is that authorization would be split between to two places and do we want authorization that close to the HTTP API core? 
   3. webac is like a shield around the HTTP interface.  Maybe a way to make a call that's unfiltered?  We need to be able to distinguish requests that need to be filtered and ones that do not (internal requests), to ensure they are not going through the authorization chain again.   One solution could be internal admin credentials?
   4. Current approach is to pull in modeshape (fedora repo impl) to resolve question of what type of RDF resource it is.   That resource is not currently being injected into the webac.  Possible not configuring the correct spring file. 
   5. What about cases where authorization is not just happening out front - ie. cases like recursive delete.   That's an area where authorization checks might need to happen outside/after of the WebACFilter.
      1. Jira ticket for looking at WebAC and recursive deletes where authorization might be different for child nodes. 
      2. one possibility is that a recursive delete will delete what user is authorized to delete – or reject the request outright. 
   6. Andrew pointed out that moving the WebACFilter stuff into the HTTP layer is more out of necessity rather than architectural design – 
      1. more sound/maintainable approach by having the filter do it all, but barrier is getting the injection of fedora objects to work correctly
      2. generating more HTTP traffic when we're already inside the server isn't ideal
   7. Jared brought up the wizardOfOz approach (hidden user) - an internally credentialed (hidden) user whose requests are always just accepted by server. Perhaps tie it to the servers IP, so they are only locally generated requests. 
   8. Short term plan - move some WebACFilter stuff closer to the HTTP layer.  Danny will look at this some.  Fresh eyes on this welcome. 
3.  Fedora 5.0.0 Preparation Tasks
   1. CTS – all the tests are stubbed out now.  
   2. Documentation changes have slowed down.  Still work to do there. 
   3. Outstanding PR's awaiting review from folks - just one current one: https://github.com/fcrepo4/fcrepo4/pull/1386
      1. some JIRA tickets just need to be closed (the PR's were merged already)
   4. JIRA tickets: 
      1. Bethany will look at  

         Jira
         server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2801

           and wrap it up this week. 
      2. There are just 10 issues left for the 5.0 API alignment. 
      3. Looked at 

         Jira
         server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2637

         1. Does it still apply?  How do we want to approach this?  This was based on a use case where some resources ought to be public and not require authorization.  Aaron B. thinks it's still pertinent.  This was to see if the refactor for Shiro changes this behavior.  This question is still open.    
         2. There is code in the WebACFilter that supports authorizing unauthenticated requests.   The bigger question is how to send unauthenticated requests - right now that's being handled by something external to the web app – ie front end talking to shib or the handled by the servlet container.   It's either everything is authenticated or nothing is.   Having Shiro might open up options in the future, for authentication, with the ability to configure Shiro authentication realms  (a potential long term solution). 
         3. Fedora will do the right thing when an unauthenticated user makes a request - acl is still checked.
            1.  Aaron B.  will re-scope it to documentation: documenting where the repository stands on working with this feature. 
         4. How are folks tying into things like shibboleth - Aaron's group is using a proxy-ized path. 
4. LTS update:  the policy has been voted in by Fedora Leadership and is now in effect.

Actions

1. Upcoming sprint Sept. 10.
2. Johns Hopkins University are starting up a pilot with CLAW. Aaron Birkland is the technical point for that and will be learning about it and Drupal. Internally JHU are going to migrate some of their existing IRs to CLAW and see how that goes.
3. 4 tickets closed this week. Also a couple PRs in review.
4. Bunch of new tests added to the Compatibility Test Suite by Bethany Seeger
5. Kevin Ford while testing via documentation found that you are able to version a non-versionable resource.
   
   1. Question is must you add the OriginalResource header to create a version. The specification seems unclear as it doesn't specify that this interaction is not allowed.
   2. However it does allow the weird interaction that you can't GET the TimeMap but you can POST to it.
   3. If we allow this to remain it might cause us problems if we close this loophole later.
6. Peter Eichman has a PR that will resolve acl:Append and move us very close to being feature complete. Only acl:Control will be remaining.
7. Less than 10 issues remaining. 2 new bugs taken by Peter Eichman and Longshou Situ (clap)(clap)
8. How do we get more people involved in the CTS development? An hour walkthrough? Jared Whiklo thinks that it will depend on each person's interest, availability, and learning style.

Actions

•  
•  Danny to explore inserting a macro into documentation for Fedora version.
•  Send email to community seeing who is interested in reviving OAI
•  Aaron B. will re-scope to be a documentation issue: 

  Jira
  server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2637

   
•  Bethany will look at this ticket and wrap it up this week:  

  Jira
  server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2801

...

Future Agenda Topics: 

• Amherst College's acrepo apache camel services: https://gitlab.amherst.edu/acdc/repository-extension-services
• Reviving OAI