otetard / ownpad

Ownpad is a Nextcloud application that allows to create and open Etherpad and Ethercalc documents.
GNU Affero General Public License v3.0
57 stars 24 forks source link

Public pads are not created if "editOnly" is set in Etherpad #67

Closed m0urs closed 5 years ago

m0urs commented 5 years ago

Ownpad is working for me if I create a new protected pad in Owncloud. However, if I create a "normal" unprotected pad, the pad it self is not created in Etherpad and the link which has been created by Ownpad is not working and gives me the message that I have no access to that tab (which is quite normal, as it has not yet been created ..).

Is this normal, which means are only protected pads are working? If yes, can I remove the option to create unprotected pads?

Thanks, Michael

m0urs commented 5 years ago

Ok, the issue with unproteced tabs is because I have set the option

/ Users may edit pads but not create new ones. Pad creation is only via the API. This applies both to group pads and regular pads. / "editOnly" : true,

in order to prvent public creation of new pads. If I set that to "false" it is working.

Howver I thought if I also enable the API option for Ownpad, then Ownpad will use the API to create new pads even for unproteced pads. Unfortunately this does not seem to be true?

It would be nice if unprotected pads could also be created via the API so that I can leave "editOnly" to "true".

A similar issue has been described here: https://github.com/otetard/ownpad/issues/44 The answer was to use the "feature/etherpad-api branch". I guess that this branch is no part of the main branch, but not working as described for unprotected pads?

m0urs commented 5 years ago

I solved the issue that with API enabled unprotected pads are not created if "editOnly" : true" is set. Here is the code I have added:

-------------
@@ -57,11 +57,25 @@ class OwnpadService {
                 }
                 catch(Exception $e) {
                     throw new OwnpadException($l10n->t('Unable to communicate with Etherpad API.'));
                 }
             }
+            else {
+                try {
+                    $config = \OC::$server->getConfig();
+                    if($config->getAppValue('ownpad', 'ownpad_etherpad_enable', 'no') !== 'no' AND $config->getAppValue('ownpad', 'ownpad_etherpad_useapi', 'no') !== 'no') {
+                        $eplHost = $config->getAppValue('ownpad', 'ownpad_etherpad_host', '');
+                        $eplApiKey = $config->getAppValue('ownpad', 'ownpad_etherpad_apikey', '');
+                        $eplInstance = new \EtherpadLite\Client($eplApiKey, $eplHost . "/api");
+                    }

+                    $createdPad = $eplInstance->createPad($token);
+                }
+                catch(Exception $e) {
+                    throw new OwnpadException($l10n->t('Unable to communicate with Etherpad API.'));
+                }
+            }
             $ext = "pad";
             $host = \OC::$server->getConfig()->getAppValue('ownpad', 'ownpad_etherpad_host', false);
             $url = sprintf("%s/p/%s", rtrim($host, "/"), $padID);
         }

-------------
otetard commented 5 years ago

Thanks @m0urs for that bug report. I think that we should always use the API to create pads (“protected” or not) if Ownpad is configured with an APIKEY.

Could you please create a pull request with your code so I can merge it into Ownpad?

m0urs commented 5 years ago

Hi, I tried to create a pull request. As I am not a developer, this is my first time I did that on Github. So hopefully I did not make too many mistakes. Otherwise I really appreciate comments :-)