Set user time zone to default to location time zone

[shill]

I would like to be able to set the time zone for a location and for users that have that location in their user record, to have the location time zone as their default time zone. As our proposed feed of user data does not indicate time zone preferences, just looking for an easier way to default the time zone on the initial and subsequent loads of user data.

For example.
Joe Smith's user data is imported to the user record with a location of Dallas, TX. The system then sets Joe Smith's time zone in his user record to what is indicated as the time zone on the location record for Dallas.

I would think this would be possible with some scripting in the user time zone field default value, or am I way off?

[shill]

Not sure why they would set this as a business rule.  The script shown was only meant to be run once and was created as a scheduled job only because it was before fix scripts were a thing.

Are there any conditions on that business rule?   Curious as to what SN said was the cause of the outage. Even if that business rule was triggered, it should only updating user records that did not have time zones set.  Unless there is some other business rule that is causing a loop of some sort.  I suppose someone could set a business rule to run if the locations time zone changed to update all users for that location, but does that really happen??  And that BR would not do that.

The business rule we created was a simple one that triggered when the user location changed on insert/update, and just matched the user time zone to that chosen location as described above.

current.time_zone = current.location.time_zon

[jas101]

Thanks for the quick reply. I figured you did not intend the script as a business rule (BR) when I came across this thread.

No there are not any conditions on the BR in our instance which if I am then understanding it correctly, means it is looking at all user records (over 26k in our SN)! Furthermore can I check doesn't this line which includes the 'nil'...

 if (!gr.location.time_zone.nil())

actually mean if the user's location's time zone does NOT = empty, make the update (match user timezone to user location timezone)? I.e. instead of looking for user's who do not have a time zone value it is actually doing the reverse by looking for user's who do?

Your simple BR 'current.time_zone = current.location.time_zone'

on change of user location makes sense to me but I guess we need to establish what the best way to 'bulk' update the location time zone values is (and subsequently the user time zone values) so all (active) users have a time zone value set (two-thirds of active users do not currently so are using the system GMT one). Is a scheduled job the best way to achieve this? Thank-you.

[shill]

Correct.

The nil() check is to avoid setting a time zone of a user to blank because the location time zone was empty.  In our instance, we defaulted to the time zone of the company's headquarters. This was to update all the field users time zones.

So, we didn't want to update the default IF the location they were at was not set to something different from the default, if that makes sense.

I would suggest a fix script now over a scheduled job. The only reason I did a scheduled job back then is to verify the script syntax with the script field instead of making a mistake in a background script.  Fix scripts provide that now.

If I am understanding your requirement correctly, your locations currently do not have time zone values, and when that is set, you need to update any user associated with that location to that location's time zone??

If that is correct, I would probably use an after business rule (with time zone changes condition) on the location table like this:

var user = new GlideRecord('sys_user');
user.addQuery('location', current.sys_id);
user.query();
while (user.next()) {
	user.time_zone = current.time_zone;
	user.update();
}

You could then update users location by location (and be able to manage the impact by trying a small location first).

Whatever you do, I would definitely try this in a sub prod instance first to gauge the impact. 

[jas101]

Thanks. I'll need to look-up fix scripts as I'm not familiar with them although I thought they were something you would run e.g. as part of an application install.

I'm continuing with testing in sub-Prod instance but so far using the below as a background script (at least for now) to bulk update users after a Time zone is added to a Location record:

gs.log("Set Users Time Zone> START " + gs.now());
var gr = new GlideRecord('sys_user');
gr.addQuery('active',true);  
gr.query();
while (gr.next()) {
   if (!gr.location.time_zone.nil()) {
      gr.time_zone = gr.location.time_zone;
      gr.setWorkflow(false); // Don't run business rules for this update
      gr.update();
   }
}
gs.log("Set Users Time Zone> END" + gs.nowDateTime());

and the following as a before insert/update sys_user business rule to account for subsequent updates - I added conditions to the BR to account for updates if a Time zone is not set that could be or when a user location gets updated (and a time zone for that location is available) and both seem to be working OK/as expected (the script took approx. 20 seconds to run when it had 1250 users to update, note setWorkflow is set to false).

Please let me know if you see anything out of place with either. Thank-you.

[shill]

That all looks OK to me, but if you continue to add time zones to locations, that script would run again for those that have a time zone set already?

The assumption is your locations currently do not have time zones set (other than maybe the one you tested with that had 1250 users). If you set another and run that script, it would run for both that one and the original (since the location's time zone is not longer empty).

You break this up since you have so many users, you might add some limits to which location it is being affected. That was the reasoning behind the after business rule to trigger changes to users that have that location, so you could do them in a location by location batch.