Table of Contents
1. Task of the function
With "Deploy ACL," the directory structure is written under the "target path and the list and authorization groups". Sub-directories without explicit authorizations are not created.
You need write rights to the deploy directory, for example as administrator.
Here three paths are displayed:
The authorization structure is read on the source path. This path is available only in the case of the "Migration per Scan".
You have the name while starting the project.
This is the name, which should be our share.
This name can correspond to the source path - this is the most common instance. It can also get another name, if the final share does not correspond with the source path.
Why is this name important?
- In the names of the authorization groups, the directory name, that is the release name is entered, if you selected it in the group configuration. In this way you can easily identify the domains of the authorization group. For this the "defined target" is needed.
- 8MAN works with the group-description field. In the description field for each authorization group, the complete path is available with server, release and directories. In case of adapted configuration, migRaven creates 8MAN-compatible groups. Therefore indispensable.
So you have already given this name while starting the project.
Deploy path (Target location, Green Meadow)
In this path, the new authorization structure is now written. This deploy path is first offered with the value of the "target path". You can change the provided value. Which name should you specify is indifferent; it must only be deviate from the source path.
[Warning] If there is a problem with the source path in case of migration, then you should implicitly rename it. Otherwise write the migration in the source directory. [/ Warning]
[Important] You must create this path, set the release and give yourself the required rights before the Deploy ACL, in order to be able to write the authorization structure. [/ Important]
3. Possible variants
- "Source path" and "Target path" are same
migRaven enters the content of the "target path" in the case of the "deploy path". Thus you would migrate directly into the source path without detour! This is possible but not sensitive. The new structures are written, the old structures remain. So the old inheritance-interruptions are preserved. Rework is needed but inadvisable.
[Warning]! In this case, it is important to specify a path to deviating from the source path.! [/ Warning]
- "Source path" and "Target path" are same, "Deploy path" which changed (for example in "Green Meadow")
It is migrated into an alternate directory (deploy path). At the end, you must rename the source- and deploy-share in a way that the deploy path receives the share name of the source directory.
This is the recommended and distributed procedure.
- While starting the project, various shares were specified in the case of "Source path" and "Target path"
migRaven enters the "target path" in case of the "deploy path". It is migrated into the deploy path.
The share name is changed in this way.
4. Following is generated
Here are statistical data on directories and authorization are generated.
Deploy is started with a checkmark in case of "I confirm this action" and by pressing the button "Start action".
Displays the current work step during deployment, up to the final message: "The folders of your project and the authorizations assigned to it were written in the file system."
If this job is successful then the 3 project gets the status