Dashboard > OSL Monitor > ... > Requirements and needs > Application features and architecture
OSL Monitor Log In   View a printable version of the current page.
Application features and architecture
Added by SebastianWagner, last edited by SebastianWagner on May 29, 2006  (view change)
Labels: 
(None)

First of all we have to devide everything into two things:

  1.  The public area
  2.  The admin/restricted area

In the Public area users can see some News from rss-Feeds/charts/pictures/information from various input/information from nagios,Cacti,[OpenNMS]. User can browse to the URL and interact with it (see some details et cetera) or everything will be updated automatically so that you can have screen in your office where you can have quick overview.

In the Admin-Area Administrator can configure the system, that means he can install the application. As we will have to store the data of the application (for example number of rss-feeds, update time and all the data of the other moduls) somewhere the administrator will have to configure database connection to load an empty "skeleton" into a database. I think this can be done all interactive with a wizard. I ll store an sql-text-file somewhere which creates all basic tables and operator just configures "kind of database" (mysql/postgres) "auth-stuff" (user,pass.host,port).
After that he should be able to grand access to other users/create users and login in database, store some configuration, import new plugins update stuff et cetera.

The very basic features and components i'll create:

  • RSS-FEED Component
  • Slide show Component
  • Small preconfigured Modules for Nagios,Cacti,[OpenNMS]
  • some list-data
  • charts of various data input

i have attached a screen of a example (this is not a screen for the Layout, its just to get a *impression*)

[http://www.webbase-design.de/laszloinfra/screen_public.png]

I love the conceptual example.. Especially the idea of seeing the "rotation" of blocks. That could be really awesome!!

As for the public/admin areas.. I'm going to recommend one more level here: public/privileged/admin. When you mentioned public access it had not occurred to me that we might publicize a URL for the general public and users to refer to. So, what I am thinking is that there may be some data that we would show in the office (say, on the bigscreen display) that we would not want the general public to see. So, in the admin section, as the admin is selecting the "modules" to display, maybe have a "public or privileged?" option?

Then make the display itself flexible enough so that if someone is not logged in (public), the display loads and shows the modules, skipping the modules marked privileged. If the user is logged in and privileged, it shows the extra modules. This status would not necessarily have to be by a logged in user, it could also be by IP or network block.. However you want to handle it.

Would this work?

Maybe the administrative side should be seperate altogether? Maybe not.. just throwing that out as a possibility.

Posted by Corey Shields at May 29, 2006 21:56 | Permalink

bound to an IP is a good idea for the access level privileged. But it should be clear that "out of the box" there is only admin/anonymious... and if a modul is public or bound to an IP does not really have something to do with userrights

if you want to create some users et cetera you have to install the "sql-skeleton" somewhere
users can have various privileges (each modul should be marked with some privileges)

Thats what a meant:

Users download the "binary-compiled-package" (packaged as zip and tar.gz) upload and unzipp it on their webspace. Then they can configure the "super-admin" (or they will get some warnings if they don't alter default password/user )
AND alter a directory with the name "config" to be writeable (chmod 777 or at least writeable for the PHP-USER). After that they can push the "sql-dump/skeleton" in the DB-server and it automatically creates a "config-file" in the "config" folder. The name of the config file(s) will be seen on startup ... i already thought about that in my demo http://www.webbase-design.de/laszlo/laszloAdmin/v1/laszloDBAdmin/client.lzx.swf
the value for "Domain" would be System/YOUR_CONFIG_FILE1/YOUR_CONFIG_FILE2 et cetera

After logging in you will be able to create user ... each user can be marked with different privileges ... if he is able to:

  1. Super admin: - all rights inclusive user-create/grand rights to others/system upgrade
  2. User: Access/enable a modul (also means that you can make things public viewable/bound to an IP or general)
  3. no rights
Posted by SebastianWagner at May 30, 2006 08:04 | Permalink
Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.7 Build:#524 Jul 28, 2006) - Bug/feature request - Contact Administrators