[BlueOnyx:26358] Re: BlueOnyx 5210R: Radicale CalDAV/CardDAV integration released

[Michael Stauber]

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