This will allow administrator to change default value and be reflected at user level
Depends on D28128.
Note that the docu for KConfigGroup::hasDefault has this logic too:
if ( (value == computedDefault) && !group.hasDefault(key) ) group.revertToDefault(key); else group.writeEntry(key, value);
With the reasoning that we want to avoid writing out the value if the value is equal to computedDefault, UNLESS there's a system file that says otherwise.
Your change seems to break this.
I see the overall setup as this, ordered by priority:
[C++ computed default] < [system config files] < [user kdeglobals] < [user app-specific config file]
!hasDefault() checks [system config files] and therefore should stay. Otherwise, when the situation is C++=1 system=2 and value to be written is 1 you'll revert() i.e. not write anything and then re-read 2, oops.
Sounds like you should add a unittest for this case, to detect this regression...
Is this needed? Nothing uses glob after this point.
This means defaultEntry is now unused, and therefore defaultKey too.