The familiar scenario:

1. Admin enables extension, and assigns permissions specific to that extension to a role.
2. Admin disables the extension.
3. Role settings still show the checkbox for the permission.
4. Admin unchecks permission.
5. Permission neither disappears, nor is it disabled.
6. Admin sighs deeply, because manually fixing the problem is a pain.

The cause:

The record in the database for the associated role contains a permission that Vanilla doesn't understand, but Vanilla takes steps during a role save to ensure that it's not affected, assuming it belongs to another application. Further complicating the issue, the Role object doesn't know anything about what's in the database while reading form data, so any unchecked orphan permissions are not initialized with a default value, and thus take on the value from the database during save.

A possible solution: don't store permissions that evaluate to boolean false, and fix Vanilla to properly deal with orphans that are unchecked. Will test this soon (haven't yet), but I think it'll work.

Insert at line 67 (before array serialization) of People.Class.Role.php (using svn rev - 738):

// Remove permissions that were unset.
// Note: Regardless of which application created the permission, all should be able to remove it.
while (list($key,$value) = each($this->Permissions)){
if (!ForceBool($this->Permissions($key)){
unset($this->Permissions($key));
}
}
Insert at line 79 (right after getting the role id from form data):

if ($RoleID != 0){
// Get the current permissions from the database before reading form data.
// Ensures that behavior is consistent with how permissions are saved and displayed.
$RoleManager = $this->Context->ObjectFactory->NewContextObject($this->Context, 'RoleManager');
$ExistingRole = $RoleManager->GetRoleById($RoleID);
$this->Permissions = array_merge($this->Permissions,$ExistingRole->Permissions);
}

I think it would need to go in GetPropertiesFromDataSet, but you're right, there would need to be logic to check for the absence of a permission that defaults to 1.

I'd like to explore this further, but I'm gonna have to do a fresh install from svn, cause I think I might be getting bit by an extension or something...

I fixed a couple errors in my code above and did a test run, and got the desired result in terms of what's stored in the database, but the permissions form for that role no longer showed up right. When a role object is created, it's supposed to fill its permissions array with defaults from the Configuration array, which it does do as far as I can tell; however, all those default settings are getting blown away somehow, by the time GetPropertiesFromDataSet is called. It's bizarre. :-/

Obsessive compulsive?

Yes. :-)

I kinda had an idea in mind I wanted to pitch to you guys, though. Maybe I won't have time to work through the details after all, but I never liked the way Vanilla did permissions, if for no other reason than the full data structure is stored in a single database column, instead of handling permissions as a separate table. I also think it's easiest to manage permissions when you're only keeping track of what a role *is* allowed to do, and the rest is only important in the settings screens.