The idea, for now, is to call the storage specific fileinfo
functions (getLocalFileInfo, getWOPIFileInfo) which returns the
file + user specific data for given URI. By user specific, it
means data which is token (provided in URI) dependent.
For WOPI, it would mean various user permissions
(editable/viewable etc.)
For our current storages, these calls also include the basic file
information which is common across all tokens. This can be
retreived by calling getFileInfo on the storage object.
Change-Id: Ibbd3b74b011d8bb6fe4730c33276ef9ac6c47103
While this has some overhead, it makes debugging of tile
rendering easier.
Change-Id: I0430015f41fd044e4be1099a5d61a23c0ef88176
Reviewed-on: https://gerrit.libreoffice.org/30245
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When a client connects or disconnects ViewInfo message is sent.
The handler for this updates the number of users via addView
and removeView. Unfortunately when the toolbar control is
updated, it resets the zoomlevel to 100% (the initial value).
This is an ugly hack to change it back to the correct
value, since nothing really visually changes. It certainly
could be improved by only correcting the toolbar.
Change-Id: I37294da2d9d1bc84e8cb3b7f634aadcfd80d6497
Reviewed-on: https://gerrit.libreoffice.org/30218
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
By retaining the view-ID to username mapping of disconnected
users we are able to show a disconnected username in the
document repair dialog.
Change-Id: Id08790de31f92653381b6a1525caf044bd875479
Reviewed-on: https://gerrit.libreoffice.org/30216
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This avoids always waiting until child spawning times
out by being smarter about whether or not there are
any children spawning to wait for.
Change-Id: I96a16ac35f90f70219d4153db9862cf2ee5b6a76
Reviewed-on: https://gerrit.libreoffice.org/30213
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Checking for document limit must be done before allocating
a child process, otherwise the new child process will not
be cleaned up or released, thereby failing the test.
Change-Id: I99b1155bdacf2f0b7a24c7b7330d207e4c7beee8
Reviewed-on: https://gerrit.libreoffice.org/30208
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
It would be nonsensical to allow less connections than documents
since each document must, by definition, have at least a
single connection.
This prevents blocking new documents because of connection
limit. If that were the intention, max_documents should be
lowered to match max_connections.
Change-Id: Ide07e977f548ed917c6e51a2ba88f3cc07947efe
Reviewed-on: https://gerrit.libreoffice.org/30209
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
It was intended to assert that the *same* thread
hadn't locked, not any. As it stands, it's problematic
and was decided to let go.
Change-Id: Iddb76f0edd62b7cdca062c2aa924b08e3d7952ef
Reviewed-on: https://gerrit.libreoffice.org/30205
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
newChild is not thread safe and accessing _childSockets
must be accessed under the lock. This fixes
a segfault and merges getMemory with newChild.
Change-Id: I523c3c31d465118f263f7cb09d84105946e19720
Reviewed-on: https://gerrit.libreoffice.org/30204
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tiles are checked for correct count and whether or
not they are serviced from cache or rendered.
One test is done with a single view and another
with four views.
Change-Id: Ieadeef8547097d4a53fb1ce42c56c33ec16d849f
Reviewed-on: https://gerrit.libreoffice.org/30197
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tests should read errors and parse them if they are
expected. Otherwise, we should not ignore them and move
on, because they are (by the above definition) unexpected.
Change-Id: I9d7a9fb23879044ac4f11461e92c5f6fd6b03fa1
Reviewed-on: https://gerrit.libreoffice.org/30194
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
