• State Not Answered
  • Replies 6 replies
  • Subscribers 61 subscribers
  • Views 2549 views
  • Users 0 members are here
Options
Related

Mimicing the Web form entry associated with proxyAddresses

Shawn.Ferrier
over 4 years ago

Hello!

The Active Roles web interface provides special, custom entries for managing certain attributes that are impossible to create on your own (or at least there is no documentation on how to do so), which includes the special behaviour associated with editing proxyAddresses, per this screenshot:

You have the ability to use this "Set as Reply" button, for example. This special form only appears when and if you add proxyAddresses to your form. My question, as the subject implies: is there a way to "steal" that behaviour for another attribute? I'm working on a project where e-mail addresses are stored in a custom extended schema attribute instead of proxyAddresses, and I would love to be able to leverage this built-in capability.

Thanks!

  • 0 over 4 years ago

    Just a note, I would NOT recommend to use DC/ldap/adsi calls to manage proxyAddresses. You read email from customAttribute and use custom script Exchange Cmdlets to set it in.

  • 0 over 4 years ago

    Hi Shawn

    I don't think it's possible to re-use the custom form used for proxy addresses, but you might be able to create something yourself to mimic it.

    Have a look at "Create a Custom Entry" in the MMC, this should give you guidance of how to change your entries "Entry Type" from "Auto" to "Custom", the how to define the script which is fired to Get or Set the value (where the code for this would need to be written by you, and stored on each web server within "CustomCode\Entries.vbs"

    However, if your customers CustomProxyAddress should have the same values (or a sub-set of the values) as those in proxyAddresses, you could always get them to modify via ProxyAddresses, then have a workflow or admin policy which runs a script (onPre) to update their CustomProxyAddress field... TBH the latter would be my choice if the requirements fit.

    Hope this helps.

    Stu

  • 0 over 4 years ago in reply to Stu.Pollock

    Thanks, Stu.

    Looks like you're right: there's no easy way to "steal" the proxyAddresses behaviour. I discovered the file "D:\Program Files\One Identity\Active Roles\7.4\Web\Public\lib\Entries\e_ProxyAddresses.asp", which is a whole bunch of code that specifically deals with managing that attribute.

    Will have to look at the other alternatives as you pointed out.

    Thanks!
    Shawn.

  • 0 over 4 years ago in reply to Shawn.Ferrier

    Good spot, thats probably the code you want :)

  • 0 over 4 years ago in reply to Shawn.Ferrier

    Shawn,

    Did you manage to take the code from e_ProxyAddresses.asp and put it into use within Entries.vbs

  • 0 over 4 years ago in reply to Stu.Pollock

    No. I did try a very basic search/replace with the proxyAddresses attribute name with my own, but that didn't work. Quite frankly, the proposal of having to figure out all of that code, which would also demand intense familiarity with the code structure of the site along with updating the Javascript was simply too intimidating and time consuming (at least for me, without any Web development background). I ended up cheating. I put the proxyAddresses attribute on my form, but then wrote onPostGet code to substitute the content with my own attribute.