Localization Support for Create-/Update Resource Activity about mimwal HOT 7 CLOSED

Typically, you'll submit a manual request and look at the Request Details in the Request History to check what and how attributes need to be populated. @EugeneSergeev, what needs to be done here?

from mimwal.

1. it will be a very rare case to create search scopes or nav bar elements with MIMWAL. I would rather go with FIMpx or any other powershell module for FIM
2. AFAIR, even import-fimconfig does not obey localizations. if you will try to do config migration with localized values in the .xml file - they will not be imported.

so, yes, I do understand what you want, but I do not believe that it's really needed. just my 2 cents.

from mimwal.

Yeah, I don't really see that MIMWAL needs to be able to do this. This is very easy to do with New-FimImportObject:

New-FimImportObject -ObjectType NavigationBarConfiguration -State Put -ApplyNow -AnchorPairs @{ObjectID = $ObjectID} -Changes @(
    New-FimImportChange -AttributeName DisplayName -AttributeValue "Visningsnavn" -Operation Replace -Locale "nb-NO"
)

from mimwal.

Thanks a lot for the actual discussion.
I like to describe the current Use Case.
In a Service Provider landscape or a complex company Environment with many companies and organizationalUnits it is often a requirement to present different MIM Portals for different Enduser Groups (Enduser Group is from a concept perspectiv and not from a technical view like AD-Group or Set).
Based on that we see often the requirment that some Enduser Groups can only show your object or the objects for your organizationalUnit and so on.

This szenario can be build in to different ways:

1. Populate a owner Attribut on all objects and update this based on the modification of a Enduser Group. Based on that build static Sets, MPR's, SearchScopes and NavBars.
   If you have many "own" Objects, it should be not the best solution, because on a modification of the Enduser Group it will be trigger many 100 or 1000 Requests at once.
2. Build Workflows how can dynamically Build Set, Grant Rights MPR's and propably SearchScopes and NavBars.
   This will be triggered based on the creation of a new company, customer, organizationalUnit or anything else.
   With this you not must be able to fill up a Owner attribut and you doesn't have the Request problems.

On our perspectiv in complex, big and highly automated MIM infrastructures, with many custom Objecttypes, we have this really often. But i understand all the discussions.
The requested feature is only needed if you deploy MIM in different languages.
And of course it can be build up external with Powershell. That isn't a problem.

@NileshGhodekar
LocalizedSettings are not normal attributes and couldn't be set on this way.
But of course i could explain you how we can set this attributes. But i think for that, we must do this external over e-mail. It will be to big here.

@EugeneSergeev
Point 2. Try the undocumented Parameter -allLocales in the Export-Config and Import-Config and you see that you have also the localized Settings exported.

from mimwal.

So it seems one of the options you currently have is once you create a custom resource, you could use a small script with RunPowerShellScript activity to add localization. Does that not work?

from mimwal.

Of Course the solutions you describe are working. In special with the functionallity of Ryan Newington LithnetRMA (https://github.com/lithnet/resourcemanagement-powershell). The RMA supporst since 23. July 2016 a nice integration to manage localizations over powershell.
For a simpler understanding of our Workflows and there activities (some Workflows have more than 30 activities) the requested feature would be very nice. We just wanted to discuss this topic with the community to address some actual gaps we have in our solutions.

from mimwal.

If some one want to contribute code for this, they are welcome. I'm closing this for now as it seems RMA can be integrated quickly in the RunPowerShell Activity to have this capability.

from mimwal.