Bug 119841

Summary:	enabling of the normal permission dialog takes effect only after closing after doing changes on acl
Product:	[Unmaintained] kio	Reporter:	urwald <urwald>
Component:	kfile	Assignee:	Till Adam <adam>
Status:	RESOLVED FIXED
Severity:	wishlist
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description urwald 2006-01-10 08:55:42 UTC

Version:            (using KDE KDE 3.5.0)
Installed from:    SuSE RPMs
OS:                Linux

Depending of using or not using acl's or unusual permission combinations, the normal permission dialog elements are enabled or disabled. When disabled, you have to use the button "Advanced permissions" to get the acl dialog.

When I do changes in the acl dialog, and these changes affect the state (enabled or disabled) of the normal permission dialog, this doesn't take effect after clicking "apply" or "ok" in the acl dialog, but only after closing and reopening the hole file properties and permissions dialog.

Maybe it would be nice when this would take effect directly.

Comment 1 Till Adam 2006-01-16 18:25:44 UTC

SVN commit 498933 by tilladam:

Make sure the base permission widgets are properly enabled or disabled
when the ACLs change for files only.

BUG: 119841


 M  +2 -2      kpropertiesdialog.cpp  


--- branches/KDE/3.5/kdelibs/kio/kfile/kpropertiesdialog.cpp #498932:498933
@@ -2125,8 +2125,8 @@
   }
 #endif
 
+  updateAccessControls();
   emit changed();
-  updateAccessControls();
 }
 
 // QString KFilePermissionsPropsPlugin::tabName () const
@@ -2266,7 +2266,7 @@
     enableAccessControls(false);
     break;
   case PermissionsOnlyFiles:
-    enableAccessControls(d->canChangePermissions && !d->isIrregular);
+    enableAccessControls(d->canChangePermissions && !d->isIrregular && !d->hasExtendedACL);
     if (d->canChangePermissions)
       d->explanationLabel->setText(d->isIrregular || d->hasExtendedACL ?
 				   i18n("This file uses advanced permissions",

Comment 2 Till Adam 2006-01-16 20:29:31 UTC

*** Bug 119375 has been marked as a duplicate of this bug. ***