- safari gets now recogniced as browser by the html-class
- html::htmlarea show's a textarea if HTMLarea is not availible (suppresses error with safari)
- dont show button to convert to html if:
* HTMLarea is not availible for the browser
* admin disabled it in the wiki configuration
- cat_id is varchar, so the id's in "cat_id IN ('1','2')" have to be in single quotes for MaxDB
- search on text-columns:
* MsSQL need to cast the column to varchar
* MaxDB cant do it at all
used by wiki and sitemgr in mind. However, if you mark a normal user as anonymous just to avoid being shown in sessions and access log (like you would for an admin that doesn't want to be noticed), the user won't be able to login anymore. That's why I allow now anonymous users to get a home :)
If you are invited to a private event, you get full access to it, as you would if it were not private. Only restriction is: other people you gave access to your private events, still cant read the event, as long as they have no direct private grant from the owner of the event.
If you are invited to a private event, you get full access to it, as you would if it were not private. Only restriction is: other people you gave access to your private events, still cant read the event, as long as they have no direct private grant from the owner of the event.
characters in filemanager, for exmaple, files that contain Chinese
characters.
Reason for producing the bug: One parameter of "fwrite"
is "strlen ($data['content'])". To multibyte character, "strlen" can
not return its actual length. So "fwrite" cannot write all characters
to the created file.
let alone view the event details. invitees are now allowed to view the event
details as well as accept their invitation to the event.
NB:
- if an invitee has granted another user private access to the invitee's calendar, the user
to which private access has been granted is UNABLE to view the details of the event.
- if the person who created the event and marked the event private has granted another user
access to that person's private events, then the person granted private access WILL be able
to see the details of the event.
- at most, uninvited third parties will only see that a private event is taking place at some
time, but only if they have at least read access to the calendar of one of the people invited
to the event.
I hope this makes sense. I've tested this extensively to make sure I am not accidently granting
access to private events that should be kept private.
