PR on it's way

I'm thinking we should probably start tagging releases. Thoughts?

At the moment, under the message body when peeking, you can click a button to requeue the message with whatever changes are in that textarea. This needs to be extended to take into account changes to message properties. It also makes sense to not do it 'inline', as it could get confusing with the little 'breakout dialogues'.

I envisage that this feature would instead be called 'Modify and Requeue' which would popup or navigate to a screen with all the properties editable, and the ability to add and remove custom properties. It's worth thinking also about letting the user change which messaging entity it sends to (change queue/topic). With a this new screen, we could also re-purpose it to allow the user to send a totally new adhoc message.

Currently if you have some scheduled messages you can only peek them when there are active messages (and they show up in the same list). They probably need to be pulled out into their own peek list.

For GlobalX staff to provision/setup.

Could be a timing issue. Use case (doesn't happen all the time, but is quite regular):

1. peek multiple messages.
2. choose one
3. edit and requeue (should happen with a plain requeue)
4. choose another message
5. sometimes at step 4, it reloads the model again

https://github.com/khellang/Nancy.Swagger
https://github.com/wordnik/swagger-spec/wiki

Is this even possible or desired?

toggle-button or the like on the bottom toolbar.

also, a way to denote disabled topics (strikethrough?) when listing them, and on the topic screen itself

We need to warn before they do something destructive like delete messages/entities. At the moment, some of these have window.confirm, which is a bit lame.

Also, doing any operation on a large queue/subscription can be really bad - it has to iterate all messages to do what it needs to do.

I basically put a wildcard include on the bin/Release dir so the package has everything required to run, but there is some extra junk in there that's not required, and it's not really in a shape that could, say, be referenced from a project file (not that I'm sure you'd want to, just sayin')

Probably needs a bit of a cleanup...

We should list on the readme the exact list of browsers we support.

Ability to select from multiple ServiceBus connection strings (dropdown?) to support multiple configs via the one interface.

Will require a change to the configuration to support this. json array? or something.

This is helpful under certain situations to stop processing of an active handler, but keep the messages for replay later

The majority of the API calls return { success: true } no matter if the result is successful or not.

They look the same.. maybe just the glyph in the header will do, but it could also be a colour change

Proof-of-concept some UI tests for review - what style of UI tests? what tech? etc

The angular controllers/directives can be componentised better, with more thought put towards correct scope. It may also be worthwhile breaking out of the single epic directives.js file.

Recent changes have meant the screenshots are out of date.

While trying to peak at the dead letter queue we occassionaly get a 500, I'm assuming because Value is null.

Nancy.RequestExecutionException: Oh noes! ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at GSF.BusManager.Models.ViewModelBuilders.QueueMessagesBuilder.b__1(KeyValuePair`2 kvp) in c:\Builds\5\GlobalX\GSF.BusManager.CI\src\src\GSF.BusManager\Models\ViewModelBuilders\QueueMessagesBuilder.cs:line 61
   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
   at GSF.BusManager.Models.ViewModelBuilders.QueueMessagesBuilder.Build(FindQueuedMessages criteria) in c:\Builds\5\GlobalX\GSF.BusManager.CI\src\src\GSF.BusManager\Models\ViewModelBuilders\QueueMessagesBuilder.cs:line 61
   at GSF.BusManager.CQRS.ModelBuilders.ModelCreator.Build[TModel,TCriteria](TCriteria criteria) in c:\Builds\5\GlobalX\GSF.BusManager.CI\src\src\GSF.BusManager\CQRS\ModelBuilders\ModelCreator.cs:line 34
   at GSF.BusManager.Modules.V1.BusManagerModule.<.ctor>b__3a(Object _) in c:\Builds\5\GlobalX\GSF.BusManager.CI\src\src\GSF.BusManager\HttpModules\V1\BusManagerModule.cs:line 41
   at CallSite.Target(Closure , CallSite , Func`2 , Object )
   at Nancy.Routing.Route.<>c__DisplayClass4.b__3(Object parameters, CancellationToken context)
   --- End of inner exception stack trace ---
   at Nancy.NancyEngine.InvokeOnErrorHook(NancyContext context, ErrorPipeline pipeline, Exception ex)

I believe it's red because of the assemblyversion

On appveyor, in settings under 'General', scroll down and make it look like this:

Need to create and maintain API keys.

The REST API is shared but the UI, so it will need to support 2 kinds of auth - cookies and keys. Some tools don't support HTTP headers, so there needs to be a way to specify the key as a route param or query string parameter (likely the latter)

I'm pretty sure splitting out the directives from #1 will mean we need to look at reducing our http requests.

A fair bit of UX/Design will go into this. It probably makes sense to open an 'edit screen' (shared with create) rather than edit in-line due to the downtime required to update a messaging entity

Needs to be able to set all messaging entity properties.

A fair bit of UX/Design will go into this. It probably makes sense to open an 'edit screen' (shared with create) rather than edit in-line due to the downtime required to update a messaging entity

Needs to be able to set all messaging entity properties.

BusMonitor should publish changes.

It's probably not intelligent to update view models for things like active/dead letters being peeked (because of the cost of continually checking those messages for changes), but certainly messaging entity properties and message counts should be propagated to connected clients.

A fair bit of UX/Design will go into this. It probably makes sense to open an 'edit screen' (shared with create) rather than edit in-line due to the downtime required to update a messaging entity

Needs to be able to set all messaging entity properties.

Be able to send a new message to a queue or topic. Great for testing or DR

Currently only the "Active Messages" and "Dead Letters" are displayed in the 'Overview'.
It would be a nice feature to also have the "Scheduled Count" displayed, as it is displayed when you drill down on individual queues.

After #6 Live updating of UI with SignalR

There are some things that might be important as a notification/toast message. E.g.

• new deadletters
• exceptions (e.g. bus connection lost)

Not sure yet if there are actually messages in there, or if they're peek-locked for a mega long time, or what have you.

This was observed some time ago, but not for a while, so I'm not sure if it's an issue at all. We've had occasional problems with SBWS falling over, so this might be related to that, and hence not a huge issue (since there's much bigger problems to worry about when that's happening)

Something in the nancy pipeline, I would imagine

SbManager can be run as a console app or windows service thanks to Topshelf. That said, it would be awesome if we could also run it as an Azure Worker Role.

In the RequeueAndRemove::RequeueOne() method, the messages are iterated through to find the one to requeue with a matching messageId. However, it uses the QueueClient::ReceiveBatch() method which may return fewer messages than the number requested, consequently it can happen that the message to requeue is not found in the returned list and so nothing happens.

Support is ending for 4.5.1 so we should move to at least 4.5.2 as our target framework.
https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-ending-for-the-net-framework-4-4-5-and-4-5-1/

We have an integration test suite. This is designed to be run against a running instance of SbManager in a CI scenario (e.g. deployed to a vanilla machine and run, then the integration tests run against it)

It doesn't have to be comprehensive, mostly to make sure it's running properly. However, this might be a good way to run automated UI tests (then again, the CI server can probably run a more fit-for-purpose UI test)

It sits there spinning. We need to show an error message and perhaps a 'retry'

We thought it might be a good idea for SbManager to integrate information about business-related stuff and perhaps auditing.

There would be 2 parts to a plugin - 1) how to make it actually run in the app and be installable/uninstallable etc, and 2) how would it integrate into the UI.

Some thoughts:
MEF?
No server-side components and just use a HTTP widget-style plugin?
Many abstractions (Nimbus, NServiceBus) have the concept of 'audit messages' and it would be useful to show these. This 'plugin' would have first-class auditing knowledge built into SbManager, and the plugins would simply be to collect and transform the audit messages.

We can't unit test a bunch of stuff.

Hide the SB API behind some proxies and unit test the things that can now be tested

toggle-button or the like on the bottom toolbar.

also, a way to denote disabled queues (strikethrough?) when listing them, and on the queue screen itself

A fair bit of UX/Design will go into this. It probably makes sense to open an 'edit screen' (shared with create) rather than edit in-line due to the downtime required to update a messaging entity

Needs to be able to set all messaging entity properties.

AD/OAuth/etc.

What is the best method of handling authentication and authorisation? How should we modularise it and make it configurable?

toggle-button or the like on the bottom toolbar.

also, a way to denote disabled subscriptions (strikethrough?) when listing them, and on the subscription screen itself

when peeking a bunch of messages, have a filter field at the top of the peek table that allows the user to filter the current set of messages to only those that contain that text. Might need a flag as to whether or not to search the body or just the headers, but not sure at this point

Make it work on pressing 'enter'
Validate it's a number