Question

How do you edit Main.TWikiPreferences as indicated as the first bullet under "Next Steps" in the Installation Guide for 4.0, when you haven't gone through setting up authorization or even registered yet? I am carefully going through the installation of the latest build (TWiki-4.0.0-beta6) using the TWikiDocumentation Installation Guide included there.

It seems like this is a chicken/egg issue with installation. I'm going to keep working, and I'll publish my findings here as I go. I will hopefully end up with a suggestion to add to the installation guide.

The exact problem is the following Access Denied error. Of course I'm in as Guest, having just finished the Basic Installation section.

Access check on !Main.TWikiPreferences failed. Action "change": access not allowed on topic.

My first question: It seems like I have to (1) Register and (2) somehow add myself to the admin user group first. But even before all that, do I have to (0) enable authentication?

Troubleshooting: I am now enabling authentication through 'configure' per the docs on User Authentication. I am choosing Template Logins. I am leaving the default password handler of Htpasswd.

• Enabling authentication is now better descriped in InstallHtmlTWiki04x00x00. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 26 Jan 2006

BTW I found a bug on that error page (Main/TWikiPreferences?template=oopsaccessdenied;def=topic_access;.....).

It says:

Contact !TWikiGroups, !TWikiAccessControl

The link there on TWikiGroups is mailto-webmaster@examplePLEASENOSPAM.com, but the link to TWikiAccessControl works like you'd expect. It should probably say instead:

Contact webmaster@example.com. 
See Also: !TWikiGroups, !TWikiAccessControl

• Fixed in RC1. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 26 Jan 2006

Small bug: The instructions at the top of 'configure' fit inside the web page beautifully, but all the comments inside each block are too wide and don't wrap reasonably. E.g. TWiki supports different ways of responding when the user asks to log in (or is asked to log in as the result of an access control fault)....

• This is because of long strings in environment variables in one of the first sections being unwrappable, not much that I can do about that, unfortunately. At 1024x768 or higher resolutions this should work OK. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 26 Jan 2006

Another possible bug: Opening 'configure' for the second time (several hours after the first time) it didn't prompt me for my 'configure password' which I'd already set the first time. Instead, it let me change settings and then asked me again to SET the configure password.

• This is intended behaviour, reading configure is public by default. -- SteffenPoulsen - 31 Jan 2006
• Then I am missing the point of the 'configure password'. Public view configuration okay - sort of. Public change of configuration - seems like a really bad idea to me. -- PabloCaskey - 08 Feb 2006

-- PabloCaskey - 26 Jan 2006

Bug: In 'configure' I also set Register-AllowLoginName to True and yet the Registration page does not include a Login Name field as advertised. However, I do see a stray <td align= on the Registration page, now.

I confirmed the setting made it into my local config file at the command line:

LocalSite.cfg:$TWiki::cfg{Register}{AllowLoginName} = 1;
TWiki.cfg:$cfg{Register}{AllowLoginName} = $FALSE;

Maybe my local setting isn't properly overriding the system default. I'll try setting it in TWiki.cfg. Nope. No dice.

Bug Fix: The Login Name is not appearing on the Registration page because of some problem with escaped quotes. I fixed it like this in data/TWiki/TWikiRegistration.txt by removing all quotes inside the nested HTML (view raw here):

# optional row for login name, enabled by {Register}{AllowLoginName} option in =configure=
* Set BESPOKE_AUTH =  (how you log in) LoginName:  =**= 

But that's a hack; someone needs to fix it for real. I haven't studied this code long enough to figure out how to really nest the quotes.

• These issues with fields in registration are fixed in RC1. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 26 Jan 2006

Back to working on this authentication problem: I found Main/TWikiAdminGroup and am trying to follow the instructions there. First, it would help to put "edit this topic" as the first step. Then it says to remove the pound sign in front of ALLOWTOPICCHANGE but not GROUP, so I hope that's right. Here goes.

I don't understand this: "set the ALLOWTOPICHANGE in TWikiPreferences to this group". Set the ALLOWTOPICCHANGE what? Variable? Set it to what group? TWikiAdminGroup? This is really weird!

That TWikiPreferences link takes me back to the site defaults, which I'm not supposed to edit, even though it gives me a nice big Edit button and lures me in. Very confusing! But okay, I use Ctrl-F in Firefox to search that whole page for "ALLOWTOPICHANGE" and it's not there.

In any case, even if I could find this ALLOWTOPICHANGE variable, I can't copy it into Main.TWikiPreferences because I don't have permission! I'm back to the chicken/egg problem. How do I escape this cycle?

I believe I locked myself out by following those buggy directions too closely on the Main/TWikiAdminGroup page. As I wrote above, it said to uncomment ALLOWTOPICCHANGE but not GROUP. I am now uncommenting GROUP as well, using vi as root on the filesystem. I am carefully editing both TWikiAdminGroup.txt and TWikiAdminGroup.txt,v removing the single '#' from the 'Set GROUP = PaulCaskey' line. Here goes.

Hey! Now I show up under Main/TWikiGroups! This is looking good.

Now it lets me edit Main/TWikiPreferences. Now I see there's a commented section in there setting ALLOWTOPICCHANGE and ALLOWTOPICRENAME to TWikiAdminGroup. I uncommented that section.

• Pinned out details in TWikiAdminGroup a bit, trying to avoid chicken-egg / catch 22 problem. -- SteffenPoulsen - 31 Jan 2006
• Many thanks. -- PabloCaskey - 08 Feb 2006

-- PabloCaskey - 27 Jan 2006

Development Site Bug: Your devel site clearly says, "Do not register here at develop.twiki.org, use your twiki.org account to login." However, my twiki.org account does not work. I have verified my password is correct. So I will just post my info here.

• I don't understand why this would not work. Feel free to register at develop again, registration process should work now. -- SteffenPoulsen - 31 Jan 2006
• Again? I never registered at develop, because of the highlighted giant yellow warning not to. I'll ignore that and register in a bit. -- PabloCaskey - 02 Feb 2006
• This failed for me but I'm trying again. -- PabloCaskey - 08 Feb 2006

Environment

Answer

To Developers:

The above notes from this newbie should make it obvious how confusing the Dakar installation is. The following suggestions would go a long way. Please also see the bugs reported above.

1. The Installation Guide for Dakar needs to be updated. The Next Steps section starts off with the suggestion to "Review TWikiPreferences settings" but this is not possible until authentication has been enabled and you have added yourself to the Admin group. (Okay, it's possible to review the Prefs, but not change.) At a minimum, move the 'Enable authentication' bullet to the top of the 'Next Steps' section. Emphasize the requirement of setting up the Admin group.
   • See above -- SteffenPoulsen - 31 Jan 2006
2. Be even firmer about treating TWiki.TWikiPreferences as read-only. If it really shouldn't be edited, don't allow it to be edited.

3. Typo on TWiki.TWikiPreferences: customaisations
   • Fixed. -- SteffenPoulsen - 31 Jan 2006
4. Remove the HTML comment tags on Main.TWikiPreferences surrounding the ALLOWTOPICCHANGE and ALLOWTOPICRENAME settings. I see no reason to hide those settings. A newbie who knows HTML might think the HTML comment disables the variables, especially since it's supposedly part of the Access Control setup to enable them.
   • Seems someone else did this. -- SteffenPoulsen - 31 Jan 2006
5. Add a clarifying sentence on TWiki.TWikiAccessControl: "To hide access control settings from normal browser viewing, place them in HTML comment markers. The control settings will still be active."
   • Seems someone else did this. -- SteffenPoulsen - 31 Jan 2006
6. The setup text on Main/TWikiAdminGroup needs to be updated as follows.

---+++++ Setup Note: 
   1. Verify that user authentication is working.
   1. Edit this topic page by clicking Edit below. You are then editing this group called !TWikiAdminGroup.
   1. Add yourself and any other registered members you wish to the GROUP line above, separated by commas. 
That assigns those people to this group. E.g. 'Set GROUP = !JohnSmith, !JackieJones'
   1. The ALLOWTOPICCHANGE variable above controls who can edit this page. Leave it set to !TWikiAdminGroup. 
That ensures that only the members of this group will be able to edit the group itself. 
   1. Enable both the GROUP and ALLOWTOPICCHANGE variables above by removing any # signs before them.
   1. Save this topic.
   1. You should now be able to edit the Main.TWikiPreferences topic page, because the variables ALLOWTOPICHANGE
(and ALLOWTOPICRENAME) are both set to !TWikiAdminGroup inside that page, and you just added yourself to that
group. (Those variables may be hidden inside HTML comments on that !TWikiPreferences page, but are still
functional. Use Edit to see them.)
   1. (Optional) Remove this note after you have done this setup.

See TWiki06x01.TWikiAccessControl#Managing_Groups for more information. 

• • Took some, left some out, thanks for the suggestion! -- SteffenPoulsen - 31 Jan 2006

Authentication in Dakar seems to still be in a limbo state. There's no commitment to requiring authentication as part of the basic installation, but you hit a brick wall very quickly without it. The same thing goes for Access Control. Since the settings for the site are accessible through the Wiki itself, Access Control is required. But this goes against Wiki Culture, hence limbo and the catch-22 I hit as a newbie installer.

You've made a huge leap forward in Dakar with the 'configure' script and the 'configure password', even though that password doesn't appear to work properly, to me. I suggest you bite the bullet and make authentication and access control part of the "basic installation" and just emphasize that it's required for Main.TWikiPreferences. And disable editing of TWiki.TwikiPreferences altogether.

I am leaving the status as unresolved here, for now. Again, I would log this under Bugs but my login doesn't work. I apologize if I'm doing something stupid.

• Your feedback is welcome, please continue doing this - hope you'll be able to use the Bugs web any time soon. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 27 Jan 2006

Bug: Main.UserForm doesn't seem to include the new Login Name for display or editing in the fancy form.

• Fixed. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 28 Jan 2006

Is anyone here? I could contribute to Dakar if someone can tell me why I'm not able to create a new bug report on devel.twiki.org. I see "Hello Pablo Caskey" on devel.twiki.org, but maybe I need additional blessing before I'm permitted to log bugs.

• Please try again, see above. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 30 Jan 2006

Possible Bug: A new user just registered at my site, and his personal page under TWikiUsers started off with "ALLOWTOPICCHANGE = TWikiGuest" instead of being set to himself or wide open. So he can't edit his own page. There must be a setting somewhere to control this, so I'll RTFM. But there are a LOT of FM's!

It seems like a bug of some sort, because he even logged out and still couldn't edit his page, because it asks him to log in upon Edit. So it's a Catch-22, and I doubt I'll even be able to edit as a member of AdminGroup. It may be time to create/edit SuperAdminGroup? (Yes I was able to edit as regular Admin.)

• Known beta6 bug, fixed in RC1. -- SteffenPoulsen - 31 Jan 2006

-- PabloCaskey - 30 Jan 2006

Pablo: Thank you very much for helping out. Your feedback is tracked at Bugs:Item1542.

Developers: Please mark individual items above as DONE once in SVN.

-- PeterThoeny - 30 Jan 2006

Thanks, Peter.

Small Bug: All indents on TWiki Prefs and Main Prefs need to be changed from TAB to three spaces for consistency with the new scheme of NOT doing that conversion within the software.

• Both should work OK - what kind of trouble do you get, Pablo? -- SteffenPoulsen - 31 Jan 2006
• No trouble; it just seemed like a smart thing to do. -- PabloCaskey - 02 Feb 2006

-- PabloCaskey - 30 Jan 2006

FYI: My users are getting confused with the new Sandbox Web and its fancy form and search results. They see the Recently Edited list of pages and expect to see those when they edit the main Sandbox page. I added the following blurb to help, right before the SEARCH(...) in Sandbox/WebHome:

The following list comes from a magic search result and is not editable! 
This Sandbox home page should not be edited much. Use the Form above to create 
new Sandbox sub-topics, and practice there. Within your new sub-topic, 
use More Topic Actions (bottom right) to delete it, and it will disappear 
from the following list. 

-- PabloCaskey - 02 Feb 2006

I'm falling behind and need to post my replies to more stuff above. I'm doing blue to alternate w/your red . Something happened with authentication and I was locked out of here for a while, and I still haven't made it into the dev site, so I will continue here.

-- PabloCaskey - 07 Feb 2006

I am still running 4.0beta6. I will upgrade to the full 4.0.0 ASAP but decided to go ahead and report what I'm seeing.

Minor doc bug: After password change, it says "you must close your browser" but that'd only be true if I was doing apache auth. I'm doing Template logins, so it could say "you must log out" instead. But this would require an "IF" hack on the page and may not be practical, so saying "close browser" is safe all around - fair enough.

-- PabloCaskey - 07 Feb 2006

Bug: A user uploaded an attachment to their topic. Then they deleted it -> Trash. Then uploaded another file with the same name. Then tried to delete it -> Error, file already exists in Trash.

I gave them access to both view and edit the Trash web. They went in Trash, found the TrashAttachment topic, found their file -> manage -> delete -> Error, file already exists in Trash.

Is there some way to actually delete a file from the Trash?

-- PabloCaskey - 08 Feb 2006

Bug: A user created a topic with parenthesis in the name, and it never "stuck". The topic page got created, but the parent page kept showing a question mark. We couldn't get to the topic -> More-topic-options to rename it. I'm guessing the parenthesis were the problem. Nothing else stood out as unique.

-- PabloCaskey - 08 Feb 2006

Bug: We are seeing strange behavior with the bread crumbs. Sometimes they work properly for sub-topics, and sometimes not. We are still trying to find any pattern or consistency. We noticed one indicator: 1. View the subtopic of a parent topic where the parent isn't showing up in the bread crumb trail. Examing the sub page's Backlinks. The parent does not show up. Oops, no, that's not consistent. I just found a case where the parent DOES show up on backlinks, but the parent DOES NOT show up in the bread crumb trail.

Workaround: Create a clone subtopic page, then delete the first one, then rename the clone page to the name of the first.

• Update: Create a brand new subtopic, and the parent will show up properly in the bread crumbs. Edit the subtopic 1+ times, and the parent disappears from the bread crumbs. Not tested 100%, but this may be the pattern. -- PabloCaskey - 09 Feb 2006

-- PabloCaskey - 08 Feb 2006

Help: This is probably a security FAQ, but I'm not finding it. If I lock someone out of Main.Blah with ALLOWTOPICVIEW, they can get around that by going straight to http:.../twiki/data/Main/Blah.txt. Point me to the fix? Can I move "data" outside of my apache document root?

-- PabloCaskey - 08 Feb 2006

Wish: I set TWiki to use the server's time zone, and I know that doesn't work everywhere, but here's my vote on priority: It'd be really cool if it was used when generating "Your signature for easy copy and paste". Late in the day here in the USA, it tells me I'm posting one day into the future, and it'd be nice if I didn't always have to double-check that and fix it. Maybe it's just a good sign I should get out of the office and go home!

-- PabloCaskey - 08 Feb 2006

Bug: This is probably fixed in RC1. In Preview mode, I'm seeing the contents of sub-topics start to "bleed" in to the linking page, right after the wiki name link.

-- PabloCaskey - 08 Feb 2006

Minor: After upload an attachment, the auto-created link (if chosen) only has one space before the splat. It needs three.

-- PabloCaskey - 09 Feb 2006

Deleting questions here as I post them to Bugs on Devel. -- PabloCaskey 13 Feb 2006

Hm, is this 'support question' answered or not?

-- TWikiGuest - 09 Feb 2006

Pablo, if you want to give us a fair chance of following your threads, please post them as one issue pr. topic, and name the topics properly. This is just too unstructured to cope with.

Mane of the issues you mention are solved in TWikiRelease04x00x01 - any chance you could try upgrading to that release asap, and then re-visit all the issues you posted? If they are still present in this release, move them to new topics with more details, else delete them.

Best thing would be if you could use Bugs:WebHome, easiest for all of us. Perhaps just use it as TWikiGuest if you haven't hand any luck bringing your login to work still?

-- SteffenPoulsen - 09 Feb 2006

It is currently a painful process for all of us. Once we fix the Dakar documentation model it will be possibly to update the docs in the TWiki web. (See DakarDocumentationModelIsBroken.)

-- PeterThoeny - 09 Feb 2006

Got it. I'll post separate topics after upgrade. Some of these are so minor, I feel stupid posting a separate topic for each one. (Even more stupid than piling it all in here!)

I tried again to register at develop.twiki.org and never received my email confirmation after registration. It's not being spam-junked, and I tested the address (twikimgr2@araPLEASENOSPAM.com this time) and it works.

-- PabloCaskey - 10 Feb 2006

Please use your twiki.org account on develop.twiki.org, do not register at develop.twiki.org.

-- PeterThoeny - 10 Feb 2006

I just tried that, yet again, and it still doesn't work. We're going in circles, here. Here's a copy of this issue from up above.

Development Site Bug: Your devel site clearly says, "Do not register here at develop.twiki.org, use your twiki.org account to login." However, my twiki.org account does not work. I have verified my password is correct. So I will just post my info here.

• I don't understand why this would not work. Feel free to register at develop again, registration process should work now. -- SteffenPoulsen - 31 Jan 2006
• Again? I never registered at develop, because of the highlighted giant yellow warning not to. I'll ignore that and register in a bit. -- PabloCaskey - 02 Feb 2006
• This failed for me but I'm trying again. -- PabloCaskey - 08 Feb 2006
• No, no registration is needed on develop.twiki.org. The problem is that the password file is not synched in a timely manner from twiki.org to develop.twiki.org. Sven is doing that from time to time. He never documented where to sync it, so I can't help you. Please as SvenDowideit. -- PeterThoeny

-- PabloCaskey - 11 Feb 2006

Thanks, Peter. Sven must've done a sync, because now I'm in. I'll do my upgrade and then post new topics to Bugs:Webhome, after I return from a business trip in 3 weeks. I'll close this topic as answered.

-- PabloCaskey - 13 Feb 2006