Updated 23-09-2011: I moderated my comment about superoffice. That was childish of me
Updated 24-09-2011: New version updated with a ton of bug fixes .. read more here
My original approach to handling users in superoffice didn't work as expected. I don’t know why I didn’t catch this while testing ( I apparently don’t test well enough )
The whole point of this powershell add on was to make a simple way of managing users in multiple SuperOffice databases. Turns out the SuperOffice NetServer API is hardcoded to declare everything as internal static’s ( that’s private shared for us VB nuts ). They don’t expose a function to clear them, and pretty much everything inside the API is handled though static’s. And they don’t offer you a way to change configuration. Even SuperOffice.Configuration.ConfigFile.SetConfigFile fails. ( they check internal static variable superoffice.socontext._currentPrincipal . That means you can “sign-out” but you’re a “stuck” with the database you connected to the first time. If you change the configuration file (like I did in my old code) SuperOffice will now throw
Failed to create Identity from tokens
If you (but you wont, its not nice to spy at others bad coding habit's ) look inside SOCore.dll with reflection you can easily see that, SuperOffice is talking with the database ( so DSN link, database and database username/password is correct ) but the identity token it created with your windows principal or CRM username/password doesn’t match anything in database. Since its still looking in the old database
I tried messing a bit around with reflection and overwrite the variables. But didn’t really get me anyway (but I learned a lot of new trick while trying ) so I decided to go down the path I read about on devnet.superoffice.com .
AppDomain … Now there is something I don’t know anything about. I know what it is, but I have never, ever tried coding with/against it.I created a ton of small test applications going down different paths, but nothing really seemed to work. *IF* I managed to get different things loaded, superoffice would go nuts and not work. Then after several hours of getting more and more desperate i found a very simple example (sorry lost the link) and that got me kicked in to gear.
So here is the updated version of my powershell add-on to manage users in SuperOffice. Its pretty much the same but
- I renamed all functions to start with so7.
- I’ve added a Type Formatting file ( .ps1xml ) so output looks better.
- I fixed a small bug in the configuration files. SuperOffice client goes nuts when it see <security> tag, so removed that unless you specifically set the Symmetric keys.
- And best of all. Now it works against multiple SuperOffice instances.