Hi dear roundcube community,
First of all, I wish you all a happy new year.
I am the maintainer of the automatic_addressbook plugin (or at least I
used to be, as I don't have much time for it now, and I would be happy
to have it integrated in roundcube default plugins if you want, but
that's an other story) .
I regularly get issues from users regarding database prefix when
installing the plugin. I understand this is complicated to handle when
installing manually, but it seems to also be the case when using
composer (At least I got reports about failed SQL statements when
installing with composer)
As far as I can see, SQL statements in roundcube codebase have no
prefix, as my sql statements in my plugin. How are database prefix
handled when installing roundcube? How are they handled when installing
a plugin with composer? (ok, I found how, see below)
I have 2 concerns:
- One is table creation (CREATE TABLE statements), on which prefix
should added. Is that handled automatically by composer? (It seems to be
the case)
- The second one is foreign keys that reference roundcube standard
tables like REFERENCES `users`(`user_id`) which should be changed to
REFERENCES `PREFIX_users`(`user_id`). Is that automatically handled by
composer at plugin installation? (It seems to be the missing one)
Is there any documentation for plugin coders on how to properly handle
plugins databases with references to standard roundcube databases
regarding database prefix?
As far as I can see here:
https://github.com/roundcube/plugin-installer/blob/0.1.6/src/bin/rcubeinitd…
This problem is already handled for CREATE DATABASE statements and for
CREATE SEQUENCE statements but not for REFERENCES statements as used in
the automatic_addressbook plugin here:
-
https://github.com/sblaisot/automatic_addressbook/blob/master/SQL/mysql.ini…
-
https://github.com/sblaisot/automatic_addressbook/blob/master/SQL/postgres.…
I should be able to propose a PR on plugin_installer for that. Is there
something more I need to be aware of before coding?
Best regards and keep making such a good webmail!
Sebastien
TL;DR: We have Roundcube in-browser tests on Travis.
I rewrote old Selenium-based tests created long time ago. These were not
working and I guess no one payed attention to them. Now, it should be
easier and better in many ways.
New code uses Laravel's Dusk (and Facebook/WebDriver) with PHPUnit which
is a nice and powerful framework for functional testing.
This means:
- setting up testing environment is very easy,
- writing tests is simpler and we can do much more,
- thanks to SQLite and GreenMail software you don't need a real
IMAP/SMTP nor database server, you also don't need a HTTP server,
- we test Elastic only, and we test all modes desktop/tablet/phone.
- via Travis tests are executed on every commit and pull request. Which
technicly means you don't even need PHP to write tests, just write code
and do a pull request ;).
Now, I would love to see pull requests coming that add some more
in-browser tests. If you'd like to give it a go, I propose to start with
Preferences UI tests. There's Settings/Preferences/General.php file you
can use as a base for testing other Preferences sections.
See also tests/Browser/README.md
Happy New Year everybody!
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Dear subscribers
We start the year 2020 with the second service release to update the brand
new Roundcube Webmail version 1.4.
It contains fixes and improvements reported since the release of version
1.4.0. See the full changelog in the release notes on the Github download
page [1].
This release is considered stable and we recommend to update all productive
installations of Roundcube with this version. Download it from
https://roundcube.net/download.
Please do backup your data before updating.
Happy New Year everybody!
Alec & Thomas
[1] https://github.com/roundcube/roundcubemail/releases/tag/1.4.2