Posted by: Scott Willhite
6/30/2006 4:00 AM 

As I mentioned... in particular order!  So lets continue, shall we?

• It seems that the previously mentioned error on an empty HTML/Text module is related to some other errors as well... and both related to caching.  See the latest version of the HTML/Text module defaults the module's cache time to 600 ( 5 minutes ) which is VERY cool ( since nobody ever remembers to do that ).  But somehow the module caching is not working too will with the inline editing nor the initial creation of the default text.  If you edit the module once & save, the issue goes away.
  
  But alas, the HTML/Text module is having another very odd issue somehow related to caching.  Our project pages all have module descriptions which should be editable by the Project Leads.  However, we discovered recently that they could NOT edit them anymore?  They don't even get the action menu item that would let them try.  Enter caching again... for some strange reason, if you turn module caching back to -0- their permissions return.  Mind you, this is only affecting the HTML text module and users in roles with Edit rights to the module ( Page Admins work fine ).
  
  Lastly... I have not fully documented it yet, but have noticed some erratic behavior with edit-in-place and cache.  That is... if I go to the Edit page after having made a change in the edit-in-place... the OLD text is there?  Hmmm...
  
• Most of the folder issues seem understood now.  However, we're on to new issues in the folder permissions.  Interestingly, there's some bad behavior left over from the 3.x versions and it appears a few items to tidy up still in 4.3.
  
  The 3.x versions weren't terribly consistent in honoring the folder permissions everywhere.  But in version 4.3 this is all being enforced... which is bubbling some issues to the top.  Couple things...
  
  >> First ( and this has already been corrected in the Vault ), the All Users roleid ( -1 ) was being assigned READ/WRITE access to every folder.  Oops.  Which would have meant that any poster in a forum could have uploaded files to your file system or, at a minimum, browsed to see where all your files were ( presuming the file picker was working... thats another story ).  Similarly... the Portal Admin role needed to have READ/WRITE access granted to it.  It had READ... but we had to go back and inject WRITE as well.  Thank you Charles Nurse for this bit of SQL which will take care of all the Portal Admin rights in your install:
  
  DECLARE @ReadPermissionID int
  DECLARE @WritePermissionID int
  DECLARE @AdminRoleID  int
  DECLARE @PortalID   int
  
  /* get the PermissionID for READ permissions on the SYSTEM_FOLDER */
  SELECT @ReadPermissionID = PermissionID
  FROM   {databaseOwner}{objectQualifier}Permission
  WHERE  PermissionCode = 'SYSTEM_FOLDER' AND PermissionKey = 'READ'
  
  /* get the PermissionID for WRITE permissions on the SYSTEM_FOLDER */
  SELECT @WritePermissionID = PermissionID
  FROM   {databaseOwner}{objectQualifier}Permission
  WHERE  PermissionCode = 'SYSTEM_FOLDER' AND PermissionKey = 'WRITE'
  
  /* Iterate through each portal */
  SELECT @PortalID = min(PortalID)
  FROM   {databaseOwner}{objectQualifier}Portals
  WHILE @PortalID is not null
  BEGIN
  
  /* get the Administrator Role ID */
   SELECT @AdminRoleID = AdministratorRoleID
    FROM {databaseOwner}{objectQualifier}Portals
    WHERE PortalID = @PortalID 
  
  /* remove any records which already exist to avoid a duplicate key error on the insert */
   DELETE
    FROM   {databaseOwner}{objectQualifier}FolderPermission
    WHERE  (PermissionID = @ReadPermissionID AND RoleID = @AdminRoleID)
     OR  (PermissionID = @WritePermissionID AND RoleID = @AdminRoleID)
  
  /* give Administrators READ access to unsecure folders */
   INSERT INTO {databaseOwner}{objectQualifier}FolderPermission
    SELECT FolderID, @ReadPermissionID, @AdminRoleID, 1
    FROM {databaseOwner}{objectQualifier}Folders
    WHERE PortalID = @PortalID
  
  /* give Administrators WRITE access to unsecure folders */
   INSERT INTO {databaseOwner}{objectQualifier}FolderPermission
    SELECT FolderID, @WritePermissionID, @AdminRoleID, 1
    FROM {databaseOwner}{objectQualifier}Folders
    WHERE PortalID = @PortalID
  
  SELECT @PortalID = min(PortalID)
    FROM   {databaseOwner}{objectQualifier}Portals
    WHERE  PortalID > @PortalID
  END
  
  >> Second... there's probably a real good chance that you have a lot of duplicate folder permissions.  I'm not 100% certain if this was introduced in 4.3 as a result of the folder duplication ( the "//" issues )... but it is possible to have a lot of basically duplicate entries in the FolderPermissions table.  We'll be introducing an index to keep that from happening in the future, but you can also run this handy SQL statement to delete your duplicates as well:
  
  DELETE FROM FolderPermission
  WHERE FolderPermissionID NOT IN (
   SELECT DISTINCT MIN(FolderPermissionID) AS FolderPermissionID
          FROM FolderPermission GROUP BY FolderID, RoleID, PermissionID
  )
  
  

And that's enough for the moment *grin*

Trackback Print

Tags:

Categories:

Location: Blogs Scott Willhite