Hi all,
Radicale CalDAV/CardDAV is now available for BlueOnyx 5210R as well.
A week ago we released a Radicale CalDAV/CardDAV integration for
BlueOnyx 5211R. This has now been ported over to BlueOnyx 5210R as well.
It will automatically installed during the next YUM/DNF update of your
server.
News article:
https://www.blueonyx.it/news/325/15/5210R-Radicale-CalDAVCardDAV/
Link to the documentation:
https://www.blueonyx.it/organizer
BlueOnyx 5210R code changes in SVN:
https://devel.blueonyx.it/trac/changeset?reponame=&new=4709%40BlueOnyx%2F5210R&old=4685%40BlueOnyx%2F5210R
I could re-use almost the entire 5211R base-organizer module and just
had to modify one handler a little. But getting the 5211R GUI pages to
work on 5210R turned out to be a bit of a challenge. It reminded me
again how much 5211R has advanced and I had lavishly used functions in
the GUI page that simply weren't present in 5210R.
So ... I had to go back and add these to 5210R as well to make this (and
future) module conversions easier. This is why it took a whole week to
get this done.
Until 5211R we had no "good" way to pass error messages that happened on
one page on to a another GUI page to present them. Or show the errors in
the same GUI page after a reload. What we had for that were crude work
arounds, which weren't that practical. In BlueOnyx 5211R we use PHP
session storage for that purpose (and others) and that has turned out to
be very beneficial and much easier to use.
This mechanism has now been added to 5210R as well. At least for the
error handling.
For these reasons the Class BxPage.php on 5210R inherited the following
new/modified functions:
$BxPage->ReturnToThisPage($errors, $redirect_URL);
Redirects the GUI to a specified GUI URL and passes an array of error
messages to it for display.
$BxPage->setErrors($errors)
$BxPage->getErrors()
These functions already existed and now use PHP session storage to
retain error messages until we've had a chance to display them. Or until
the next POST request against the GUI happens.
$BxPage->setFormUrl($url)
Allows to change the form target of GUI related POST forms to another
GUI page. We could do this already in another way, but this is a lot
simpler.
$BxPage->setGETPOST($val)
Tell BxPage to fetch all GET and POST requests (as well as the
user-agent and browser-version of the visitor) of the current GUI page.
$BxPage->getGETPOST($val)
Returns GET, POST or AGENT info of the current GUI page as arrays.
Likewise the helper blueonyx_helper.php got updated a litte:
init_libraries() now tells CodeIgniter to load the "session" library.
GetFormAttributes() is now more in line with what 5211R does and
integrates the required key checks for form input fields that we had
marked as required. It then stores errors directly via
$BxPage->setErrors($errors) to keep them "on file" until we can present
them.
Added getUserAgent() function to fetch the user agent and browser
version of the visitor.
Capabilities.php and ServerScriptHelper.php got extended with a
capability check that so far was unique in 5211R:
if (!$CI->getAllowed('validUser')) {
// Nice people say goodbye, or CCEd waits forever:
$CI->cceClient->bye();
$CI->serverScriptHelper->destructor();
Log403Error("/gui/Forbidden403");
}
With that simple and "cost effective" check we can test if the user
accessing that GUI page is a 'validUser'. Means: He is a valid user,
known to CODB and is currently successfully logged in.
We use this simple check on GUI pages with the lowest privileges that
are accessible to all logged in users. Basically anything that's
reachable under "Personal Profile". So far 5210R (and older) used a
check that was slightly more complex and cost a few CPU cycles and CODB
accesses more.
Existing GUI pages for 5210R don't need any changes to continue to work
and these added functionality provides simplified and better options for
future changes and modifications. So this is a good compromised and
investment into the future of 5210R.
The idea to port the whole 5211R GUI to 5210R is still on the table for
the general speed improvements, easier code maintenance and simplified
coding of future enhancements. Yet: It would really rock the boat and
that's why I'm reluctant to do it. Instead there might be more gradual
changes to the existing 5210R GUI to selectively port individual
enhancements from 5211R over.
--
With best regards
Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
