#1358 closed defect (fixed)
Changes to a Journal entries metadata are wiped if edited while Activity entry is currently instantiated
| Reported by: | garycmartin | Owned by: | erikos |
|---|---|---|---|
| Priority: | Unspecified by Maintainer | Milestone: | |
| Component: | Sugar | Version: | 0.82.x |
| Severity: | Blocker | Keywords: | r+ |
| Cc: | Distribution/OS: | Unspecified | |
| Bug Status: | Assigned |
Description
Ouch a nasty one, tested on 0.82, 0.84, 0.86...
If you use the Journal to edit ANY of the metadata (favourite star state, title, description, tags, while that activity entry is running, switching focus to that activity and back to the Journal will wipe all your changes.
How to reproduce:
1) Start a new Activity from the home fav view (e.g Browse)
2) Switch to Journal
3) Favourite star it, edit the title, in detail view add description and/or tags
4) Switch back to Journal list view (i.e don't leave in Journal details view)
5) Switch to Activity instance
6) Switch back to Journal view
7) Note that all previous Journal metadata details are wiped/reset
The activity does not need to be new, it can be a resumed instance. You can leave the Journal view in a details view but you hit another bug in that the view is not refreshed with the wiped metadata, so it look like it remembers, but when you revisit later it was indeed wiped.
This issue prevents the workflow where you switch to the Journal to add tags or a descriptions to Activities you have open for reference (say you're trying to work out a nice description for two homework essays, or clearly tag them).
Attachments (1)
Change History (12)
comment:1 Changed 14 years ago by alsroot
- Milestone changed from Unspecified by Release Team to 0.88
comment:2 Changed 14 years ago by alsroot
- Severity changed from Major to Blocker
comment:3 Changed 14 years ago by erikos
- Bug Status changed from Unconfirmed to Assigned
- Component changed from journal to sugar-toolkit
- Owner changed from alsroot to erikos
- Status changed from new to assigned
I have a fix for sugar-toolkit for this one.
comment:4 Changed 14 years ago by erikos
- Keywords r? added
comment:5 Changed 14 years ago by erikos
The above patch lets the DSObject listen for the updates to the object. To only listen for changes to a specific object is done by adding the arg0 argument to the dbus connect call. The DSMetadata associated with that object is then updated. On property changes in the DSMetadata a gobject signal is emmitted, on which the activity base class is already listening on (at the moment it only listens for the title to change).
The patch adds the "add_update_listener()" since when creating a new DSObject the ID is None. The ID is only set after datastore entry is created. Actaully one could so that as well write call in the datastore.py
One interesting thing about the patch is, that it can be easily back ported to 0.84, or even 0.82.
comment:6 Changed 14 years ago by tomeu
- Keywords r+ added; r? removed
Sounds good, but I would turn object_id into a python property and connect to the dbus signal in the setter, that way we don't need add_update_listener().
comment:7 Changed 14 years ago by erikos
- Resolution set to fixed
- Status changed from assigned to closed
Thanks for the review, pushed with the additions you made.
comment:8 Changed 14 years ago by erikos
- Resolution fixed deleted
- Status changed from closed to reopened
There was a little issue, found while testing. Fixed with this commit.
comment:9 Changed 14 years ago by erikos
- Resolution set to fixed
- Status changed from reopened to closed
comment:10 Changed 10 years ago by dnarvaez
- Component changed from sugar-toolkit to Sugar
For me it look like core problem,
after switching to Journal from activity, shell re-writes ds objects and afaik there is no API(in activity class) to tell activity reread changed object, so activity isn't aware of changes and feed to write_file() old data.