...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 40 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 40 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 40 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

1.  PUT with server-managed triples... fail or ignore?
   1. when you have a resource that you want to update with a PUT request (body being RDF, that doesn't not include server managed triples) the current logic tries to remove the triples that are not in the body of the RDF - throwing a 4XX error.  Question - we not require the server managed triples be included in the body of RDF request.   Use case is to update the resource w/o having to know the server managed triples, since we can't change them anyways.
   2. Esmé Cowles reminded us that there is a preferred header ```handling=lenient;received="minimal"``` should do the trick.
   3. Why is the default behavior taking server managed triples into consideration in the first place?  Should it be the other way around?  Lenient default - and have a strict option? Use case: one may want the full graph in a case where other's are editing at the same time - for conflicts. 
   4. Esmé Cowles has used this recently - would be surprised if not implemented, since it's worked for him.  
   5. Esmé Cowles will test this (the lenient and received=minimal) 
      
      1. Confirms that PUT with received=minimal does do the requested behavior - updates the user triples. 
      2. Esmé Cowles to update the documentation for this 
      3. Should work for Stefano's use case. 
   6. Andrew Woods - Is there any situation that should require putting the server managed triples back on the server? Would this capability help in some way? ETags should serve the same purpose.
   7. Concern about what it means if someone tries to write server manage triples that are wrong?  Persist anyways?  
      1. if you're trying to change the value on a server managed triple, you should get an exception. (including implicit removal for triple not specified in request). 
      2. LDP spec says HTTP PATCH is for merge of data, and to use HTTP PUT for replacement.
      3. HTTP PUT for replacement - but with server managed triples it's more complicated.
      4. The delete and recreate use case is the one to figure out how to work with here.  
      5. Want to be careful of situations with server managed triples that change w/o user knowing (Indirect Containers, for example). 
   8. Two ways to do this stuff
      1. PUT with received=minimal
      2. SPARQL update via PATCH
   9. is it worth someone times to investigate a different behavior here, or are things good as is?
   10. handling=strict; received="minimal" may give same response, which would probably be a bug.   
   11. Benjamin Armintor - to add comments to 

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

       
       
       
2. 4.5.1 Release planning - getting a release out would be beneficial
   1. one blocker - 

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

       - auth is a core feature and if not working, we can't really release.  
      1. what do we think the expected behavior should be in this situation (a batch operation)?
         1. a link to an ACL that is prefixed with transaction context ?
         2. a link to an ACL that is not prefixed with transaction context?
         3. a link to an ACL that points to non-accessible uri?
         4. no ACL link header?
         5. behavior different depending on whether or not the ACL is created w/i the batch request?
   2. Any other tickets in before we put out release?  None put forward
   3. Who can work on release?  
      1. Benjamin Armintor - Release Manager
      2. Esmé Cowles and Jared Whiklo  happy to help out
3. Bugs are beginning to pile up