There is a possibility of access permission conflict on UI. In current UI, when user views all document, he will see all the groups and documents that are the part of root document group (i.e. on top level in hierarchy). Documents that the part of only some group will only be visible under only those groups. If a person does not have read permission to those groups, he won't be able to see that document because there is no path for the use that lead to the document.
For example, as shown in above image, there is a doc which is only inside the Steering Wheel. User has permission to read/write that document. But he doesn't have permission to read Steering Wheel Document Group. So if he want to read the document inside it, he must be able to go to Steering Wheel and get a link to see document. But he can't as he won't be able to see Steering Wheel in first place!
So, such implementation will cause issues for such scenario.
There are two possible solutions that I can think of,
1. User will be able to read a document group (but see his file only) even if he doesn't have permission, if he has access to one or more document groups or documents inside that document group. But this thing will cause another visibility issue. Suppose if a document is part of several document groups. User have access to some groups only, then he will also see the other document groups (with just his file) for which he doesn't have access to. So, he will be actually see the name of document group which he is not suppose to know in some case. Again, a solution for that can be, if a document is part of at least one group that he can read, he won't be able to see other groups. This approach looks ideal but again, computation overhead and complexity for system will increase causing slower performance if number of document/user/access groups/members and documents increase and relation between them become complex.
2. A much more simpler approach to this issue may be, in root document group (i.e. page after clicking View All Documents link), as we are listing all document groups, we also list all the documents so that there is no issue for visible path to access the file. There is always a link to document if user has access to it. This approach has very less overheads compared to first approach.
So what approach do you think is good to adopt?
For example, as shown in above image, there is a doc which is only inside the Steering Wheel. User has permission to read/write that document. But he doesn't have permission to read Steering Wheel Document Group. So if he want to read the document inside it, he must be able to go to Steering Wheel and get a link to see document. But he can't as he won't be able to see Steering Wheel in first place!
So, such implementation will cause issues for such scenario.
There are two possible solutions that I can think of,
1. User will be able to read a document group (but see his file only) even if he doesn't have permission, if he has access to one or more document groups or documents inside that document group. But this thing will cause another visibility issue. Suppose if a document is part of several document groups. User have access to some groups only, then he will also see the other document groups (with just his file) for which he doesn't have access to. So, he will be actually see the name of document group which he is not suppose to know in some case. Again, a solution for that can be, if a document is part of at least one group that he can read, he won't be able to see other groups. This approach looks ideal but again, computation overhead and complexity for system will increase causing slower performance if number of document/user/access groups/members and documents increase and relation between them become complex.
2. A much more simpler approach to this issue may be, in root document group (i.e. page after clicking View All Documents link), as we are listing all document groups, we also list all the documents so that there is no issue for visible path to access the file. There is always a link to document if user has access to it. This approach has very less overheads compared to first approach.
So what approach do you think is good to adopt?
I think the issue here is your concept of the User Interface ...Note our discussion on the hierarchy of rights...
ReplyDeleteYour suggestion in point 2 is the expected behavior for our implementation at this point...