Implemented in rKS5f221711c39ec04def940e1622543bc1a806fe13

Users may also find it useful, to have an indication on files currently being edited, to which they have read-only access (such as your proverbial company-wide communique at shared/memo/communique.odt), so that they might postpone reading and/or downloading a copy of the document (since it is being edited). Any thoughts?

It is suggested two separate UI elements be used for indicating ongoing sessions:

This could be a blocker for T756?

From the suggestion in T731#10206, the expectation for Susy could probably be managed better by establishing the implementation of presence information exchange ("Robert is on the phone"), supplemented by scheduling and availability information (Free/BUsy) (or vice-versa, the implementation of a Free/Busy interface supplemented by presence information) for when Robert is otherwise occupied between "now" (Susy would like Robert to join) and "then" (Robert is available to respond and does so).

This could possibly be improved upon by suggestions raised in T725#10210 as well as T727#10213.

Apart from the semantically different content types, I would suggest that this is the same type of API call for Manticore to implement, as already suggested in T725#10210.

The collaborative editing session should probably have been available during the meeting, with meeting participants able to read if not write in to the notes as would be deemed appropriate. The collaborative editing session might have started out with the agenda of the meeting.

Two angles of attach exist;

I've edited the task description to portray the file being clicked is a document, rather than just any file, and the editing session that is opened is a collaborative editing session rather than just an edit session.

This would rather be Roundcube Kolab Plugins , namely the kolab_files plugin, and Chwala, more so than Roundcube itself, at this moment, with no room currently defined for Roundcube Next to achieve its stretch goals.

This scenario should probably be superseeded by establishing the mechanisms to exchange presence information ("on the phone") rather than be implemented specifically as an instant request-response mechanism for participation in collaborative editing sessions, requiring Robert to respond as fast (while on the phone) for Susy to have the appropriate expectations, and should probably be formulated in a way that allows the participants (invitor and invitee alike) to expect an asynchronous and delayed responses.

This spells "delegation" more so than "declination". Let's reformulate the use-case to be an explicit "not interested", and perhaps create another for delegating participation on to other parties.

The user story is ambiguous, in that either Eva moves a document, for which, at that moment, a collaborative editing session exists, from one storage backend to another, or the corporation switches storage backends as a whole.

Included in pykolab-0.7.15.

This has been implemented now.