**As an** OpenProject user
**I want to** be able to inplace edit and comment a work package in one step
**so that**

- I can better explain my changes
- I do not spam other users with Begin of the deletion tooEnd of the deletion e-mail notifications for each change I make.
- Activity streams are easier to understand.

**Acceptance criteria**

- One email
- One journal entry
- The user only needs to save once.
- The comment field is close to the lastest activity item
- Chronological order: the comment field is underneath the last activity item.
- Reverse chronological order: the commet field is above the latest activity item.
- To the user, the comment then becomes a field similar to description. Exceptions:
- Creating a comment works via an empty placeholder field Begin of the deletion on the top of the activitiesEnd of the deletion with a placeholder like e.g. “Click to add comment”
- Editing a comment behaves just like changing a work package attribute
- Look\&Feel is the same as for in-place edit fields Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion **Implementation approach** Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion - Updating the work package and commenting the change remain to be two actions (and two API requests) technically. To the user however, this does not become apparent. He can change the comment along with the other attributes and send the comment on the same save. To the user only one journal is created, one e-mail is send.
- The journals displayed in the front-end and send via e-mail are aggregations of the journals in the database. Multiple actions done on a work package can thus be displayed to the user to be only one action e.g. changing the description first, saving, changing the assignee, saving, and adding a comment, saving, looks to be only one journal in the front end. Journals are aggregated if they happen within a configurable timeframe.
- The timeframe can be configured in the admin settings and as such work instance-wide.
- Certain actions will lead to stopping the aggregation in the sense, that those actions will always be shown to be distinct ones. The timeframe is ignored then.
- Different author making the change
- Additional comments (also by the same user)
- **OPEN** other criteria
- Aggregation only happens when reading a work package’s journals. Making changes to a work package can thus remain fast. This aggregation function is used for the front-end/API as well as for e-mails.
- In the front-end, the last journal will have to be updated if it another action is aggregated to it, otherwise, a new journal needs to be added.
- Background algorithm for sending e-mails is something like:
- Mail component is registered for “journal created” events
- Once the change to a work package is saved, “journal created (journal\_id)” is notified
- Mail component sets a delayed job with the journal\_id and the timeframe as a delay
- If the delay passed, Mail checks whether this is the last journal. If:
- yes: Send the mail (New or created depending on whether it is the container’s first journal)
- Aggregate all journals who are close to each other (subtracting their created\_at should be smaller than the configured timeframe)
- no: Do nothing.

**Open**

- Should an Admin be able to configure the timeframe for the email notification globally?
- How to adapt the API.
- Can we keep the ID when referencing an activity