Currently the Permission Names are hard coded, so no table contains the Permission Name.  Two tables contain the Permission values (jiveGroupPerm and jiveUserPerm).  Not having a table contain the Permission Name is causing a problem for a Permission Audit Report.

I developed a work around, but it is a lengthy process and does not satisfy the user requirement that it be an on-demand report.  Currently I must copy the data from the Permissions tables into a .cvs file.  Then I copy the .csv file from the Jive server to my desktop. Then I import the file into Excel.  A key in the Excel spreadsheet converts the permission value into the permission name.  I must execute this workaround when users want to audit permissions because they are unable to use the report without the permission name.  Not an ideal solution.

I propose creating a new database table called jivePermDesc that would hold two data elements:

1) Permission - Permission value (bitmask of all permissions the group has on the object).  This is the Primary Key

2) Permission Name - Description of the permission value (Create_Thread, Create_Message, Read_Document, etc....)

Storing the values in a table is a better design than hard coding them anyway.  The spreadsheet Karl attached in my thread located here:

http://www.jivesoftware.com/jivespace/message/198815#198815 shows about 30 permission values that are currently reserved for future use.  There are a total of 66 permission values.  Hard coding all these values isn't a very good design for system maintenance, scalability, etc...

Creating this table would take about an hour or two to get it into production and that is all that we need.  I'm not asking for Jive to change its existing code. In fact, Jive wouldn't need to use the table until it felt the table would be more beneficial than continuing to hard code the permission values.  If Jive would like to use the jivePermDesc table instead of keeping the permission codes hard coded, my guess is it would take no more than 3 days to change the code and test.  Another "day" to load it into production.  Again, Jive wouldn't need to use the table until it felt like moving to it, but it would save your customers a lot of hours and eliminate a lot of frustration.

So, Jive would save users many hours of executing a work around for an hour or two of work to create the new jivePermDesc table.  Seems reasonable to me. 

Until then, I'm stuck having to export the tables into a CSV file, then import the file into Excel and use a key in Excel to convert the permission values to permission names.  Arghhh! 

Regards,
Mark