User:Alsroot/trash/Activity as a regular Journal Object

Summary

Use Journal objects to represent activities.

Owner

• Name: Aleksey Lim
• Email: send an email

Current status

• Targeted release: ?
• Last updated: Tue Jul 28 04:32:53 UTC 2009
• Percentage of completion: 0%

Detailed Description

The major reason for this feature is eliminating confusion when:

• theres are activities(in Home view) and activity bundles(in Journal)
• user can remove bundle from Journal and activity will be preserved(and vise versa)
• activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal

Feature declares:

• every activity which is accessible in sugar has Journal entry
  • for activity came from bundles, entry will have .xo's metadata(timestamp, title etc)
  • for system wide activities, based of /usr directory properties
• there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another
  • in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home plugin
• reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity
• reflect on uploading to Journal new .xo version of existed activity, could be:
  • follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity)
  • storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start

Benefit to Sugar

• feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity)
• let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal entry to USB source
• since all activity have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.)

Scope

• sugar

UI Design

Nothing.

How To Test

This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.

Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.

A good "how to test" should answer these four questions:

• What special hardware / data / etc. is needed (if any)?
• How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?
• What specific actions do I perform to check that the feature is working like it's supposed to?
• What are the expected results of those actions?

User Experience

If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.

Dependencies

Glucose dependencies.

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

• Unified Objects#Activities_as_Journal_Objects|Unified Objects
• Features/Object Bundles
• Email threads
  • multiple activity versions installed simultaneously
  • Activity as regular objects proposal

Release Notes

The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.

Comments and Discussion

• See discussion tab for this feature