ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Issue atom feed shows "issue creation" journal, didn't before (Bug #442)
Description
The atom feed for an individual issue /issues/:id.atom
shows the journal for the issue creation, this wasn't present in previous versions. Showing that journal doesn't make much sense as it doesn't give any significant information, so I think it can be left out. Alternatively, I don't feel the atom feed is complete if it doesn't include the initial state but just the changes, should we add an initial entry reflecting the initial state of the issue?
Associated revisions
[#442] Handle nil changes in Atom feed
History
Updated by Eric Davis at 2011-06-03 03:32 pm
I want to look into this initial journal. It seems to be causing some other problems and I'm not sure why we need it.
Updated by Felix Schäfer at 2011-06-03 04:02 pm
Eric Davis wrote:
I want to look into this initial journal. It seems to be causing some other problems and I'm not sure why we need it.
They might be causing some problems, but getting rid of them is not the right solution. The activity for example is now only one request to the journals
table with the correct types, before it was to at least as many tables as types you wanted to see in the activity. If you remove the initial journal, you'd have to query every object for its creation date in addition to just the journals
table. Furthermore, we could now have something like "created on" and "deleted on" entries in the journals so that deleted issues/whatever still leave a trace.
Anyway, what I'd like to have discussed here is if we just remove the initial entry from the ATOM feed for now to keep compatibility, or if we remove the initial entry and replace it with an entry of the full initial issue. I think having the full initial state of the issue as the first entry is "more right", but would need more work, so I'd say just filter the initial journal for now and rework the ATOM feed later.
Updated by Eric Davis at 2011-06-03 06:23 pm
Felix Schäfer wrote:
They might be causing some problems, but getting rid of them is not the right solution. The activity for example is now only one request to the
journals
table with the correct types...
Ah so the initial journal is used for the "created Issue" activity. That makes sense then. I just couldn't find the code (or comments) that defined that.
Anyway, what I'd like to have discussed here is if we just remove the initial entry from the ATOM feed for now to keep compatibility, or if we remove the initial entry and replace it with an entry of the full initial issue. I think having the full initial state of the issue as the first entry is "more right", but would need more work, so I'd say just filter the initial journal for now and rework the ATOM feed later.
I think you're right about the full changes. I think of the atom feed as a list of the changes to an issue, which could be either way (changes after creation or all changes). But if we track the original state of the object at creation, then we would be able to query/diff/compare it easier. Let me see if I can prototype this.
(At the very least I'll see about changing the ATOM feed)
- Assignee set to Eric Davis
Updated by Eric Davis at 2011-06-03 06:36 pm
I really like the feed with the full details. I faked it out by changing the initial creation journal to show the state change of nil
=> value
. Examples attached:
- File initial-journal-feed.png added
- File example_feed.xml added
Updated by Eric Davis at 2011-06-03 08:07 pm
Posted my code and research on initial journal tracking to #445. If that change is merged in then this issue will not be needed (the initial journal would list the "creation" attributes).
- Target version set to 2.0.0
- Status changed from Open to Ready for review
Updated by Eric Davis at 2011-06-10 06:23 pm
Now that #445 has been added the Atom feed will show the initial state of the issue. I added a small bugfix for nil changes that was trying to get converted to a string in 1e68bed.
- Status changed from Ready for review to Closed