[Freeipa-devel] group inactivation question

[Rob Crittenden]

Karl MacMillan wrote:
> On Tue, 2007-11-06 at 14:29 -0500, Rob Crittenden wrote:
>> Ticket https://hosted.fedoraproject.org/projects/freeipa/ticket/54 calls 
>> for an option to inactivate all users in a group.
>>
>> I've got this mostly done on the GUI side. I added a similar option to 
>> mark a group as active/inactive and it too updates nsAccountLock.
>>
>> So in XML-RPC when a group is updated I can see if this is "true" and 
>> mark all the members as inactive. But this opens a real can of works.
>>
>> Groups can be members of groups. Should I follow all paths and 
>> recursively mark everything inactive?
>>
> 
> I say no - I think this behavior would be surprising, but who knows.

Well, I've assumed yes for now and have a recursive function that 
inactivates everything.

Perhaps in the GUI I can bring up a dialog to confirm that this will be 
a recursive change. Would that be less surprising?

>> And does the reverse hold true as well? If a group is inactive and it is 
>> marked active does that cause everything to become active again? I 
>> assume so but I hate assuming.
>>
> 
> I assume so as well.

Ok, that's what I've done.

> 
> BTW - are you fixing the whole deluser is actually inactivation issue so
> that we can both delete users and inactivate them?

I have a partial patch to at least fix some semantics. What I plan to do 
is update ipa-userdel to handle this, just haven't decided exactly how yet.

We also lack a command-line re-activation tool (other than ipa-usermod 
--del=nsaccountlock <uid>)

I need to allow cmd-line group de-activation as well.

Unfortunately I have totally hosed my development FDS instance which is 
making some testing difficult. I want to keep this instance around for 
future testing of fixes, so I'm kinda stuck.

I wanted to make sure that my recursive function could exist so I added 
a set of circular groups (A member of B, B member of C, C member of A). 
Seems to have been a bad idea.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071107/a35c96c3/attachment.bin>