Seems to have no effect, so gone in
favor of RLIMIT_AS (virtual memeory).
Change-Id: I210879ec9285f420c9f9839cdabf45c42d865fb3
Reviewed-on: https://gerrit.libreoffice.org/38720
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Using it this way looks very fragile to me; let's just avoid this.
Change-Id: I7459f3b215f5f9930287566a1bd946a94e9b343b
Reviewed-on: https://gerrit.libreoffice.org/38512
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
... with no functionality attached to it except notifying the WOPI host
that button was clicked. Host is supposed to do the action thereafter
itself.
Also, notify the host when a save succeeds or fails.
Change-Id: I0daa2690af2259233840ea7ab4326b9b80d5fa87
Moreover, its ideal to use the same URL to get this *-help.html file with
which loleaflet.html is loaded, and not the one with 'dist' in it.
Change-Id: I2e25f9a2ef41bb1d23fc09878b0726d6b4019cee
File extensions marked as view (as opposed to edit)
in discovery.xml are now forced to be read-only,
regardless of what the client tries to request.
Change-Id: I3eb00c33ff716800dc317f7377281c6d5f0909d7
Reviewed-on: https://gerrit.libreoffice.org/38480
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
In richdocuments, it was added in aa0a8f666ada8f1d1edae17b906089cc03ba473d
and then removed in 87f7720d12e130bd1c3cd9306ad1b1f4d784f9e6
It was added firstly way before WOPI was even there. But now since we
have WOPI, we wouldn't need it.
Change-Id: I786a3f7b2103a43995a70b53438d88a829d13265
When saving while editing a cell, the
document is saved with the new cell contents
(as the cell editing is interrupted and applied),
but the modified status is not published to the
client (loleaflet).
This has the unfortunate side-effect that the
EverModified flag is not set in this scenario.
To avoid this, this patch sets the EverModified
upon successful saving. This is easier than
forcing LO Core to emit ModifiedStatus=true
in the scenario above. Though it suffers from
the false-positive result when the user forces
a save. Although this is probably defensible,
since technically the document changes upon
saving (though not the content if there was
nothing new to save). On the other hand,
it's less harmful to signal modification
due to save than to ignore genuine
modification to the document.
Change-Id: I7ccba62731f534b69819f7924eeb9231d874c111
Reviewed-on: https://gerrit.libreoffice.org/38398
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This is required to tell the clients if the command they issued was
successfull or not. In this case 'savetostorage' is the command that we
are interested in knowing the success status of.
With this, now if the user commands to overwrite the document, dialog
boxes of all other users are automatically closed.
Can easily more commands in future for this kind of thing. Its similar
to unocommandresult, except its not a uno command, but our internal
command.
Change-Id: I2e7e1fd5edbd55c13ee4bf9bce24284483d6507f
There is one known problem still - after any user decides to overwrite
the file to storage, other users are not informed, so their dialog keeps
hanging on the screen until they press the cancel or reload button.
Change-Id: I6dad1585e4c53eeed79cd38316892a7f239d44ef
