Page History

...

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. Upcoming Sprint
   
   1. Emerging focus might be on WebAC.  
   2. Versioning will probably go through the whole two weeks
   3. Documentation will be needed:  
      1. Adopters Guide - can someone look at a pending PR and approve it?
      2. Document: Breaking Changes Between 4.7.x and 5.0.0 - created as a place to put differences
   4. Focus is mainly API alignment, but if there's time maybe have some folks working on fixing issues that are not specifically sprint related.
   5. Danny Bernstein has been doing some sprint planning which should be complete by Friday. If you know of an issue that he should consider as part of the sprint, let him know.  He will update the sprint alingment document and send an email on Thursday or Friday of this week. 
   6. Sprint Kickoff meeting is at 11 am ET on Monday morning.  Seems like that time works for most, if not all.  
2. Sprint Planning 
   1. Memento discussion - Ben Pennell talked about approach the group seems to be coalsessing coalessing on. He is working on implementing that and hoping to have a PR this afternoon so people can see what that this approach would look like.  Having He is having a few issues getting subjects correct right now.  Issue around etags and the wrong one being returned when asking for description (of a binary) - you currently get the etag of the binary.  May Not sure why it was done this way, may have been a convenience thing.   Should we make it so you get the descriptions etag when you ask for it?  General thought is that the binary's description should return it's own etag - general concensus here.  Ben will work with this approach in his PR. We'll go down this road for now and reconsider if we learn more about why this behavior was created this way in the first place.
   2. LDP responses for mementos question talk about - headers persisted as part of the mementos?    consideration of etags
      1. The acl wouldn't be part of the memento, so not stored with with them
      2. apply permissions to time map for creation / view / delete of memento
      3. as time goes along and permisions migth might get changed – you don't want the permission from 1 month ago to work with some of your mementos and others have different perms. Idea is that all the mementos fall into the same bucket – and the permission for that bucket, as a whole, is what might change. 
      4. ACL's for mementos - an alg would could look at current resources ACL – that ACL  is what's applied to all memento resources.   Before you check the original resource, you check the time map first so that the mementos coudl could have different perms.
         1. Peter Eichman - would have to duplicate ACLs? 
         2. mementos can only be read or deleted, so do they need a different ACL?  Can they follow whatever inheritance path structure we define? 
      5. feedback from leadership on deleting a resource - what does it mean for the versions?  leadership seems to like the idea of keeping the tombstone with versions still in place upon deleting of resource.  So the versions live under the tombstone. So one could recover.   Need Need to think about how to restore a version from a tombstone and maybe keep the same URL. The Then what happens when you delete the fcr:tombstone – all things mementos will get purged for that resource.   
   3. WebACLs
      1. Assessment of removing WebACLs from Modeshape. Danny took a quick look and didn't think it'd be too complicated to separate the two.  Perhaps we can accomplish this during the sprint
      2. there There is a no more then 1:1 resource:ACL, which ignores inheritance.  If a acl an ACL triple is editiable by the user, then we can run into comlications complications of change to that triple or adding more acl ACL triples.  
      3. Implication What is the implication of dropping 5.4 from the spec – spec? – Perhaps when you create a resource, it has a default location for that resources ACL, whether or not one is there.  
         1. maybe Maybe we have a server managed location like fcr:acl  - that would be a starting point for locating the ACL, if nothing at fcr:acl, go up the inheritance tree from there to get the ACL. 
         2. Example from Peter Eichman:  top level PCDM container – all the PCDM modelled collections are all siblings under that.   There is an ACL on that parent container, so no resource in it has it's own ACL.  Per collection defaults for ACLs their current heirarchy won't work for them.  AccessToClass impl would make that available to them. Creation of resources would need to add an appropriate access class to that.  
         3. Leads back to what is best practice for data modeling in Fedora 4.  

   
   

...