3.4 development was shifted for one month, moving tickets to reflect reality better.

I think this is covered by the user life cycle feature designed in #3911.

In all cases, before a user is put into production, he may reside in staging tree. When he joins the company, helpdesk moves him to active. When the user/contractor/temp worker leaves, he is moved to deleted users tree. Alternatively, his principal will just expire, account will be there, but user won't be able to log in.

If the user comes to company again, he is either pulled back from deleted users tree or principal expiration is moved.

Unfortunately it is NOT covered by the user life cycle management feature.

Here is a simple example. You have a contractor who starts on Monday at 7AM so his account should be enabled at that time. But admin does the work on Friday to create his account and move him from staging to the main part of the tree. In this case the fact that admin moved him does not mean that account should be active during the weekend.

This feature is affectively to add time related attributes to the user account. If the time is outside of the defined window the user account should be treated as inactive.
IMO the validity of the account should have the same scheduling capability as we planned for time component in access control rules. May be it even can be accomplished via access control rules (under the hood) but it should be applicable to any authentication not only HBAC.

Well the contractor can't login until he sets a new password, which I assume it would happen when he shows up the first day.

I am not sure this scenario is very realistic.

If the password is somehow preset then admins can always lock the account until they feel it is ok to unlock it.

May be it is unrealistic but this is how it was presented to me. I suspect there is some pre-set password that is sent to the user and should be used during first login. This can be easily automated and I suspect it is a part of the work flow here.

We decided to push this out of 3.4, it is not a priority for this release. Should be addressed/discussed along with #3911.

Starting to shape next release

Processing leftovers from 4.2 backlog - this ticket was found as suitable for consideration in next big feature release - 4.4.

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.