Question [SOLVED] Why getAnniversaryEvents is empty for anonymous?
- UksusoFF
- Topic Author
- Offline
- Junior Member
Please Log in or Create an account to join the conversation.
- fisharebest
- Offline
- Administrator
If this data is private, and you are not logged in, then you cannot see it.
Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Please Log in or Create an account to join the conversation.
- UksusoFF
- Topic Author
- Offline
- Junior Member
And i can't find where access check in this function. Can you tell me string number where this done?
Please Log in or Create an account to join the conversation.
- ToyGuy
- Offline
- Moderator
- Live like it's Christmas every day - Santa Stephen
Santa Stephen the Fabled Santa
Latest webtrees at MyArnolds.com
Hosted by webtreesonline.com , a division of GeneHosts LLC
MacOS 10.6.8, Apache 2.2+, PHP 5.4.16, MySQL 5.5.28
Please Log in or Create an account to join the conversation.
- fisharebest
- Offline
- Administrator
The privacy functions are handled at a very low level. In the "Individual" and "Fact" objects.
If you want to write code that bypasses the privacy, you will need to create a fake session/user.
Perhaps create a dummy user object, and pass it to Auth::login()
Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Please Log in or Create an account to join the conversation.
- UksusoFF
- Topic Author
- Offline
- Junior Member
ToyGuy wrote: Assuming there was anonymous access, it would only return the already public information on the site. If set as default,webtrees would show anniversary dates for deceased persons only and while, on occasion that might be nice, it doesn't help with providing living persons' birthdays or anniversaries, and, without exposing critical private data, never could do more.
fisharebest wrote: > Is there way to get this data for anonymous user?
The privacy functions are handled at a very low level. In the "Individual" and "Fact" objects.
If you want to write code that bypasses the privacy, you will need to create a fake session/user.
Perhaps create a dummy user object, and pass it to Auth::login()
Thanks. I will try this.
But can you explain why in autocomplete have additional check for this. Why not returns only values which can be viewed?
For eg: github.com/fisharebest/webtrees/blob/mas...autocomplete.php#L56
Please Log in or Create an account to join the conversation.
- bertkoor
- Offline
- Platinum Member
- Greetings from Utrecht, Holland
UksusoFF wrote: Why not returns only values which can be viewed?
For eg: github.com/fisharebest/webtrees/blob/mas...autocomplete.php#L56
I guess because $something->canShow() is rather hard to implement directly as a SQL query, but very easy to implement as a function on the PHP object. If this was implemented as a SQL query, the queries would get extremely complicated and harder to optimise.
Whether an object can be shown depends on a lot of factors, so better hide that away in the object itself. Also when the implementation needs to be changed, it can be done at one place only, and not in the hundreds or thousands SQL queries present in the application.
stamboom.BertKoor.nl runs on webtrees v1.7.13
Please Log in or Create an account to join the conversation.
- fisharebest
- Offline
- Administrator
We then use PHP to apply the privacy rules (slower).
I looked again at the code.
The function Individual::getFacts() has a parameter "override" which ignores the privacy. We use this to set a different privacy level when downloading GEDCOM files. You might be able to use this?
Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Please Log in or Create an account to join the conversation.
- UksusoFF
- Topic Author
- Offline
- Junior Member
Yep, I understand this.bertkoor wrote: I guess because $something->canShow() is rather hard to implement directly as a SQL query, but very easy to implement as a function on the PHP object. If this was implemented as a SQL query, the queries would get extremely complicated and harder to optimise.
Whether an object can be shown depends on a lot of factors, so better hide that away in the object itself. Also when the implementation needs to be changed, it can be done at one place only, and not in the hundreds or thousands SQL queries present in the application.
As I can see Individual::getFacts() can't accept julian day or something other way to filter by day.fisharebest wrote: We use SQL to find the records (very fast).
We then use PHP to apply the privacy rules (slower).
I looked again at the code.
The function Individual::getFacts() has a parameter "override" which ignores the privacy. We use this to set a different privacy level when downloading GEDCOM files. You might be able to use this?
Looks like Auth::login() works fine. But I think that have performance issues on large databases with many users and my implementation.
Please Log in or Create an account to join the conversation.
- UksusoFF
- Topic Author
- Offline
- Junior Member
Ouch, it's work only with public trees.UksusoFF wrote: Looks like Auth::login() works fine. But I think that have performance issues on large databases with many users and my implementation.
Why this:
Please Log in or Create an account to join the conversation.
- UksusoFF
- Topic Author
- Offline
- Junior Member
Please Log in or Create an account to join the conversation.
- UksusoFF
- Topic Author
- Offline
- Junior Member
Please Log in or Create an account to join the conversation.