On 07/21/2014 11:26 AM, Chris Angelico wrote:
On Tue, Jul 22, 2014 at 4:16 AM, Monte Milanuk <memila...@invalid.com> wrote:
On 2014-07-21, Chris Angelico <ros...@gmail.com> wrote:
On Tue, Jul 22, 2014 at 2:07 AM, Monte Milanuk <memila...@invalid.com> wrote:
So I guess I'm asking for advice or simplified examples of how to
go about connecting a client desktop app to a parent/master desktop app,
so I can get some idea of how big of a task I'm looking at here, and
whether that would be more or less difficult than trying to do the
equivalent job using a web framework.
Easier way: Don't have a "master desktop app", but instead have a
master database. Since you're posting this to python-list, I'll assume
you currently intend writing this in Python; you can make a really
simple transition from single-user-single-desktop to a networked
system, although of course you'll want to think in terms of multiple
users from the start.
So... if everybody is using the same application to access the same
database, how would you prevent say, a data entry user from accidentally
breaking something above their pay-grade? Set up some sort of
role-based privilege system to limit them to write access for some
portions and read-only for others?
That would be one way, yes. The first question you'd need to ask is:
How do you know who's data-entry and who's admins? As soon as you
solve that (probably with some sort of login), you tie the access
level to that.
Given the small user base and the nature of the events, volunteer staff,
everybody knowing everybody, etc. its pretty much a matter of the match
admin saying "You, you and you - data entry" ;)
If you need absolute security, you would have the user enter a login
and password which would actually be the database credentials. Then
you grant exact rights in the database manager, permitting ONLY what
that user is allowed to do. It's then utterly impossible, even for
someone who knows Python and SQL, to do damage.
Intriguing... and probably the most technically correct way as far as
role-based access. But also very unlikely that most of the end-users
would be able to set up the DB correctly. Just sayin'...
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.
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...
Monte
--
https://mail.python.org/mailman/listinfo/python-list
