- CSS Regions - these are not really usable right now until all browsers roll it out. But we could try using polyfills to see how performant this approach is.
- SVG <use> tags. Wrapping the entire document in an svg tag and rendering pages that aren't being worked on with <use> (a way to visually "reference" parts of an SVG without duplicating it), while displaying the "real" cropped SVG to show the current page. Not sure how doable this is, but it will let us do more tricks like arranging pages in different layouts (thumbnail bar for example)
- Parse ODF page breaking attributes and just add "spacer" elements within document content to make it look paginated. Does not let us do the above mentioned tricks but is probably "good enough" and a safe approach. When CSS regions are ready we can probably switch to those without too much work.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 7 2015
Sep 17 2015
Sep 12 2015
As this issue was already discussed on a telephone meeting between Aditya, Aaron and me, I'm assigning this to Aditya.
Sep 11 2015
Sep 10 2015
Robert should not be able to just join Susy's editing session without either Susy or the owner of the deployment (and therefore arguably the owner of all files) having pre-approved this level of association of rights outside the session with implicit rights to join and/or manage access on such session.
I need to add that Chwala will likely want to apply a type of lock that allows the file to be marked as being locked (in a collaborative editing session) in other UIs (webclient), rather than just "a lock". This lock could be of such type, amended with such identifier, as to establish the static URI for Manticore to speak to.
In T723#10323, @Adityab wrote:[1] The most convenient solution would be to have administrative rights available handy to work on a shared folder. If, however, only a system that exposes individual rights is possible, then enough exposure of who has what permissions on a source document is required.
Sep 9 2015
I think the idea is to keep the file navigation and status in the Kolab environment. So if no documents are open, you can view the editing status or last edited status etc... without opening the editor. Manticore was going to provide the editing part of the functionality/session only. This solution will provide an easier UX and keep the user in a familiar UI @vanmeeuwen is that correct? My visuals will support that approach... Arriving soon ;)
IMO this is Manticore's business, and we should avoid duplicating it's features within Roundcube files.
Just my two cents: Is providing a separate document list important? Why not simply use Manticore to view this list?
A further question arises, on whether a document to which I have read-only access should be annotated with the fact a collaboration session is ongoing on that particular document.
Robert opens the file (doubleclick) to join Susy in the session.
I agree, we should simply use the regular collaborative setup and not worry about providing a single-user mode.
[1] The most convenient solution would be to have administrative rights available handy to work on a shared folder. If, however, only a system that exposes individual rights is possible, then enough exposure of who has what permissions on a source document is required.
Sep 8 2015
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:
Sep 7 2015
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.
If "editing files continues to work" means live sessions will carry on fine, this is not possible if things like etags and last modified timestamps will change. Unfortunately moving to a different file backend will make us lose information that identifies files in the new "filesystem" with their versions in the older one.