#5876 NORM Never A: objects in the journal not tied to an activity after opened

[Zarro Boogs per Child]

#5876: objects in the journal not tied to an activity after opened
---------------------+------------------------------------------------------
  Reporter:  tomeu   |       Owner:  Eben          
      Type:  defect  |      Status:  new           
  Priority:  normal  |   Milestone:  Never Assigned
 Component:  sugar   |     Version:                
Resolution:          |    Keywords:                
  Verified:  0       |    Blocking:                
 Blockedby:          |  
---------------------+------------------------------------------------------
Changes (by Eben):

 * cc: marco, okada, christianmarc (added)


Comment:

 This does seem wrong.  Without an activity ID, how would
 sharing/versioning/etc. work?  I think ''something'' needs to be given an
 ID when this happens.  I'm not sure what, and I'm not sure by who.

 What I mean by that is, first of all, should Sugar/Journal be
 automatically assigning an ID in this case, or should it be left up to the
 activity to decide whether or not to "claim" the object?  Are there any
 cases when assigning the object an ID doesn't make sense?  For instance,
 what if I open the image but don't make any changes?  Perhaps then it
 retains its raw form.

 Also, as far as what actually gets the ID, should it be the original (in
 this example) screenshot entry itself; should it be a copy of the
 original; should it be only the entry which represents the changes to the
 original?  This is a delicate question, actually.  Consider opening the
 screenshot with Paint, and assigning the screenshot an activity ID.  It is
 then associated with that Paint instance, including its scope and other
 properties.  If I then attempt to use that screenshot as a starting point
 for another project, what happens?  Does it only then get duplicated in
 its unaltered state and receive a new activity ID?  It can't remain part
 of the histories of both activities, or can it?  Can we assign the objects
 which "branch" multiple IDs?

 Tomeu, any thoughts on this?  It's a tricky problem that arises both in
 the case of opening a "raw" object (with no association), and due to the
 "resume as ... <some other activity>" option that we provide.  Does the
 latter action create a new activity collaboration under a different ID
 implicitly, or does it retain the previous one (even though the activity
 ID then represents 2 separate activites - perhaps call it the
 collaboration ID instead), requiring an explicit copy to be made first if
 a new collaboration is desired?

-- 
Ticket URL: <http://dev.laptop.org/ticket/5876#comment:1>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system