Private trees are completely private - so how can we show welcome information?

[HRN]

svn 14400

When access to Family tree is set to "Require visitor authentication"
I get the following error when requesting new user account

ERROR 8: Undefined variable: SHOW_REGISTER_CAUTION
0 Error occurred on line 450 of file login.php

[fisharebest (fisharebest)]

I guess that all the trees on this server are private (require visitor authentication).

The fix for bug #981640 means that we now deny complete access to all private trees, which exposes this bug (and others).

There can be multiple private trees, with different settings for authentication/registration.
But we don't know which ones to show until after a user has logged in (and we know which trees they can access).

I'm not sure what is the best solution? Convert these from tree-settings to site-settings?

[kiwi (kiwi3685-deactivatedaccount)]

<<I'm not sure what is the best solution? Convert these from tree-settings to site-settings?>>

Yes, I think that is the only solution, as essentially user registration is no longer linked to any tree, or (?) even the existence of a single tree?

[Wes Groleau (webmaster-unigen)]

I don't know whether this is related or not (SVN 14466):

I was logged in (Firefox) and editing some text about requesting an account.

To verify a detail, I launched Safari (so that my login session would not be there).

I selected my other GEDCOM (not the default) welcome page and clicked the request link.

Filled out the form with a fake name but a real e-mail address and clicked Submit.

Blank screen except for a centered "Invalid page referer"

[Wes Groleau (webmaster-unigen)]

But mine do not require visitor authentication.

[Marcel Beerli (493pocbrcycmdw7yksonho9o2qzzq06652mtv6nw76-admin-d18ecat4t1b76tkfi3vttrkfngli4hci2jxl2sxy9j)]

Can an empty Tree be created called Login? (Administration - Family trees - Access) I used Require visitor authentication = no

then a new user request should not give any error, correct?

[Bert Koorengevel (bert-koorengevel)]

Yes, if you have an empty public tree to show a welcome page, that is a good work-around.
But it's just that: a work-around, not a proper fix for this bug.

[Diving Ivan (o-launchpad-noisesoff-com)]

Suggestion: Have a separate welcome/login page that is independent of any tree and is the default for unregisterd users. Allow administrator to customize a first_page_block and to add other blocks if the administrator wants to have something else available for unregisterd visitors.

[kiwi (kiwi3685-deactivatedaccount)]

Surely that last suggestion is describing the "Home page" exactly as it works now? All you need to do is add the login module to it, as I have always done.

[Diving Ivan (o-launchpad-noisesoff-com)]

kiwi: I'm using 1.3.2 and my HomePage is apparently tree-linked. Gedcom switching is, in fact, on the HomePage button. If you set up a new site with only a single private tree, don't put any blocks on the home page except the login, you'll find that no one can request a user registration.

To clarify what I'm suggesting: a *site-wide* Welcome Page that is *not* linked to any user or tree, and has the option of adding a *site-wide* html block (that is, not connected to a tree or user) (and maybe even a *site-wide* news). The Welcome Page would then _only_ be shown to unlogged-in users.

[kiwi (kiwi3685-deactivatedaccount)]

I have never understood why anyone would expect people to want to register on a "private tree". They can't see if there is anything there worth registering for.

I hope we can one day be bold enough to remove the "require visitor authentication" option. It is perfectly easy to manage what people can see without making the whole tree private.

These "private trees" are totally contrary to the very concept of webtrees IMHO - to foster collaborative genealogy.

[kanchan (kanchanpandey5)]

i want to display login only in home page ..how it can be done

[Jacqueline Gazaille (gazaillegen-deactivatedaccount)]

Kiwi:
These "private trees" are totally contrary to the very concept of webtrees IMHO - to foster collaborative genealogy.

I agree with Kiwi. I don't think we should waste time on solving a "user account" issue for these "completely locked down" websites.

An admin of a private website, IMHO, should create any new user account himself.

[Jacqueline Gazaille (gazaillegen-deactivatedaccount)]

Hi,
Would it be good to disable "request new user account" when "Require authentication" is set to YES ?

I mean webtrees offers so many privacy options that it is easy to set a "private" website without having to lock down the whole site.

[kiwi (kiwi3685-deactivatedaccount)]

Yes, Jackie, I agree. But I would still go one step further, and remove the "Require Authentication" option completely.

There is one other feature that I would add in its place:- the ability to manage who can see each of the main menu items.

Then to lock a site down would mean:
1 - Set "Show dead people" to "members"
2 - Set up the home page with just appropriate public blocks (even just an HTML block with an embedded login module if that's what you want).
3 - Hide as many menu options from visitors as you want.

If necessary we could even make these the default settings (if we really must).

(Note, 1) can already be done; 2) can already be done; 3) could be done easier with the added feature I mentioned, but wouldn't be hard now in a custom theme).

[fisharebest (fisharebest)]

<<3 - Hide as many menu options from visitors as you want.>>

It would presumably make sense for these menus to be hidden automatically when a user does not have permission to view living people.

<<If necessary we could even make these the default settings>>

No. But an upgrade script could easiliy convert

REQUIRE_VISITOR_AUTHENTICATION = yes

into

SHOW_LIVING_INDIVIDUALS = show to members

<<Set up the home page with just appropriate public blocks>>

We'd also need to change the logic here. The default set of blocks is added when no blocks are available. When all blocks are private, we get the problem of the default blocks being added over and over again.

[fisharebest (fisharebest)]

<<not have permission to view living people>>

Of course, I meant "dead" people...

[kanchan (kanchanpandey5)]

<<I'm not sure what is the best solution? Convert these from tree-settings to site-settings?>>

how to convert these setting?
from where i can change them

[Fred Rawson (phred53)]

<<the "Require visitor authentication" option, which causes lots of problems. We are considering the removal of this option. >>

<<These "private trees" are totally contrary to the very concept of webtrees IMHO - to foster collaborative genealogy.>>

Please don’t forget webtress is about the only good (full function, quality and open source) option for anyone wishing to independently host their own tree and collaboration isn’t necessarily their driving reason. I’m personally aware of several individuals using webtress as their desktop genealogy program (read no collaboration), who then publish their tree for use only by their families.

The “lock down your tree” debate must surely boil down to individual preference. Forcing collaboration on someone not interested in managing, moderating, ensuring quality and standards on a tree would ultimately result in just another junk tree. Even those who advocate open trees have occasion to “lock down a tree” – one example in my case being a couple of us working together on a research tree, testing hypotheses, making assumptions, collecting evidence – making that tree public would only serve to spawn junk trees not something we are interested in doing. Then there are those who, either themselves or members of their family, simply won’t tolerate an open tree for what they see as privacy issues.

All that said, if the fix for “Require visitor authentication” is too onerous, or detracts from other higher priority work, or you simply don’t want to fix the bug, so be it – but IMHO that would be a pity. Ultimately it’s your bat and ball.

[kiwi (kiwi3685-deactivatedaccount)]

Fred, sorry, and no offense intended, but you have missed the point, as many people do. Preserving the complete privacy of your data is not the same thing, in webtrees, as "Completely locking down the site".

In webtrees you can hide all data (I.e. hide dead as well as living people) without needing to lock down the site.

That means a whole unnecessary layer of complexity can be removed WITHOUT PREVENTING GROUPS SUCH AS YOU DESCRIBE FROM OPERATING AS THEY WISH.

[fisharebest (fisharebest)]

I've coded the change suggested in post #1 - convert these settings from "tree settings" to "site settings".

It seems to work OK, but I need a little more testing before I commit the changes. (Because there is a database update script that cannot be reversed).

[kiwi (kiwi3685-deactivatedaccount)]

I'm very disappointed that REQUIRE_VISITOR_AUTHENTICATION still exists after this update.

But if it is to be kept, then for those cases where all (or the only) tree(s) have it set to 'yes', then header.php should hide the complete menu bar and the header search box, otherwise the insanity of links to pages that show nothing remains.

[fisharebest (fisharebest)]

Fix released in webtrees 1.4.2