RE: [OPT-general] Permissions Revisited (LOOONG mail)

[David I. <dav...@sy...>]

Hello Bogdan,

I think the reason you did not receive much feedback is because the new
permission scheme looked like it would handle most cases we suggested. My
biggest concern is the ability to have all involved parties in a project
have access to only parts that concern them. i.e. if I am outsourcing part
of a project to a vendor I do not want any interaction between my client and
my vendor but I want the vendor to have some access to update parts of the
project tasks that they are working on etc.

David

--
Systematic Software
dav...@sy...
(513) 241 3331 ext. 9
Fax: (513) 241 0749
http://www.systware.com
http://www.careerservicesonline.com


> -----Original Message-----
> From: out...@li...
> [mailto:out...@li...]On Behalf Of Bogdan
> Stancescu
> Sent: Wednesday, April 24, 2002 11:05 PM
> To: OPT General
> Subject: [OPT-general] Permissions Revisited (LOOONG mail)
>
>
>   Ok, I see I start to get e-mails about permissions from new users -
> here's a repost of an older proposal made of two e-mails I posted on
> this list but I received next to no feedback, therefore dropped the topic.
>
> As always, looking forward to comments.
>
> MESSAGE #1
> [edited as not to conflict with MSG #2 - this was originally slightly
> different]
> Subject: Permissions - 1st talk
> Date: Thu, 28 Feb 2002 03:57:59 +0200
> From: Bogdan Stancescu <mg...@fx...>
> Reply-To: bo...@la...
> To: OPT <out...@li...>, Ni...@ba...
>
>
> Hello everyone!
>
> I've started thinking about the permissions system in 2.0 and would
> *really* like you some input from you on this one.
>
> *DISCLAIMER*
> Don't get your hopes too high - it's not going to happen very soon -
> it's just that I'm working on forums and would like to start
> implementing a proper permissions system for it as long as I'm starting
> from scratch. The rest of the permissions system will follow, but I've
> got quite a number of other things to implement right now.
>
> These are my first thoughts on the issue - please let me know what you
> think:
> - Filesystem-type permissions, but more refined: read/write/delete/edit
> at core level. Why do we need three types of "write" (write, edit and
> delete)? Because you may want to let your secretary browse through your
> assignments in order to print them without changing stuff, and you may
> want to allow fresh employees to edit requests but not delete them, for
> instance.
> - These would be stored per item type, and item types are going to be
> stored hierarchically. For instance, [system] would encompass all item
> types in the system, whereas [projects] would be a level under [system]
> and would only encompass all projects and sub-items. [users] would be
> another sibling of [projects] and would encompass [companies] and
> [people] etc.
> - There are going to be two interface types for setting permissions:
> regular and detailed.
> - The detailed interface will have checkboxes for every possible
> combination of settings.
> - You will be able to save permission schemes as defined in the detailed
> view (and of course the system would come with a few predefined schemes
> - sysadmin, projadmin etc).
> - You will be able to assign permission schemes to individual users from
> the regular interface.
>
> MESSAGE #2
> [After other comments from several users - you can check the archive on
> geocrawler for the actual discussion - click on the link at the very
> bottom of this e-mail, then on the archive link]
> Subject: Revised Permissions (LOOONG mail)
> Date: Thu, 28 Feb 2002 23:28:59 +0200
> From: Bogdan Stancescu <mg...@fx...>
> Reply-To: bo...@la...
> To: OPT <out...@li...>
>
>
> I'd like to go back to my original solution and propose a new version
> augumented with a couple of changes which, in my opinion, would result
> in a flexible enough permissions system that anybody can implement
> whatever they want. So.
>
> 1. We still have the read/write/edit/delete permissions (Niels, "read"
> is the same as "see" - it wouldn't make any sense to see an item and not
> be able to read it, therefore if you can't read it you can't see it
> either). Additionally, there will be an admin flag (read further for
> clarifications).
> 2. We have groups/permission schemes/profiles or whatever you want to
> call them (detailed later - will be called groups from now on).
> 3. We have the data types structured in a tree - the tree starts at the
> top with [system] which branches in [projects], [users], [notes] and
> [admin] (I'll post a chart for everybody to see)
> 4. After careful consideration, I think my original "top-down"
> permission propagation is indeed wrong and should go as normal
> filesystems go.
> 5. You can store permissions for core data types in the groups. For a
> user to have read permission to documents, he has to have read
> permissions set to [system], [projects] and [documents] in these main
> groups. For example, group "regular user" would have these permissions
> by default. This doesn't necessarily mean that a user with these
> permissions set will be able to see *any* documents - he also has to
> have permissions in [project #p] and [document #d] in order to be able
> to see document #d in project #p - see below.
> 6. Groups can also contain *template* permission schemes for specific
> items. That is, the template permission does not contain a specific
> project number, for example - it just says "when assigned to a project,
> this will allow you to read documents in there". These are Tony's
> "roles". If you have no such group assigned for a project then you don't
> even see the project exists.
> 7. The groups can be assigned related to certain element types. Some
> combinations won't make sense (assigning system administrator group
> related to a document, for example). The system would warn the
> administrator who assigns such a group but by default the system will
> use the minimal combination - in our example above, the user would have
> "admin" permissions over that single document.
> 8. A admin flags would propagate bottom-up with minimal impact. That is,
> in the example above, the user will be able to see the project in which
> the document resides, but won't be able to see anything in that project
> except that particular document. He wouldn't even have the right to
> create items in the project - but he'd be admin for that document - for
> example, he'd be able to delete it.
> 9. An "admin" flag set for any core-level data type unassigned to any
> project would propagate top-down right to the bottom and *all* items
> below. For example, admin+read rights on [system] would be the same as
> the current "guest" access level: you can see everything but can't edit
> anything. An admin+read on notes would be needed to read all news,
> knowledge entries and newsletters. And so forth.
> 10. The groups are *only* additive - if a user is sysadmin you can't
> deny him access to a specific document.
>
> Considerations on this proposal
>
> GENERAL CONSIDERATIONS
> - In this proposal, groups are not groups of people - they are groups of
> permissions (better described as permission schemes, but called groups
> because if you name a permission scheme "SysAdmin" it's easier to say
> that a person is part of the sysadmin group than to say that a person
> has been assigned a sysadmin permission scheme).
>
> PROS
> - Administrators would have the possibility to implement any kind of
> groups they want and attach them to people.
> - Minimal data hard-coded
> - Once set up, you don't need heavy maintenance - just assign "sysadmin"
> related to a specific project to someone and you end up with a project
> administrator.
> - Along with user groups (Tony's virtual teams - which would be easily
> implementable afterwards) permissions administration would be really
> easy. This would imply adding another permissions type under [system]
> named [teams].
>
> CONS
> - Pretty database-intensive;
> - This is user-related permission scheme rather than item-related
> permission scheme. Take a look at the *nix filesystem permission scheme:
> permissions are per file, which has the great advantage that if you
> delete the file, you automatically delete the related permissions. Not
> so in the case of the solution proposed above.
> - You can't solve David Iyhoia's vendor/customer scenario - maybe this
> may be fixed by creating yet another categorization per project? i.e.
> create "vendors", "customers" and "developers" *item* groups per project
> (kind of the same as task categories, but running in parallel with
> those) and have to flag every item at creation time (this document is
> only for developers, this one is for both developers and customers etc).
> Then we'd have to take these into account when assigning groups to items
> - this guy is a developer sysadmin on a project. And then we'd have
> another category of permissions under [system] - [data groups].
>
> Would this be flexible enough to make everyone happy? Any simpler ways?
> Scenarios where this would fail? Looking forward to your opinions.
>
> Bogdan
>
>
>
>
> --
> Outreach-general mailing list
> You can post messages at Out...@li...
> You can change your options and unsubscribe at
> https://lists.sourceforge.net/lists/listinfo/outreach-general
>