We use the user settings for subsitutes for ourselves and our customers. In order to be able to set not only the notification but also the permissions via NACLs not only for Employee.M-Files-User but also for the substitute users and usergroups we had to write an hourly background job which synchronizes the settings with the properties Subsitute users and Substitute user groups on employees according his/her user setting if they have changed it.
So far so good. But shortly we had a collegue who gets ill for a longer time and had not the chance to set his substitute user before and also not now because he is not able to use a computer at the moment.
That's why I found out that it is not possible to change this setting for this user as an administrator which is a necessary feature.
Btw.: The hourly task would not be necessary if there would exist an event handler on the saving event of the the user settings where I can implement the changing of the employee object when the user (or admin) changes the substitute setting - and discard changes if the logic in the event handler throws an exception -. same as you can implement within a vault application for the AfterCheckinChanges event of objects. This would be a much more stable implementation than such an hourly sync job.
Changing this setting by admin would also have the advantage that the user could change this on his own employee object as well - or also that the secretary could be authorized to change this on behalt of their boss if wanted. Would be good to have this in one of the next releases:
- allow admin to change user setting (I guess all user setings would be good then if the person cannot do this for him-/herself.
- add an event handler to VAF including C# snippet for handling substitute changed (or user settings changed in general) events and get the old version of user settings also as "PreviousVersion" property like available on ObjVerEx.
Setting substitute by using new Web Client would also be necessary to have a complete package where this setting makes sense. Otherwise this option should be declared as discontinued because it is no function which you can deliver in a way that it makes sense at the moment - and also have no possibility to customize this via ComAPI and without big hacks with direct database actions which I would like to avoid...
