Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #75090
| 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 | 2014-07-24 01:38 +1000 |
| Subject | Re: Network/multi-user program |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.12243.1406130377.18130.python-list@python.org> (permalink) |
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
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Network/multi-user program Chris Angelico <rosuav@gmail.com> - 2014-07-24 01:38 +1000
csiph-web