ukho / adm-psmodule Goto Github PK

This idea no longer needed, it shouldn't be ADMs need to work that out.

The colour for each action (add, remove, modify etc.) aren't defined globally anywhere. It would make sense to have the colour defined once in a variable and then use that variable everywhere else.

the licenseUrl provided is https://raw.githubusercontent.com/UKHO/ADM-PSmodule/master/LICENSE.md

this returns a 404, as the page is rendered as: https://raw.githubusercontent.com/UKHO/ADM-PSmodule/master/LICENSE

There are places using the array ability and others where each line is defined to use write-color.

Needs to be done one way or the other

Currently when three users are added to the same group, you get three logs of a group modification.

I should be possible to hold some information about the group last mentioned and visually link a record as if it were done in the same time

Write-color has a parameter of StartTab

Use it

If the item/ou is not defined on the structure, it should be deleted (ignoring provided external groups).

Thinking a flag on the call or in the configData

At the moment only users can be defined within groups within the configuration, this can lead to duplication. For example, within TFS there is often a "developer" group, a group of all developers for that project. This group is then used within multiple TFS group saving the user time when adding and removing users. This module currently doesn't do this and it might make administration a pain. Possible fix might look like:

$configData.Groups = @{
    OpsDevs = @{
        Users = (
           $config.Users.OpsDev1
           $config.Users.OpsDev2
       )
    }
}
$configData.OUStructure = @(@{
Name   = "Access Groups"
RootOU = "OU=Services"
    SubOUs = @(
        @{                           
          Name = "Ops"
          Groups = @(
              @{
                Name = "Build Admins"
                Users = @()
                Groups = @($configData.Groups.OpsDevs)
               } 
              @{
                Name = "Contributors
                Users = @($configData.Users.ProductOwner)
                Groups = @($configData.Groups.OpsDevs )
               }
           )
        }
    )
})

The group would be created at the rootOU level. There might be some fun and games around creating doing this across domains

I would like the ability to disabled the test run as part of the -ApplyChange maybe as a bitwize operator or a separate parameter, happy either way.

due to things like Sam names being limited it a number of characters, is likely that all of the circumstance of having AG_SYS_PRD_GROUP_ROLE-GG is making the whole thing too long to be unique.

I am thinking that during the test run the Create-Group would have some santisation to catch any expected behaviours.

For example but not exclusively to:

1. CN conversion to samname creates duplication

this doesnt cause the system to error, but it does cause the function call not to work.

when I was setting up the clone on my local pc it was erroring on a few things around dependencies including the RSAT tools which isnt mentioned ion the read me

For a build to be successful, it should be a version greater than the last full release.

builds from a branch other than master will happily create pre-release versions of the package that is effectively already released.

I am thinking some sort of check against the gallery and checking the module release version vs the version in the branch.

Visually the logs are really hard to read, I have see some recent work on the terraform project and the mix of clear separation of areas and nomenclature makes it easy to read.

suggestions I have are:
+ for add
- for remove
~ for changed

with some tab indenting and horizontal spacing, things might become easier to read.

probably something that only comes from testing in production :)

on line 37 of Update-AD it calls write-color this is asking for the parameter of -Line which is incorrect, this should be LineBefore or LineAfter

on the list of what has changed, there isnt a count for errors.

 Change Summary:
    Created OU: 0
    Created Groups: 0
    Added Groups: 0
    Removed Groups: 0
    Removed Users: 1
    Added Users: 42

what I propose is adding an error count, ideally at each level, so error on OU, error on group, error on User

 Change Summary:
    Created OU: 0
    Errored OU: 0
    Created Groups: 0
    Added Groups: 0
    Removed Groups: 0
    Errored Groups: 0
    Removed Users: 1
    Added Users: 42
    Errored Users: 1

The build is triggered even when only the README.md is updated. This scenario causes the build to fail as the version number has not been updated.