new client id/template mgmt system design - feedback?

[Nick]

dSupportSuite currently has limited mgmt capabilities, and due to its initial design any real improvements would be a difficult implementation at best. This hinders the potential it has to do much more than it is currently capable of. I want to improve the situation, and I would appreciate your input, because only you know what you need.

I wanted to share my notes with you on how I would like to see things look and operate in the next release. If you are interested look them over and let me know what you think. Please look carefully as I haven't expressed the larger picture in absolutely every section/idea, though it is likely there if you examine all of the content in every section. Also obviously I left out a LOT of content in the XML especially but also in other areas that wasn't necessary to illustrate the system (e.g. different config types.) Some concepts or usage ideas may only be implied, some are entirely expressed in XML, but most should be fairly obvious. Remember when browsing that I have looked at many of the issues and requests mentioned on the forums, and while much of the designs/concepts you will see will directly improve some situations, it won't happen across the board; but maybe at least pave the way for future improvements by providing a better foundation to build new features upon.

http://1drv.ms/1GP1lyr

this is my "real-time" onenote on the project so content may change at any time, check back frequently when following up on a topic/design idea

also keep in mind that currently I'm not focusing on any topic related to the dSS client software or related configuration of any type, so please hold off on discussion not related to mgmt capabilities or operation of "the system" -- once we get mgmt worked out we can think about the rest.

Thanks!

[csc]

Hey Nick,

I read through most of your notes, and I think I have a perspective that might be missing. Imagine you're licensing your software to a scalable organization. That organization will have a head office which issues the templates to a server in every district (for updates) which would then be applied at every location at the discretion of the location. The server at every location would handle the clients for that location and may have something customized for a few of their clients. That's what keeps the personalization or customization of templates done with the technician who performs the service for that location.

If interested I would be willing to share my Google Macro with you which is essentially one big search filter for the automated emails which are sent. It will put the data collected (like last maintenance date) into a google spreadsheet which can then be referenced or manipulated however you want (I have it generating PDF reports on demand for my clients with logo and contact information. This is sent automatically on a scheduled basis).

I would recommend separating the authentication of the head office from the store locations. A store should be able to update their modified template back to the district server (backup, ect) and have read only access to the templates hosted on the district server (these are updated by head office). At no time should the technician be able to upload templates to head office or should head office be able to change something behind the technicians back.

I'll keep reviewing your notes, sorry if you feel as if I jumped the gun in my response.

Thanks,
Ray

[laplandz]

Some thoughts...

Are you considering or have considered making this fully web-based using php or similar to interact with the xml data? The console being the way we interact/update/cache/backup the data.

Would a single RootNode with a minimum of 1 SubNodes attached be wiser for navigation or logistical purposes, No reason why a SubNode can't be a few levels deep.
With regard to permissions, can xml be used like a database to create an Allow/Deny type configuration? or could the console manage permissions to allow this? These may be the same thing and am asking if a multi-user environment could be possible, with the below as an example, Town shop 1 & 2 could have different logins meaning they could both be "logged" in to their respected SubNode at the same time.

RootNode
Town A (SubNode1)
--- Shop 1 (SubNode1a)
------ Shops internal comps (SubNode1a-a)
------ Residential Customers (SubNode1a-b)
------ Supported Businesses (SubNode1a-c)
--- Shop 2 (SubNode1b)
------- Shops internal comps (SubNode1b-a)
------- Business Customers (SubNode1b-b)
Town B (SubNode2)

If a permission based scenario is possible and i'm not sure how to explain it, but, would giving some restrictions to Root be feasible?
these Global restrictions could be things like - Only Root can create a first-level-SubNode and first-level-template such as Town A & Town B.
What i'm trying to get at is Root should only be able to create a SubNode, back it up, Move them to other SubNodes or to another ftp location, etc. It shouldn't be able to make direct changes to Subs after a template has been set to it, except to perhaps delete it or even better move it to an Archive/Trash_SubNode.

Might be well off base here and i'll stop there as i'm not really sure what sort of feedback you would like and after i've read what i alone have written, i'm starting to wonder if i'm over complicating it all.

[csc]

Hey Nick,

How about setting up dSupportSuite to be customized with a web-gui frontend and the technicians just register for an account on your website? Have you heard of Agomo? Something similar to that. The technician could program the commands within the web interface and the application could just execute the profile of that customer from server. Here's a link to a $300 2-month free trial for the Google Cloud Platform. Not sure if this will interest you or not.

https://console.developers.google.com/freetrial

Thanks,
Ray