On 11/08/12 16:27, Dominique Dominique wrote:
Let's be honest, the RTFM answer is a bit dry, but you're right we
should pay closer attention to it.
It's not dry, it's a fact. The documentation is there and we spend a
great time writing it. If you think it can be improved, send
improvements directly.
A good idea would be to identify clearly the changes in the manual -
when an option is being introduced or modified or when it has been
deprecated and/or replaced. That would make reading the manual more
user friendly, update after update.
We already mention new options when we make a release. Mentioning that
over and over in the doc would clutter it.
I saw that part in recent version of the documentation, but It's less
than obvious to derive from those pages that you have to create those
two fields in the SQL table to be able to use the functionality.
Furthermore the authentication table is provided by the application
itself, so one could expect the columns to be already present - or to
be part of the upgrade process as other table/columns are added/modified.
You're wrong. The authentication table is not provided by SOGo at all.
In the documentation mentioned, several other fields are also optional
- should they also be added to the same table?
If they are mentioned as optional, why should they be added?
--
Ludovic Marcotte
+1.514.755.3630 :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
--
[email protected]
https://inverse.ca/sogo/lists
