I was looking around the privacy module tonight, and thought it would be nice for some to have additional levels of privacy.
Admin
Related-Auth
Auth
Public
Comes to mind first. However, I see more potential for increased group useage. Related-Auth could be inreased privlages such as private data viewing. Auth could give a subset of of Related-Auth until an Admin increases rights. Public on the other hand can view the most limited subset of rights. Possibly not viewing any living persons data, name, or existance as if at the end of the tree. Also allowing for an Admin to display a hint that authenticaion is needed beyond that point. One could also allow the Admin to "Disable Complete Branches" of a tree.
Just a thought, I know Rights Management is a tough one to implement. Esspecially with all the combinations one could cook up. Perhaps just the ability to create a couple of other groups. Related vs. non-Related but still family.
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There has been talk elsewhere (I think in the RFEs) of disabling full branches of the tree. Such as a person and all their descendants or a person and all their ancestors.
This introduces a speed issue in that for every person who needs to have their privacy checked I have to compute the relationship between them and the other person. This would be a very slow calculation.
This would require a completely different privacy module based on ownership and groups. This means that each individual in the gedcom would have an "owner" user with permissions and a "group" of users with permissions. This would be very similar to the file system. The owners of records would then give permissions to other users. It would also require extending the gedcom spec to add owner, group, and permissions for each object.
I introduced this comment a while ago in the forums and didn't receive any response on it. I suppose the use case is very unique. It is more for a single large database running in a multi-user environment. It could be done, but I'm not sure that it has a marketable audience.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply. Personally I'm happy with the privacy module, however I was thinking that some extra options would be nice. Perhaps whe the project mature more, we'll see a clearer way.
I probably overlooked past messages, as I was not concerned with privacy stuff, the default was working fine for me.
Thanks
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
John,
I was looking around the privacy module tonight, and thought it would be nice for some to have additional levels of privacy.
Admin
Related-Auth
Auth
Public
Comes to mind first. However, I see more potential for increased group useage. Related-Auth could be inreased privlages such as private data viewing. Auth could give a subset of of Related-Auth until an Admin increases rights. Public on the other hand can view the most limited subset of rights. Possibly not viewing any living persons data, name, or existance as if at the end of the tree. Also allowing for an Admin to display a hint that authenticaion is needed beyond that point. One could also allow the Admin to "Disable Complete Branches" of a tree.
Just a thought, I know Rights Management is a tough one to implement. Esspecially with all the combinations one could cook up. Perhaps just the ability to create a couple of other groups. Related vs. non-Related but still family.
John
There has been talk elsewhere (I think in the RFEs) of disabling full branches of the tree. Such as a person and all their descendants or a person and all their ancestors.
This introduces a speed issue in that for every person who needs to have their privacy checked I have to compute the relationship between them and the other person. This would be a very slow calculation.
This would require a completely different privacy module based on ownership and groups. This means that each individual in the gedcom would have an "owner" user with permissions and a "group" of users with permissions. This would be very similar to the file system. The owners of records would then give permissions to other users. It would also require extending the gedcom spec to add owner, group, and permissions for each object.
I introduced this comment a while ago in the forums and didn't receive any response on it. I suppose the use case is very unique. It is more for a single large database running in a multi-user environment. It could be done, but I'm not sure that it has a marketable audience.
--John
John,
Thanks for the reply. Personally I'm happy with the privacy module, however I was thinking that some extra options would be nice. Perhaps whe the project mature more, we'll see a clearer way.
I probably overlooked past messages, as I was not concerned with privacy stuff, the default was working fine for me.
Thanks
John