Control I also ask a question about the design of permissions
I am now doing a system, a similar information released Dongdong, originally also does not matter, can not think of the user put forward a lot of BT requirements, especially the authority, originally according to my conventional thinking, this kind of dongdong is generally divided into several roles, divided into a few information of the release module and so on line, Even companies have ready-made things to use directly.
But did not expect the customer's request is more tricky. Let me first talk about the approximate appearance of the system.
Information release, first of all, of course, to classify the category and level of information, and this level is indefinite, may be two or three layers, may also be 10 layer, eight layer (not so sick bar ^_^), in fact, similar to the style of the Windows Explorer, the directory contains files, and the file May and the directory peer said, This is what the display aspect probably wants to show. Now talk about their requirements in terms of authority control, after a user logs on to the system, these directory files (using a similar style of explorer, a tree on the left, a list of basic information on the right) will need to vary depending on the user's permissions (some directory files are displayed, some do not show), Of course, for different records users also need to have different additions and deletions, although the list can be seen, but some records he can be modified but can not delete, and some even modified are not allowed, of course, there are other ways to control the operation. More perverted is the requirement to click on a record (or directory, or file) view the page for different permissions of users also need to be different, that is, some fields can be displayed, some fields are not displayed (my God, or I have to recycle it), which requires the management of the background has a flexible operation, Of course, the user also asked, in line with the principle of ease of use, the administrator can be appropriate to choose a record to empower or to a group of records to empower.
Having said so much, I wonder if you can see it?
I started with the idea of defining groups, assigning certain users with the same permissions as a group, then you choose the record by selecting the group without having to select each person, so that you do not have to operate on the individual (even if a person has a group for him), so that group configuration changes can have those permissions on the record, and you can display the fields that are logged. The group is then selected for the record (one user may belong to more than one group, and if there is duplication, the maximum permissions the user can obtain).
However, after a thought, the inclusion of certain records is only for individuals, if you do so, it will be dead, ah, the number of groups is too much.
However, the user's requirements in the final analysis is quite reasonable, but the realization is really quite a headache, anyway, I have a headache for a afternoon, a few table of contents files after painting, background permissions on the side of my hand: (
I would also like to be able to take advantage of this system to manage this privilege inter-accounting inter-accounting, anyway, as far as possible in the design phase to consider the perfect, it is best to be able to the permissions of this piece as far as possible independent, in the future in other systems can be more easily moved to (it is not estimated that the information system has so cumbersome requirements, the original is not a big thing, Leng let them make a big mess.
But I am in the design is a novice, so it is very difficult to feel very much, or listen to all of you here pontificate first, please advise how to start, Information table and permission table How to relate, if anyone has done this aspect of things, then better.
All the experience, methods and suggestions are welcome in the next, please do not hesitate to enlighten me, I really have a big head
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 00:36:37 reply
Published by: Iceant published article: 413/Registration Time: 2002-10
1. "Some of the catalogue documents show, some do not show" questions
Files that are specific to a directory can be controlled for display and not display, but are not suitable for the directory to do such control. Why? If the user only has access to the 1.1.1 directory, does the 1.1 directory level need to be reflected? If only a directory where the user has permissions, how can you tell which directory is 1.1.1?
2. Group and user
Your application is actually the application of dynamic responsibility determination, there is no way to know which characters can manipulate which objects in the program planning and implementation phase;
In addition, the permission design must not be too complex, otherwise the administrator will not be able to find out their assigned permissions is what kind of, at least I add a two or three-storey dongdong will be dizzy.
So I suggest that you do ACL based control. You mentioned the concept of wanting to use a group, but you want to define a group for a person, which I think is not necessary, completely can be user (users) and Subject (folder| Documents) directly corresponding. If only one person can manipulate the file modification of a directory, then you directly authorize a person, and modify the Role-user Map relationship maintenance is not much different. However, if the same Permission operation of a directory is authorized to different users, it is certainly not easy to maintain a group or a character.
Therefore, my choice is to directly use the Subject,group,user three-level relationship.
Here are some of the nouns to explain first:
Subject: Various directories, files and other objects
Group: User Collections
User: Users
Operation: A specific operation of Subject, such as visit,modify,delete, etc.
Permission: A combination of Subject and Operation, such as: refers to the visit operation of a directory
OK, let's build a few tables:
Permissions_table (
Subject varchar,--The ID of the corresponding directory or file
User_name varchar (a)--User-subject ACL
Group_name varchar (a)--Group-subject ACL
Operation_type int,--1:visit,2:modify 4:delete,3:visit+modify,5:delete+visit,6:delete+modify,7:visit+modify+ Delete
Subject_type int,--1:dir,2:document
)
User_group_table (
User_name varchar (10),
Group_name varchar (10),
Primary KEY (User_name,group_name)
)
Again below ....
I believe you have the ability to finish ....
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 10:02:00 reply
Published by: Ninsky published article: 20/Registration Time: 2003-10
Thanks to Iceant, your advice gave me a thought, some places I did go astray, but also blindly want to design a generic dongdong (it is estimated that this is over design)
But I would also like to ask you, for the permission mode that controls to the field can you also offer a little suggestion?
I now just want to find more people, listen to other people's opinions, and then their own synthesis, I hope to be able to achieve this set of rights management functions as well as possible
I hope you can speak more and hope to stimulate my tired brain.
Thanks again for Iceant,jdon's discussion ethos is the best of my several forums.
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 11:16:11 reply
Published by: Iceant published article: 413/Registration Time: 2002-10
"Can you give me some advice on the permission mode that controls the field?"
What is the permission mode that controls the field?
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 12:19:51 reply
Published by: Ninsky published article: 20/Registration Time: 2003-10
> Can you give me some advice on the right mode to control the field?
>
> What is a permission mode to control to a field?
Is that some of the fields in a table can be displayed and some are not displayed
Of course, there is a way to put all the table fields and related descriptive information into a data dictionary table, and then to the data dictionary to do some related weighting operations, but this requires the data dictionary and all the table's field synchronization
But it's not always a good idea, but I didn't think of any other way.
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 12:29:24 reply
Published by: Iceant published article: 413/Registration Time: 2002-10
Can you tell me more about your application scenario? As an example
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 13:41:19 reply
Published by: Ninsky published article: 20/Registration Time: 2003-10
> Can you tell me more about your application scenario? As an example
Information about users, units, etc. is stored in LDAP, and is remote, my system although take is LDAP in the user, unit information, but also have to provide additional user, Unit added function, that is, in the reading of users, unit information to the LDAP information and their increased user, unit information convergence, Re-arrange the tree (this place takes the form of generating an XML tree without knowing how it works), while also determining the permissions of the current user to control whether each node is displayed (these nodes may be units or individuals).
Then the information displayed on each node has to read control permissions, the information can be displayed, those who can not be displayed, in addition to the various information on the operation of the Authority also has control over a piece of information is to increase, delete, change, or just view. And for the details of a record, you need to control whether a field is displayed, and so on, and so on, and so on
My initial idea:
Division function points: Functional modules (different users have different operating modules, such as our general Program top menu items, non-LDAP and related information), table structure (data dictionary table, control to field permissions)
Operation (operate): Add, delete, change, view
Role: Functional modules, and related operations
Users: Assigning roles
Group: Assigning Users
Come on, let's just say this, I'm dizzy, and now I'm in a mess.
Re: I would also ask a question about the design of the rights issue time: October 22, 2003 13:54:05 reply
Published by: Iceant published article: 413/Registration Time: 2002-10
My feeling is that you are not clear about your needs, and you are going to sit down with your clients and talk about what they want. You can draw the operation of the interface, and then ask the customer is not want to do so, if not, how to change, and finally a need for changes in the instructions (may want you to write, the customer signed, this is also a protection of your own!), indicating what needs to be identified.
