Assigning policy to groups

Hi

I want to assign policies to groups in LotusScript. The same is possible for users, but I cannot see a method or property of a class that can do this for me.

Is it possible in LotusScript to assign a policy to a group?

In the administrator client I have manually assign a policy to a group. But Nowhere on the group document I see the reflection of this. The document property of the groupdocument shows me that no change has been done to the document. What changes are done by the manually assigning of a policy to a group?

regards

Subject: Assigning policy to groups

Q: What changes are done by the manually assigning of a policy to a group?

A: The person docs for all members of the group are updated to reflect the policy assignment. As you noted, no change is made to the group doc itself.

NOTE THAT this means that if you apply policy to a group today and then add someone to that group tomorrow, the newly added person will NOT receive that policy assignment. In other words, there really is no such thing as assigning policy to a group.

Subject: RE: Assigning policy to groups

Hi Bruce

Thank you very much. No I understand. I have also heard that when assigning a policy to users and after that made some changes to 1 of the settings the changes are not allways reflected in the desktop environment of the user. To make sure that the changes will be reflected an scheduled agent has to be enabled that will place the current date in a '$'field. Do you know something about that?

Regards

Subject: RE: Assigning policy to groups (LONG)

You are, I assume, referring to Jen Cohen’s excellent posting about making Desktop settings apply consistently by modifying a specific field in your settings doc via a scheduled agent. The point of her posting was how to get around the problem that if you DON’T change a settings doc, those settings won’t reapply to the user continually. (In other words, I apply a policy to a user that sets their client to always prompt to save when sending mail, but the user later changes that setting in their preferences back to always save without prompting. Unless the settings doc is modified again, my settings won’t be reapplied to the user, and their change won’t be set back the way I want.)

If you open the settings doc into the Notes client and resave it (as opposed to editing it via an agent), the $PolMdTm field will set itself, and everything should work normally. The point of Jen’s post is

a) The $PolMdTM field is what the Notes client looks at to determine the last modified time of the doc instead of the doc’s actual LastModified property. (For performance reasons, this field is retrieved out of the ($Policies) view to avoid accessing the doc off disk.)

b) Any agent that only resaves the settings doc or even changes or resets one of the data fields (like, to use my example setting above, the SaveMail field) before resaving it will fail to reset the $PolMdTm field, since the agent modifies the doc on disk, and the $PolMdTm field’s Computed Value formula won’t be calculated since it’s defined in the form, and agents don’t use forms when editing docs.

c) Therefore, to make a settings doc look recently modified to a Notes client via an agent, you MUST explicitly set the $PolMdTm field to the current date/time.

Again, this is ONLY true if you’re resaving the settings doc via an agent, and is unnecessary if editing the doc manually via the client.


Now, it should also be said that the Notes client is still a little squirrelly when it comes to how reliably it will apply policies (and profiles) to itself, but in my experience, it always seems to eventually see the changes; it just may take a couple reboots.


I should also say that if Jen is reading this posting that I’m sorry I haven’t emailled you back since your last post to me. It’s not that I’m being a jerk; I keep meaning to get around to it when I think that I have something interesting to say, and that hasn’t happened yet. (But yes, I am eating some excellent Belgian chocolate as I write this.)