rosuav at gmail.com
Wed Jul 23 17:38:26 CEST 2014
On Thu, Jul 24, 2014 at 12:14 AM, memilanuk <memilanuk at 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
More information about the Python-list