objects in the journal not tied to an activity after opened

[tomeu]

As tamichan reported in #5860, if an screenshot is opened in Paint, modified and then stopped, the journal entry for this activity lack the 'activity' and 'activity_id' properties.

Eben, this is wrong, right? Please reassign if I need to do something about it.

[Eben]

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?

[tomeu]

Certainly, if we had versions in the journal (and we can store deltas of the entry data instead of the full data at each version), then this problem would be quite simpler.

At each time that an object is started in a different activity we would branch as you said.

So the original object is left in the journal as an activity-less object. And also entries would never change from one activity to another, just new entries would appear in new branches, each tied to its activity.

Until we have versions in the DS, we can just "migrate" entries to the latest activity and activity_id they were opened in. Hopefully we won't be dragging this issue for many more milestones.

[tamichan]

Eden wrote:

For instance, what if I open the image but don't make any changes? Perhaps then it retains its raw form.

On the build 653, if an image taken by Record activity is opened by Paint activity, the file format is changed from JPEG to PNG and the original image is lost.

tomeu wrote:

So the original object is left in the journal as an activity-less object. And also entries would never change from one activity to another, just new entries would appear in new branches, each tied to its activity.

The same issue is found with a PDF file (imported from USB stick) and Read activity. I am not sure whether it is the right thing to create a new entry in that case. I guess it would be OK to store activity/activity_id in the original object (the PDF file) as long as the content of the original object is not modified.

[marco]

I think this is not an Update.1 bug. We are discussing how to handle this better in the journal summit, but handling in the best will require versions. Making changes to this behavior now would be too risky and unlikely to improve the situation a lot.