Inbox rule support

[elijahgagne]

I am interested in working on adding functions to create/read/update/delete inbox rules. I'll plan to work on that soon.

[gscales]

As far a i know at the moment the REST API doesn't support Inbox rules so you might have to leave this one open until the underlying API supports it.

[elijahgagne]

That's a bummer. It doesn't look like it's even available in the beta api yet.

[elijahgagne]

I opened a request with MS. https://officespdev.uservoice.com/forums/224641-feature-requests-and-feedback/suggestions/19823005-add-inbox-rule-management-to-outlook-rest-api

[gscales]

Well I voted for it :)

[gscales]

Looks like they have added Inbox Rule support now to Beta Endpoint (well at least I can see the entities in the Metadata)

[elijahgagne]

Awesome, I'll check this out soon.

[elijahgagne]

Unless I'm doing something wrong, it seems that Inbox Rules or "MessageRules" (which admittedly is a better name) are not yet available. My test is:

$MailboxName = "name@company.com"
$Url = "https://outlook.office.com/api/beta/users/$MailboxName/MessageRules"
$Headers = @{
  "Authorization"   = "Bearer $(Get-TokenFromSecureString -SecureToken $Token.access_token)"
  "X-AnchorMailbox" = $MailboxName
  "Prefer"          = 'outlook.timezone="Eastern Standard Time"'
  "Content-type"    = "application/json"
}


try{
    iwr -Method GET -Uri $Url -Headers $Headers
} catch {
    $resp = $_.Exception.Response
    $r = $resp.GetResponseStream()
    $sr = new-object System.IO.StreamReader $r
    $body = $sr.ReadToEnd()
    
    write-host("Status code: $($resp.StatusDescription)")
    write-host("Body: $($body | ConvertFrom-JSON | ConvertTo-JSON)")
}

Which gives me the following output:

Status code: Bad Request
Body: {
    "error":  {
                  "code":  "RequestBroker-ParseUri",
                  "message":  "Resource not found for the segment \u0027MessageRules\u0027."
              }
}

I figure I'll keep waiting until that works. But do please let me know if you see an error in my test.

[gscales]

MessageRules are a NavigationProperty on a Folder in this case the Inbox folder so you need to make a request like

https://outlook.office.com/api/beta/users('gscales@datarumble.com')/MaillFolders/Inbox/MessageRules

Returns the Inbox rules for me

eg a simple mod of (using -beta when generating the token)

    param( 
        [Parameter(Position=0, Mandatory=$true)] [string]$MailboxName,
        [Parameter(Position=1, Mandatory=$false)] [psobject]$AccessToken
    )
    Begin{
        if($AccessToken -eq $null)
        {
              $AccessToken = Get-AccessToken -MailboxName $MailboxName          
        }   
        $HttpClient =  Get-HTTPClient($MailboxName)
        $EndPoint =  Get-EndPoint -AccessToken $AccessToken -Segment "users"
        $RequestURL =   $EndPoint + "('$MailboxName')/MailFolders/Inbox/MessageRules"
        return Invoke-RestGet -RequestURL $RequestURL -HttpClient $HttpClient -AccessToken $AccessToken -MailboxName $MailboxName
    }
}

[elijahgagne]

Thanks very much for pointing me in the right direction. If it's OK, I'd like to work on some InboxRule functions to contribute.

[elijahgagne]

I made a branch in my fork at https://github.com/elijahgagne/Exch-Rest/tree/InboxRules and made an initial commit for a Get-InboxRules function.

I wanted to ask a few questions:

• What do you think of structuring things where each function is in it's own file? The .psm1 file would dot source all of the functions in .ps1 files. You've added a lot of good code and the psm1 file is starting to get big. Breaking things into multiple files will make it easier for multiple people to work on parts of the code. Alternatives could include adding a folder structure to group related function or using multiple files, but putting related functions all in one file.
• What do you think of my use of Update-FormatData. This let's the Get-InboxRule function get all the data, but by default only display the important columns in a table format.

I am very conscious that this is your module and I do not want to make any changes that you're not in favor of.

[gscales]

Sounds good regarding the structure issue the size is starting to get an issue and I was considering that as a solution. I don't think I'll pull all the existing code into new files because of the time it will take but its easy to fix bit by bit as new functions are added.

the Update-FormatData looks good anything that makes the data easy to use is worthwhile as long as it not too time consuming to construct or breaks easy but it all looks good

Thanks
Glen

[elijahgagne]

I think I have something that might be worth merging, but wanted to get your feedback before submitted a pull request. Here is a gist that might be useful in seeing how to test what I've added: https://gist.github.com/elijahgagne/1a9debe0f7a98b4c6c336018228f9490.

A few notes on things that might be questionable:

• I created advanced functions with CmdletBinding support. This let me add help info and parameter sets.
• I choose function names using verbs of get/set/new/remove

Please let me know what you think and if you'd like any changes before I submit a PR. Thanks.

[gscales]

It looks okay the only comment i would have is about making people pass in the JSON, not too many people would be comfortable with that so its better to build a helper function to build the JSON and just allow people to use parameters for the input. But you can publish what you have now and just add that as a future improvement. One other thing from experience is that the RuleId's will change when anybody modifies any rule , there is nothing you can do about that it just one of the pains of working with rules.