Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <lqofvr$5od$1@ger.gmane.org>
References: <slrnlsqelq.evp.memilanuk@machin-shin.milanuk.lan> <CAPTjJmqmGEVr8-DApUf5zUt3QpL+9=rOiweyzc0Z9thtBEpO=w@mail.gmail.com> <slrnlsqm8h.evp.memilanuk@machin-shin.milanuk.lan> <CAPTjJmrnXKpXraRbBwY=HjU08V1OQJvEBObToJaPbOpyogid5A@mail.gmail.com> <lqofvr$5od$1@ger.gmane.org>
Date: Thu, 24 Jul 2014 01:38:26 +1000
Subject: Re: Network/multi-user program
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.12243.1406130377.18130.python-list@python.org>
Lines: 48
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:75090

On Thu, Jul 24, 2014 at 12:14 AM, memilanuk <memilanuk@gmail.com> wrote:
>> But more likely, what
>> you really want is a cut-down UI that simplifies things: if the user
>> is data-entry level, you take away all the admin-type options. It
>> might be possible to fiddle around in internals and gain elevated
>> access, but that's not an issue in many environments.
>
> That sounds very much like what I'm thinking of... maybe a token nod @
> security with a passwd for 'admin' and 'data-entry' roles to keep idle
> passers-by from snooping or diddling with things they shouldn't.  Even if it
> just greyed-out / disabled buttons, tabs, etc. based on role that would
> probably meet needs.

Yep, for most purposes that would be fine. In fact, you could cut it
down further, if the data-entry mode is pretty safe: have the program
start up in data-entry mode, and it has one menu item "Switch to admin
mode", which prompts for a password.

>> In any case, these are issues you'd need to figure out regardless of
>> the development model. Ultimately, you could treat the entire
>> computer, network, database, etc as a black box, and just look at two
>> entities: the human, and the UI s/he is using. All permissions issues
>> can be explained at that level.
>
>
> Not really clear on what you're talking about on this part...

If you were to create a web application, you'd have to worry about the
same question of "is this person an admin or just data-entry". If you
were to do this as a single program that other programs script, you'd
have to worry about the same question. It's not complexity inherent in
the model of "database is king, and there are several applications";
it's complexity inherent in the original problem "we will have
separate admins and data-entry people".

Incidentally, there is another way you could lay it out: have two
separate programs, one of which is the d-e and the other is admins.
That could work out very nicely, if you have a specially cut-down and
simplified UI for d-e. It'd be like how some accounting packages have
a special Point-Of-Sale mode, which doesn't have permission to process
anything other than straight-forward sales, and which will use the
entire screen just for that. It's a useful feature even when you
completely trust the people involved; the simpler UI can allow
increased throughput. There's a lot of flexibility here, and
ultimately, you get exactly as much complexity as you write into your
system :)

ChrisA