Known Issues and Assumptions

Collections

• Currently reports work only within one collection.
  • items that are transferred to another collection are treated as if deleted
  • items that are transferred into this collection may be reported incorrectly
• Report items are kept in the same collection.
  • if report items are transferred elsewhere, "/report last" will not work properly, because the latest report will not be found

Efficiency

• Currently the potential items for reporting are filtered from the collection, and then ALL the versions in the repository after their creation are iterated over.
  • slows down the performance
  • will be especially problematic with huge repositories and very old items

Deleted Items

• Currently deleted (or transferred to othe collections) items are reported only for "New arrivals". In other cases, such as transition of focus in, etc. it is assumed that these items are not as important for the user, since (s)he has already deleted them
• Adding broader support for deleted items might be necessary

Repository Issues

• Worked on items: it is impossible to get currentMe address for old items. Thus, currently, if the user changes his email account, and then asks for a report on older items, the older items may be not reported as modified by himself, but by someone else.

• Dates of commit are stored in repository. Currently, reports are based on these dates as the dates for the versions of items in history.
  • if the repository is changed, they are not preserved. Reports for older items will not work properly.
  • it is impossible to fake a commit date other than now -> testing, older reports, by simulating older commits becomes difficult

• Creating new view in repository is costly. Currently, in reports implementation one view is created for each section of report. Also a new view is created for each recovery of special attributes from the repository (for recurring events)

What should be reported?

• Currently only the changes of triage status between the start point commit to the end point (now) are checked. The changes of status in between these two points are not taken into account.
  • DONE (before last report) ---> LATER (sometime before now) ---> DONE(a little bit before now) will NOT be reported as an achievement.
  • NOW (before last report) ---> LATER(sometime before now) ---> DONE (sometime before now) will be considered as an achievement, but not as transition out of focus.

End time

• Currently the end time of each report is always current time. Flexible end time is NOT implemented

Recurring events

• When changes happen to all the occurrences, both the occurrences and the master event will be reported
• Newly generated occurrence is NOT reported as a newly received item. All the occurrences are assigned the creation time of their master.

Initial triage status

• The initial triage status of items is not stored explicitly. It is assumed that items are created in the status of NOW for reporting.
• For items that have the EventStamp^? and their start time is later than their creation time, the initial status is assumed to be LATER

-- VeraSheinman - 12 Aug 2007