disable c1 and c2

Hi Forum,

My client uses MCC and file documents exclusively via folders and so client and matter are always set for them. The client wants to prevent users with full access to the workspace (and they need that too) from being able to change c1 and c2. How can we do this?

These are the options we have come up with

1) just remove the C1 and C2 from the workspace properties dialog. (roles disable create new workspace - so no need to touch new workspace dlg)
2) let users have the ability to change c1 and c2 but store c1 and c2 as a hidden value on the workspace profile so that if they do change (e.g by mistake) we can do a report and fix it programatically.

Ideally IWOV would create an NRS script to allow us to disable the c1 and c2 and show it as read only. But i dont think that exists.

any ideas?

Ben.

Find more posts tagged with

Comments

jny

Would it work to make the client/matter fields read-only through an event wrapper around the default edit workspace command?

For further clarification, see attached VB sample ICommand Event Wrapper code along with the associated registry key below:

FileSite 8

[HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\WorkSite\8.0\MailSite\Commands\Workspace]

"Commands" = "IManExt2.AddShortcutsCmd,ImportCmd,IManExt.SearchCmd,iManExt.SendFolderURLLinkCmd,-,IManExt.ShowWebViewCmd,@4003@Show/Hide Hidden Tabs, @33751@Refresh,-,IManExt2.IManRefileCmd,IManExt2.IManMoveFolderCmd,IManExt2.IManCreateShortcutsCmd,-,iManExt.PurgeCmd,@33752@Rename,New,-,IManExt2.AddToSubscriptionFolderCmd,IManExt2.AddToFavoritesCmd,-,ImanEvtTemplate.MyWorkspaceProfCmd"

' Note ImanEvtTemplate.MyWorkspaceProfCmd is the progid to the sample ICommand Event Wrapper which replaces the default IManExt2.IManPropertiesCmd (that is used by default to execute the edit workspace command).

Ben_inform

Hi !!

Thanks so much for that -- I can't find the attachment caxn you re attach or sent to

ben.sunderland@alphawest.com.au

Thanks....
Ben

jny

Here you go...

[newprof.nrs]

Option Explicit

' AttributeID
Const nrAuthor = 5

' Access rights
Const nrRightAll = 3
Const nrRightReadWrite = 2
Const nrRightRead = 1

Sub NewProfileDlg_OnChange(obj, id)
dim secDlg
dim arrUserNames(2) ' Assuming array count is 3
dim arrUserRights(2) ' Assuming array count is 3
dim strOwner, str1, str2
dim lngOwner, lng1, lng2

If id = nrAuthor Then

' Usernames
strOwner = obj.GetAttributeByID(nrAuthor)
If "" = strOwner Then Exit Sub
str1 = "user1"
str2 = "user2"

' User access rights
lngOwner = nrRightAll
lng1 = nrRightReadWrite
lng2 = nrRightRead

' Put ACLs in a safe array
arrUserNames(0) = strOwner
arrUserNames(1) = str1
arrUserNames(2) = str2

arrUserRights(0) = lngOwner
arrUserRights(1) = lng1
arrUserRights(2) = lng2

' Get UsrGrpSecurityDlg object
set secDlg = obj.UsrGrpSecurityDlg

' Put UserACLs
secDlg.UserNameArray = arrUserNames
secDlg.UserAccessRightsArray = arrUserRights
End If

End Sub

Sub NewProfileCmd_PostOnOK(obj)
dim secDlg
dim arrUserNames
dim arrUserRights
dim lngNames, lngRights, i
dim strRet

' Get UsrGrpSecurityDlg object
set secDlg = obj.UsrGrpSecurityDlg

' Get UserACLs
arrUserNames = secDlg.UserNameVariantArray
arrUserRights = secDlg.UserAccessRightsVariantArray

If Not IsEmpty(arrUserNames) Then

' Obtain a count of the usernames and userrights.
lngNames = UBound(arrUserNames) - _
(LBound(arrUserNames) - 1)

' Determine if there are usernames.
If lngNames > 0 Then
for i = 0 to (lngNames-1)
strRet = strRet & arrUserNames(i) & "=" & _
arrUserRights(i) & "," & VBCRLF
next
msgbox strRet
End If
End IF

End Sub

Ben_inform

Hi again,

I think you posted an NRS script by mistake instead of the event wrapper for ......

ImanEvtTemplate.MyWorkspaceProfCmd

3rd time lucky ?

Ben_inform

here is what i have so fare but i get access denied when it goes to this line
mOrigCmd.Execute

see attached code.....

jny

Sorry about that. Let's try again.

Ben_inform

I have tried checking everything and can't get this to work. Have you got it working or is it a "Should work in theory" ?

Didn't you say that IManExt2.IManPropertiesCmd is used to display workspace props instead of IMANEXT2Lib.IManEditWorkspaceCmd ?

Ben_inform

Can You help ????? My client is making me sweat and I am at the mercy of this undocumented thing which is not the best.

malan

Hello - jny is on vacation, but perhaps I can help.

I can actually get this working. Here's what I did.

1. Compile ImanEvtTemplate.vbp.
2. Change the commands registry key as above.
3. Right-click on a workspace.
4. Click "Properties" which will call your ImanEvtTemplate.MyWorkspaceProfCmd instead of IManExt2.IManPropertiesCmd since you made the substitution in the registry key. The profile will pop up and client will be disabled.

In the reigstry entry above you should be substituting ImanEvtTemplate.MyWorkspaceProfCmd for IManExt2.IManPropertiesCmd.

When you say it is not working, what is happening instead?

Also, to answer your question, IManPropertiesCmd calls IManEditWorkspaceCmd to allow you to edit the profile of the workspace.

Ben_inform

Hi,

Yes I can now get it half working in MailSite as you have said . I was trying with DeskSite with this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\WorkSite\8.0\DeskSite\Commands\Popup Menus\WorkSpace
But it does not work in the sense the "Properties" menu item is greyed out. Even though the same DLL and cmd in MailSite works - well kinda.
In MailSite it works as far as the client is diabled but the matter edit box is still writeable (even though the button is greyed).
Is this the same issue with disabling the matter as in this posting Search for : "Disable Matter Field".??

So I am stuck coz Mailsite half works and DeskSite doesn't work at all.

Ben_inform

And the other problem that i have is that if you do call setattribute to disable the fields, the workspace is effectively changed and on OK it will ask you to reprofile......

malan

I have a possible workaround to the problem with the discrepancy between MailSite and DeskSite disabling your command. In your wrapper, you are using the update method of the workspace edit command, not the properties command you are replacing. If you were to instantiate the properties command just for the purpose of calling it's update method inside your update method, so that you could read it's status and return it when asked for status, that might be one way to keep it acting like the properties command you are replacing. The IManEditWorkspace command seems to be unnecessarily strict in it's Update method.

The problem with the writable matter field is a known bug as you point out.

The re-profiling might be the biggest problem, though. The dialog should be smart enough to know you haven't changed the value, but this might have to be fixed in the software. Could you report the bug to development support?

Ben_inform

I have no idea how to do that.
I can have a go but this dev by trial and error is painfully slow and my client (as clients tend to do) want answers NOW.
All I wanna do is disable c1 and c2 - why is this such a hard task?

I will raise my high level objective with IWOV support rather than dwell on this low level SDK detail because I keep hitting flaws and undocumented areas in the SDK. I could end up wasting weeks of my time to find zero solution.

Thanks for your help anyways Smiley Tongue

Ben_inform

Actually i just found out that the disabling C2 via setattributebyID has been Fixed in HF1 for which i have a pre -release to test.

Assuming that thta now works all i have to do is make the DeskSite one work the way you said and then escalate the issue with the refile.

My question is how do I instansiate the IMan.EditPropertiesCmd just for the purpose of the update status method ??

can you give me a hand please ?

malan

You would like your command to be enabled whenever the EditPropertiesCmd is enabled, and disabled whenever the EditPropertiesCmd is disabled.

The best way to find out when the EditPropertiesCmd is enabled or disabled is to actually create an instance of it, give it the same context items that were given to your wrapper command, call .Update, and get it's status. Then you'll know if it is enabled or disabled. You can pass that information along in the .Status property of your command.

Ben_inform

Thanks. I tried to do as you said but am not sure if what I have done is write.
Now when i run it the properties menu item is enabled but when clicked I get this error message

iManExt2: The WorkSpace for BSUNDERL Personal.CSF_Sydney_C8 cannot be modified!.

Access is denied.

Please see attached to check how i have instantiated IManPropertiesCmd and used its update method to set status of ICommand_Status.

Bowman

Hello, i have been looking at this thread and have ran the code supplied in it and have the same problem. The new Properties menu command works great if the user looks at the properties on the workspace under Worksite Explorer, but if the user looks at the properties of a workspace shortcut i get an error saying the object is invalid.

Is there any way of getting this command to work for both the workspace and workspace shortcuts? For a workspace shortcut i would expect to see the shortcut properties screen first and then if the user clicks on the workspace properties screen it would show the workspace properties with the custom fields disabled.

Also, i noticed you can get the the workspace properties from a number of locations including some of the integration dialogs. Is it possible to disabled c1 and c2 from these screens also?

Thanks.