Some parts are probably better suited for the docs since they are now part of the repo.

To prevent overload, it should be run by cron once a day to get info about the latest version available. If the latest version does not match current version a notice in administration should be shown.

Presently there is no check of the db settings. This has to do with issues like:

• db charset
• db collation
• strict_mode (and all the related settings)

There are collated columns all over the db and when running migration on a db that is not collated foreign keys sometimes can not be made. This particular case was fixed by this diff:

mb@mb-laptop ~/Projects/epartool/epartool (master ±1) ~> git diff
diff --git a/data/phinx-migrations/20180221091158_dbjr1358.php b/data/phinx-migrations/20180221091158_dbjr1358.php
index 3fb54e63..7352ddfa 100644
--- a/data/phinx-migrations/20180221091158_dbjr1358.php
+++ b/data/phinx-migrations/20180221091158_dbjr1358.php
@@ -10,7 +10,7 @@ class Dbjr1358 extends AbstractMigration
 CREATE TABLE `voting_button_set` (
   `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
   `consultation_id` int(10) unsigned NOT NULL,
-  `button_type` varchar(191) NOT NULL,
+  `button_type` varchar(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
   `points` int NOT NULL,
   `enabled` tinyint(1) NOT NULL,
   `label` text NULL
mb@mb-laptop ~/Projects/epartool/epartool (master ±1) ~>

If the mail server configuration was not done correctly, the password recovery feature results in an error500 instead of the info that there is a mail problem.

ePartool-version: 4.11.x

During installation and update process the db creation and migration tasks can take too long and then there can be PHP or webserver timeout.

The PHP timeout was hackishly solved by disabling it in the script, but there is no clean way to deal with the webserver timeout. The present situation therefore is that if the user disregards the webserver timeout and keeps on waiting, then the PHP script will likely eventually finish on the background and all will be OK. Of course the PHP script could be killed by the OS and the user has no way of knowing other then trying the installation out.

Ideally the db creation and migrations should be run in separate requests that will be triggered sequentially. JS could probably do this. Using JS would also make it reasonably easy to provide the user with a nice progress report.

The installer asks for a cron key or even allows to generate one, but it doesn't say what it is used for. You need to figure out from other sources, where to put it afterwards.
=> Installer should already contain the information on how the path to the cron script should be put together

Showing reactions doesn't work anymore on latest deployment.

Steps to reproduce:

1. On this page
   https://mitwirkung.dbjr.de/mitmachen/followup/index/kid/24
   Try to click on "Ansehen" (view) of any of the two follow-up documents. No reaction from the system. (The "Herunterladen" (download)) does work though).

2. On this page
   https://mitwirkung.dbjr.de/mitmachen/input/show/kid/24/qid/779946/page/28
   Click on "Reaktionen ansehen" (view reactions) on any of the contributions - an empty page appears

There is the "website address" field on the general settings page: It is blank by default. Yet we would like to see that the installer autofills it, so that the admin user may only need to change it afterwards, if necessary.

You and I have never spoken about this before, so I consider it a new task request. I hope the description is clear and is hopefully easy to implement. I don't need an estimate for that, if it's quick to implement.

It is not being used anymore

I found a problem with the article editing for voting results introduction. It has two elements:

1. The consultation-specific text is apparently not shown in frontend. You can see the place for the missing text box in the “bug” screenshot attached, marked with green. Marked with blue you can see the general introduction to the voting results, which comes from an article in the general settings of the tool (“Erklärungstext Abstimmungsergebnisse (alle)”).
   In the consultation-specific article editor there is the option for the text (see screenshot, it’s the selected one in blue), but somehow it’s not shown in the frontend then.

2. In the consultation-specific article editor there is one option that makes no sense there: in the screenshot attached it’s marked in red. It seems to be redundant to the above-mentioned general introduction to voting results. But a general introduction should not be found in consultation-specific article editor, right? So we don’t really know what it does or where it appears. From our point of view, the option that is marked by red should be deleted. Or is there something that we are missing here?

In several instances of the epartool, the e-mail address [email protected] appears. That mail address should no longer be used. From now on, the more general [email protected] should be used instead.

When the install wizard went through there is a hint to delete the /install folder. Yet, users don't expect to have to use SFTP again - it complicates things a bit. Therefore, an option to remove the install folder by the system, should be added at the very last step.

Please add to the menu visible at /admin/settings a new entry Server info Where relevant info about the server will be listed:

• PHP version
• PHP memory settings
• PHP enabled extensions
• PHP server OS
• MySQL version

This entry should be located at the bottom of the menu and should be visually separated

Please expand documentation to include process for external translation update.

Presently there is no way to validate if Facebook video is public. This is caused by broken mechanism that is supposed to check if video exists and if it is public. This was caused by changes in Facebook API,

With the new API the endpoint returns the following error:

(#10) This endpoint requires the 'pages_read_engagement' permission or the 'Page Public Content Access' feature. Refer to https://developers.facebook.com/docs/apps/review/login-permissions#manage-pages and https://developers.facebook.com/docs/apps/review/feature#reference-PAGES_ACCESS for details.

According to https://developers.facebook.com/docs/permissions/reference a Facebook app needs to be approved by Facebook in order to get the correct permissions to check if video is public. Although it seems strange, I could not find another way.

This means that:

• users can not enter facebook videos
• admins can not edit contributions containing facebook

Possible solutions:

• drop support for Facebook videos
• Figure out how to get the application approved and make sure all installations that use Facebook video get their Facebook application approved as well.

Please update front-end dependencies (BUI) to fix security warnings

Deployments of the ePartool are often done by different people than those who will actually use it. The new users are often a bit too slow to setup their passwords, because the password reset links become invalid already after a few hours. A full day would be more useful.

After selecting the account nothing happens and the user is not logged in. No flash message is shown.

The ePartool has yet to adopt some more secure default settings. As mere HTTP deployments should not be supported anymore, some aspects could be upgraded:

• HSTS headers
• cookies only secure
• protection against various Cross-Site attacks

The following additions to a .htaccess do most of it, but we should be clear whether that approach is the right place. Any thoughts/considerations?

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" env=HTTPS
  Header always edit Set-Cookie (.*) "$1; HTTPOnly; Secure"
  Header set X-Frame-Options "sameorigin"
  Header set Referrer-Policy "same-origin"
  Header set X-XSS-Protection "1; mode=block"
  Header set X-Permitted-Cross-Domain-Policies "none"
</IfModule>

Currently users can't close their accounts without technical support of an admin. Yet such self-managed procedure should be made available. Consequences towards anonymising existing contributions, comments and votes are to be taken into account.

Some minor feature issue that I would like to report:

• The page "motto" and phase names sometimes would require better hyphenation or line breaks. The automatic hyphenation in browsers sometimes creates grammatically wrong breaks in words. HTML has entities for that, e.g. the &hyp; to make breaking suggestions. Unfortunately the entities are displayed as plain text (also unicode characters) – any suggestion how we to make it possible?
• We have gotten requests to allow
  or bold / italics /underline also in the page "motto". Maybe it's the same case like the one explained before.

I'm aware that this may increase the risk that admin users break the design or layout. That's why I would like to restrict it to HTML entities and only the four formating aspects mentioned in point 2.

This issue is not urgent, but a task for whenever resources are free. If the implementation takes more than two hours, I would need an information beforehand.

There should be one log file per day and they should be removed after 30 days by cronjob.

The 30 day period should be configurable via config.local.ini. If set to 0, the rotation should be turned off.

A fresh install of v4.11.1 on PHP 7.2 - the upload of a file to the pre-defined "misc" folder throws an error 500.

(If I understand the application.log correctly, the SQL insert wants a consultation id, but doesn't get any?)

2018-12-06T15:59:32+01:00 CRIT (2): PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1 in .../vendor/zendframework/zendframework1/library/Zend/Db/Statement/Pdo.php:228
Stack trace:
#0 .../vendor/zendframework/zendframework1/library/Zend/Db/Statement/Pdo.php(228): PDOStatement->execute(Array)
#1 .../vendor/zendframework/zendframework1/library/Zend/Db/Statement.php(303): Zend_Db_Statement_Pdo->_execute(Array)
#2 .../vendor/zendframework/zendframework1/library/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#3 .../vendor/zendframework/zendframework1/library/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SELECT cnslt....', Array)
#4 .../vendor/zendframework/zendframework1/library/Zend/Db/Table/Abstract.php(1577): Zend_Db_Adapter_Pdo_Abstract->query(Object(Zend_Db_Table_Select))
#5 .../vendor/zendframework/zendframework1/library/Zend/Db/Table/Abstract.php(1392): Zend_Db_Table_Abstract->_fetch(Object(Zend_Db_Table_Select))
#6 .../application/modules/admin/forms/Media/Upload.php(32): Zend_Db_Table_Abstract->fetchAll(Object(Zend_Db_Table_Select))
#7 .../vendor/zendframework/zendframework1/library/Zend/Form.php(239): Admin_Form_Media_Upload->init()
#8 .../library/Dbjr/Form.php(28): Zend_Form->__construct(NULL)
#9 .../application/modules/admin/controllers/MediaController.php(302): Dbjr_Form->__construct()
#10 .../vendor/zendframework/zendframework1/library/Zend/Controller/Action.php(516): Admin_MediaController->uploadAction()
#11 .../vendor/zendframework/zendframework1/library/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('uploadAction')
#12 .../vendor/zendframework/zendframework1/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#13 .../vendor/zendframework/zendframework1/library/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#14 .../vendor/zendframework/zendframework1/library/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run()
#15 .../www/index.php(31): Zend_Application->run()
#16 {main}

Next Zend_Db_Statement_Exception: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 1, query was: SELECT cnslt.kid, cnslt.titl FROM cnslt WHERE (proj LIKE '%xx%') AND (kid IN ()) in .../vendor/zendframework/zendframework1/library/Zend/Db/Statement/Pdo.php:235
Stack trace:
#0 .../vendor/zendframework/zendframework1/library/Zend/Db/Statement.php(303): Zend_Db_Statement_Pdo->_execute(Array)
#1 .../vendor/zendframework/zendframework1/library/Zend/Db/Adapter/Abstract.php(480): Zend_Db_Statement->execute(Array)
#2 .../vendor/zendframework/zendframework1/library/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SELECT cnslt....', Array)
#3 .../vendor/zendframework/zendframework1/library/Zend/Db/Table/Abstract.php(1577): Zend_Db_Adapter_Pdo_Abstract->query(Object(Zend_Db_Table_Select))
#4 .../vendor/zendframework/zendframework1/library/Zend/Db/Table/Abstract.php(1392): Zend_Db_Table_Abstract->_fetch(Object(Zend_Db_Table_Select))
#5 .../application/modules/admin/forms/Media/Upload.php(32): Zend_Db_Table_Abstract->fetchAll(Object(Zend_Db_Table_Select))
#6 .../vendor/zendframework/zendframework1/library/Zend/Form.php(239): Admin_Form_Media_Upload->init()
#7 .../library/Dbjr/Form.php(28): Zend_Form->__construct(NULL)
#8 .../application/modules/admin/controllers/MediaController.php(302): Dbjr_Form->__construct()
#9 .../vendor/zendframework/zendframework1/library/Zend/Controller/Action.php(516): Admin_MediaController->uploadAction()
#10 .../vendor/zendframework/zendframework1/library/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('uploadAction')
#11 .../vendor/zendframework/zendframework1/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#12 .../vendor/zendframework/zendframework1/library/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#13 .../vendor/zendframework/zendframework1/library/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run()
#14 .../www/index.php(31): Zend_Application->run()
#15 {main}

In the sight of the several data scandals of Facebook in the recent weeks (I'm counting four or five) and considering that it is not successfully used by any of our known deployments, we would like you to remove the Facebook login structure in the ePartool.

Currently the project depends on the grunt-premailer npm package which depends on ruby and the premailer gem.

Currently ruby is not installed in the docker container and the grunt mail command therefore fails. There are two options how to resolve this:

1. Get rid of the grunt-premailer dependency and build mail templates by some other means
2. Install ruby and the required premailer gem into the docker containers

I think solution 1. is preferable as it would simplify the stack and make development and contributions easier.

License descriptions need to be updated:

We need the following texts translated:

Creative Commons license 4.0: attribution, non-commercial

The contributions are published under a <a href="http://creativecommons.org/licenses/by-nc/4.0/deed.en" target="_blank" title="More about creative commons license">creative commons license</a>. This means that your contribution may be re-used in summaries and publications for non-commercial use. As all contributions are published anonymously on this page, this website will be referred to as the source when re-using contributions.

for the following languages:

• fr_FR
• pl_PL
• cs_CZ
• ru_RU
• ar_AE

The ePartool's root directory does not contain any index.php or index.html file. Instead, a .htaccess redirect does the job of pointing to a default document. However, several instances have reported problems with installing the ePartool, because they just didn't see the .htaccess in root. (It occurs with people who use the entire ePartool zip, but not with the web-downloader it does not occur, though)

Therefore it would be useful to have a basic index.php or index.html that says something like "if you see this page, then something is wrong about your configuration. Please check whether the .htaccess is rightly in place."

When manually sending email from the administration to a particular user it is possible to attach a file from the media centre.

This file is not attached correctly and can not be opened by the addressee.

Does the tool need to support Internet Explorer? Presently it partially does as the only things that do not work are:

• reaction timeline
• administration

Dropping support for IE would allow us to not include some polyfills. This would make the JS code smaller and the load times would decrease. Also working on the project would be easier…

Context:
Currently, there is an info bubble over the Contribution phase when the contribution period is running. It says "Contribute now" (or something like that). A similar bubble pops up atop the voting phase, when voting is on.

Several projects have reported to us that a full voting is too complex for their needs, so they would use the "Support" feature as a kind of informal voting. However, their problem is to make it transparent to users that it's not the voting that they need to reach out for, but that the users need to go to the "Contribution" phase and click the support buttons there.

Concrete task:
The wish is that the info bubble atop the "Contribution phase" does automatically change its label. Priority is that it says the "Contribute now" message, just as it is now. But then, if the contribution phase is over, it should check whether the support phase is currently on, and show a bubble saying "Support now" / "Jetzt unterstützen".

We should switch to PHP 7.2 for development as it has become generally available with all webhosters and PHP 7.1's active support phase actually ends by 1st December 2018 (https://secure.php.net/supported-versions.php)

Migrate from Jenkins to GH action:

• run tests for all supported versions of PHP and nightly
• add build shields to README.md
• produce install and update wizzards
• migrate install and update to GH releases section
• update file RELEASING.md

It is necessary to translate validation messages for languages that are not natively supported by Zend. The missing languages are:

• Arabic
• Polish

In the meantime English is used as a fallback.
Attached is a file that contains all the strings for English. GitHub does not allow attaching PHP files so I had to rename it.

Zend_Validate.php.txt

When entering videos in discussion:

1. It is possible to enable video service (i.e. vime) that has no credentials entered. That causes an ugly
   error message.

2. Also I was unable to enter a facebook video as I was getting "not_public" even if it is public.

3. Also I was unable to enter vimeo video as I was getting "api_unavailable"

Add ability to delete user profiles. All content authored by the user should be anonymised.

At the moment the install wizard tells you in its last step to go to the server and delete the /install dir. However, it would be much more helpful, if the install wizard offers to do that itself – if the rights for deleting are available.

The wizard deleter should try to delete the following:

• /install dir
• epartool-downloader.php script in root (from installer perspective: it's a hierarchy step above, so it's ../epartool-downloader.php )

In the screen shown bellow the modal overlay can only be closed by clicking the cross with mouse. It would be helpfull if it could also be closed by pressing the Esc key.

Bootstrap modal does that natively, so there is likely some error somewhere.

After a fresh install of v4.11.1, there's a first consultation as example. However, the media folder for that particular consultation doesn't exist. It should come pre-defined as well, because new backend users would have no idea or comparison how to name it properly via the backend.

1.Currently it uses version 8 for building assets. This version is not supported anymore.
2. We should not depend on the bower package manager. It is not supported anymore. We should depend for all packages on the npm registry.

For the use of "Let's encrypt" SSL certificates, the verification process needs to access /.well-known/* , but ePartool's default .htaccess would not let that through. A directive to allow that should be added.

During installation there is no mechanism to detect permissions of application/configs/phinx.local.yml.

If the permissions are wrong the user is not informed and general error Something went wrong, we could not create the installation. is displayed.

The gender*star is more common nowadays, so DBJR decided to switch.