mypads isn't working with with current (1.9.3) release of etherpad
Description of the bug
In the current release of etherpad it is not possible to login into a new instance of mypads any more as long as a non dirty.db is used. I tracked down the bug to a refactoring process of ueberDB2 from js -> ts.
Trace of the bug:
- [mypads frontend] login not possible: console ->
Uncaught TypeError: can't access property "length", a.data.rootUrl() is undefined
- [mypads frontend] admin.js: fetches '/mypads/api/configuration' -> response:
{"value":{},"auth":true}
. Usually the value object should be populated and include informations like rootUrl. Instead it is empty - [mypads backend] api.js: GET route for /api/configuration gets the return from configuration.js
- [mypads backend] configuration.js: initially takes default values writes them into the database via 'storage.js'
setKeys
functions and try to get those values from the DB viagetKeys
and returns them. - [mypads backend] storage.js: tries to set and get keys from DB via 'ep_etherpad-lite/node/db/DB'.
- [etherpad] ep_etherpad-lite/node/db/DB: exposes functions of ueberdb2 to initialize as well as
get
andset
from the DB. - [ueberDB2] index.ts: Condition which checks of the debrecated version of a call is used is triggered through this pipline starting from mypads in which the
set
function returnscbDb.get.call
this should becbDb.set.call
instead. So nothing is ever written to the DB and therefore it is impossible to get anything from the DB.
So in the end, this small bug breaks mypads up the chain. How this bug ended up in ueberDB2 is described in the following ueberDB2 PR: https://github.com/ether/ueberDB/pull/464
What should be the normal behavior?
A login process should work without any problems, as the storage.js is able to write data to the DB through ueberDB2 and get this data afterward.
What is the current behavior?
Do you have a hint about the bug resolution?
A PR is already in place in the repository of ueberDB2 : https://github.com/ether/ueberDB/pull/464 . If this PR got merged and this following release of ueberDB2 will be included in the upcoming etherpad release, this bug should be resolved on its own without any changed in mypads. if this is not the case it is needed to rewrite the storage.js file in mypads that it uses the non deprecated function of ueberDB2 (which includes this bug). Anyhow, since the PR towards ueberDB2 is a bugfix and not a feature request it is likely that it will get solved without any chances needed for now in mypads.
What is your version of Etherpad?
1.9.3 (in 1.9.1 it is still working)
What is your version of MyPads?
1.7.24
What is your authentication method?
LDAP