It seems at one time, users that were identified with their gedcom ID were able to edit (subject to "approval" after editing) three generations: theirs, children & parents. Am I wrong, or is this no longer functional?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thomas … if it was once like that, it was before my time (2006). The only thing I can think of that's remotely like this is the default relationship privacy of 3 generations away from the user's root id, but that's only for visibility purposes, not for editing purposes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IIRC, the problem was that a user can "marry" or "adopt" an existing indi, which makes them immediate family, which enables them to view/edit private individuals.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess not. If I were malicious, and the admin was too easy, the code (modified) might prevent me from adopting or marrying the person I want to tamper with. So then I'd just use my sibling. Block that, and there'd probably be **another** relative close enough.
But the question still stands-is it no longer possible to grant editor access because of the privacy risk?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-19
Wes, I think you've missed the point of the original question. It related to an idea that users could be given LIMITED edit rights - to only their immediate family.
It is of course still possible to grant editor access, just as it always has been. But edit means the ability edit anything on the tree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One compromise may be to prevent users with 'limited editing rights' linking to anyone else in the database. The administrator can set up their record and parental links during the approval process. Then the user will only be required to Add new records.
It seems at one time, users that were identified with their gedcom ID were able to edit (subject to "approval" after editing) three generations: theirs, children & parents. Am I wrong, or is this no longer functional?
IIRC this didn't work properly, and was taken out.
Thomas … if it was once like that, it was before my time (2006). The only thing I can think of that's remotely like this is the default relationship privacy of 3 generations away from the user's root id, but that's only for visibility purposes, not for editing purposes.
It sure would be nice to have a feature like that, or to allow editing of parents and any generation below.
IIRC, the problem was that a user can "marry" or "adopt" an existing indi, which makes them immediate family, which enables them to view/edit private individuals.
I'm confused. Does this mean now only admins can edit?
Would it solve the problem if they can edit family, but they can't change their own relationships?
I don't see the risk if the admin has to approve the change.
I guess not. If I were malicious, and the admin was too easy, the code (modified) might prevent me from adopting or marrying the person I want to tamper with. So then I'd just use my sibling. Block that, and there'd probably be **another** relative close enough.
But the question still stands-is it no longer possible to grant editor access because of the privacy risk?
Wes, I think you've missed the point of the original question. It related to an idea that users could be given LIMITED edit rights - to only their immediate family.
It is of course still possible to grant editor access, just as it always has been. But edit means the ability edit anything on the tree.
One compromise may be to prevent users with 'limited editing rights' linking to anyone else in the database. The administrator can set up their record and parental links during the approval process. Then the user will only be required to Add new records.
Unless, ofcourse I've overlooked something else :-)