... for which they want to be notified.
Needed to add some missing header files to Storage and Auth class
because of conflict raised when LOOLWSD.hpp is included in
Admin.cpp
Change-Id: Ia1c8ed82f8cd979eaf93267ae5dfa347acf895f4
And then combine into one during build for distributing. We would
also want to minify the combined JS file but that is for later.
This come up rather early than anticipated, but good for us.
Change-Id: I74feb4955c5d47f0e9e817b410726ad219add485
Additionally, move jquery <script> tags up because we need jquery
to add context menu to table rows as soon as page is opened
(socket is opened, in this case).
Change-Id: Ic6e28486fb96f119e7d41168fc0039265f15a087
Further changes/refactoring to make it possible:
* Add broker pid to Admin class
* Move getMemoryUsage for process to Util
* Change variable name to accurately reflect *active* items
_nViews -> _nActiveViews, etc.
Change-Id: I4c9206c49ab829b73ebfe226874bfbbcc8f95342
Reviewed-on: https://gerrit.libreoffice.org/22989
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Otherwise the process could terminate while admin sessions are still
being served.
Change-Id: Id91d0989e264e8294827e8e2ad8dd2d44b6006ec
Reviewed-on: https://gerrit.libreoffice.org/23021
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Much simpler.
Also, don't duplicate the code informing that LD_BIND_NOW or
LOK_VIEW_CALLBACK are not set. Not that I understand why we need to
inform about that? If the "normal" thing should be that they are set,
why don't make it so by default then?
I occasionally saw a deadlock when running 'make check' where one
thread holds the ChildProcessSession::Mutex and wants the _mutex for a
Document, while another thread holds that _mutex and wants the
Mutex. In particular, it is the Document::onUnload() that wants the
_mutex. So avoid the deadlock by having Document::onUnload() first
take the ChildProcessSession::Mutex.
The callbacks from documentLoad() are made in the same thread.
Sure, as such it is not a good thing to use recursive mutexes. If we
switch back to non-recursive mutexes, we will have to stop taking the
lock in callbacks from documentLoad(), i.e. make sure we know those
functions aren't used elsewhere, in places where a lock would be
needed. Or something.
If a client session closes just after sending a load message to load a
document, and another session then fairly immediately connects and
sends a load message for the same document, the latter session gets
handled by the same kit process. Also, the same Document object is
apparently used. In that kit process, the first documentLoad() might
easily still be in progress. The handler for the new session still
calls onLoad(), too, and as the first onLoad() had dropped the lock
for the duration of the documentLoad() call, the new onLoad can take
the lock and call documentLoad(), too, while the first documentLoad()
call in the other thread still is in progress. This leads to
interesting problems.
It is loolwsd that spawns loolbroker so we control what arguments it
gets, so no need to give verbose errors if our own code is
inconsistent. That is what assert() is for.
Lets have a new websocket class for each websocket type we want
in admin console inheriting from single abstract base class.
This, hopefully, would provide us with extensibility and ease of
managing files in future. Right now, there is only one class with
very less complexity, hence all the code is in one file.
As the complexity increases, we would need to separate all these
classes in different files, concat and compress them before moving
to dist/
Also rename dashboard.html to admin.html
Change-Id: I34b9b2817fe4a0e6ee2913c017d2694a17ab978c
Reviewed-on: https://gerrit.libreoffice.org/22904
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
This broke after we changed 'searchAll' to 'highlightAll'.
Change-Id: I257b20a458a9ad3334b5e20fc110d0932eb63733
Reviewed-on: https://gerrit.libreoffice.org/22508
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
This is required because we want to test on which page search is
found, and we can not do it before we get results for
partpagerectangles.
Change-Id: I6f927ae27b91e62d86a8e46dc9c21ee9aa913894
Reviewed-on: https://gerrit.libreoffice.org/22507
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Work based on bootstrap: http://getbootstrap.com/
License: MIT
Change-Id: I6a114e8dd688339c809ff27d97d0065647700971
Reviewed-on: https://gerrit.libreoffice.org/22824
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
State changed event from LOK for impress documents is
prefixed with the template name followed by the style name. Lets
strip the template name for the time being till we support it in
the UI.
Also LOK emits some form of internal names in state change event
which is different from the internal names supplied to us in
intial .uno:StyleApply. For consistency, convert these names to
our original form of internal names.
Change-Id: I95d3d8aa29238fc326887cdfc9b22eb4e429d1bb
Reviewed-on: https://gerrit.libreoffice.org/22814
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Since the data scraped from the LO translation module is a
mapping between the UI names (not internal ones) to different
languages, the plan is to first set the locale explicitly to
'libreoffice' so that l10n framework gives us corresponding UI
names from programmatic names, and then to use the specified locale to
translate these UI names to respective languages.
Change-Id: I64f7c9b4927e5effe328cb7b42582b45d44167d9
Reviewed-on: https://gerrit.libreoffice.org/22813
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Admin web sessions are added as subscribers to AdminModel. Live
notification fill up the AdminModel, and notifies to
subscribers, if present any. AdminModel can also be queried to
fetch any previous data since the start of the server including
expired documents/views with timestamps for analysis.
There is lot of stuff that can be added in future. This commit
just lays the foundation of appropriate classes.
Change-Id: Ifcf6c2896ef46b33935802e79cd28240fd4f980e
Reviewed-on: https://gerrit.libreoffice.org/22869
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
As a test, add command to fetch documents from AdminModel.
Change-Id: I3cb7097ba7dde049f3b2478fe7b6b6c309da1d92
Reviewed-on: https://gerrit.libreoffice.org/22781
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Turns out the callbacks from documentLoad() are in general done on
another thread, not necessarily the same one that did the
documentLoad() call. Not sure why it happened to be the same thread
for me, but oh well. Need to fix the problem described in
3671abf89b in some other way then.
This reverts commit 2fab757462.
I forgot to mention in the commit message of
2fab757462 what error situation the
change fixes... So here goes:
If a client session closes just after sending a load message to load a
document, and another session then fairly immediately connects and
sends a load message for the same document, the latter session gets
handled by the same kit process. Also the same Document object is
apparently used. In that kit process, the documentLoad() can still be
in progress. The handler for the new session still calls onLoad(),
too, and as the onLoad() had dropped the lock for the duration of the
documentLoad() call, the new onLoad gets the lock and calls
documentLoad(), too, while the documentLoad() call in the other thread
still is in progress. This leads to interesting problems.
Actually, now that I think of it, I very much doubt it is sane to have
the same Document object used for several sessions (one or several
already "dead" ones and one "live" one) simultaneously, but at least
the change made the unit test work more reliably.
The callbacks from documentLoad() are made in the same thread.
Sure, as such it is not a good thing to use recursive mutexes. If we
switch back to non-recursive mutexes, we will have to stop taking the
lock in callbacks from documentLoad(), i.e. make sure we know those
functions aren't used elsewhere, in places where a lock would be
needed. Or something.
... and Admin and AdminModel containing all the required data
that we need to expose to Admin panel.
Admin processor will keep listening to any data on this
notification pipe and update AdminModel accordingly.
Change-Id: I0dd6f07ae60158733c34d17f53a35def70600513
Reviewed-on: https://gerrit.libreoffice.org/22780
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
