On 7/31/2015 11:38 AM, Steve Ankeny wrote:
On 07/31/2015 10:03 AM, Chris Coleman wrote:
On 7/31/2015 9:27 AM, Steve Ankeny wrote:
On 07/31/2015 09:08 AM, Chris Coleman wrote:
On 7/31/2015 8:08 AM, Steve Ankeny wrote:
On 07/31/2015 07:36 AM, Khapare Joshi wrote:
My SOGo version is 2.2.16 (root@shiva.inverse 201502121141).
Something has changed in this version, some reason in my calendar
names are not recognizable, instead it prints as : 147F-4Dcc ....
But if I create a new calendar i.e test it is normal.
I have attached the screen-shot. anybody has an opinion on this ?
K
Are the alpha-numeric-named calendars "shared" calendars from
other users?
If so, that would seem to indicate the issue has to do with the
authentication of users -- a scrambling of usernames -- i.e.,
LDAP, SQL, Samba-AD, Microsoft-AD, etc. How are you
authenticating users?
Where is user data stored? It may also simply require a "fresh"
sharing from the original user.
It might also be helpful to know your OS, etc.
Shouldn't the sogo web user interface display a sensible, detailed
error message to the user, if it's indeed encountered a problem
when attempting to authenticate/authorize the user's access to some
shared calendars. Because displaying 64 digit GUID numbers to the
user instead of calendar names, with no explanation, doesn't work.
Have you checked the relevant log file?
Good idea, but normal users don't have access to global system log
files!
Users still need to know what when wrong (for example, unable to
display certain shared calendars) and why (authorization failure on
server xxx with username yyy) and how to fix it by themselves (go to
whatever settings page on some menu and try entering correct
username/password), or who to contact for help (sogo mail sys admin).
That's a different issue than "fixing" the problem.
Sorry! I was under the impression the OP wanted to fix his
calendars. What you're suggesting may be a feature request but may
have little to do with actually fixing the problem. The questions I
asked may help.
Right! My point is, the app should contain informative error messages
for every foreseeable error condition, that guide the user to fix their
own error most of the time, get help from their sogo mail sys admin some
of the time, and finally resort to the mailing list in very rare
situations when an unforeseen error occurs and the app doesn't have a
built-in informative error message to guide the user to fix it
themselves. Without this, basic level 1 help requests flood the mailing
list...
--
users@sogo.nu
https://inverse.ca/sogo/lists
