Category: Administration

When trying to reset a password for a user you can't click the confirm button on the confirm page. Click the confirm to submit the form gives the javascript error "uncaught TypeError: Property 'submit' of object #<an HTMLFormElement> is not a function" in chrome. This is caused by one of the inputs in the form being named submit. So the function the confirm button calls "javascript:document.forms['confirm'].submit();" is calling the submit input element instead of the submit method of the form. To fix this change the name of the submit button in tiki-adminusers.tpl from "submit" to something else.

In a Tiki 11 svn installation an upgrade notice is shown, which suggest to switch from Tiki 11.0 to Tiki 11.1 or do a major upgrade to Tiki 9.0 as follows:

-+Version 11.0 is no longer supported. A minor upgrade to 11.1 is required.+-
-+Version 11.1 is still supported. However, a major upgrade to 9.0 is available.+-

The computation and suggestion of the major upgrade version number is not correct. I'm not sure whether this problem is already fixed in a later version or not.

Star name was forgotten in code at the last release:
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/branches/11.x/lib/setup/twversion.class.php#l31

If this is useful, it should be indicated in ((Releasing)). If not useful, it should be removed from the code.

Please see: ((Upgrade script))

There was a revamp of ((URL Rewriting Revamp)) in Tiki11, but after the revamp, we found edge cases.

Adding them to logs would be easy and make sure we find anything left.

Also, things like http://dev.tiki.org/abcdef.php should
* offer a nice error message
* be logged so we know about broken links
* Offer a search box (if search is activated) with content of the URL in it?

On a fresh install at Admin -> Log in I enable "Users can register", I uncheck "Validate new user registrations by email" and I set an URL for the field:"URL the user is redirected to after account validation"

So validation is not done using the email link but is done right away after validating the register form.

I create a wiki page: mysuccesspage and tried with page name, a relative path tiki-index.pgp?page= mysuccesspage and an absolute path: http://mysite.com/tiki-index.pgp?page= mysuccesspage

I’m redirected to the default registration page.

I enabled back "Validate new user registrations by email"to check and it worked.

----

I created an instance to demonstrate:
Setting are good : http://bsfez-11581-6095.show.tikiwiki.org/tiki-admin.php?page=login
Success page exist : http://bsfez-11581-6095.show.tikiwiki.org/tiki-index.php?page=success

The goal is to have a USB key version of Tiki.

Possible uses:
#Easy testing on a Windows desktop
#Have a backup of your Tiki on your MP3 player
#etc


Possible partners:
http://www.easyphp.org/
http://portableapps.com/apps/development/xampp
http://www.uniformserver.com/

{syntax type="tiki" editor="plain"}
With a home page from an imported Mediawiki at tiki-index.php?page=Main+Page putting either that, or that with http://192.168.2.6/tiki-index.php?page=Main+Page or that with 192.168.2.6/tiki-index.php?page=Main+Page has no effect at all. The documentation for this feature claims that any entry here should override the Use tiki feature as homepage scroll selection, but that remains in control here, and its selection is what is shown.

So either there's a way to get this to work and the documentation's incomplete. Or the feature is broken. If the second, what would the most direct work-around be?

This is a useful feature for an Intranet. However it's not so good if the emails are not to be disclosed. I think some code has been done in 1.10 for this. However, the feature probably needs more work.

CVS update of 1.10 at 04:27 UTC

After the admin user "Admin" enables the poll feature, they are unable to access the poll administration page.

To reproduce:
1. Log in as admin
2. Enable Polls checkbox via the Features-->Admin Page
3. Click on "polls" in left-hand admin menu
4. Permission is refused.

Another way to reproduce
1. Log in as "Admin"
2. Click on "Admin Home" in the left hand menu
3. Click on the "Polls" Icon.
4. User is taken to ~/tiki-admin.php?page=polls, which is not Polls Admin, but Polls comment admin.
5. Click on link at top of page: "To add/remove polls, look for "Polls" under "Admin" on the application menu, or Click Here."
6. URL when hovering is ~/tiki-admin_polls.php
7. Receive permission refused error.

So we know which admin created a login...


We currently have a log entry when a user is assigned to a group, but not when he is unassigned.

Also, we have:
unassigned perm tiki_p_broadcast from group admin

but not:
assigned perm tiki_p_broadcast from group admin



Maybe adding failed login attempts would be good too...

Using a Tiki at tiki-admin.php?page=login you can set the user to receive an email to validate its account or as welcome.
This work fine.

You can also use a tracker plugin in a wiki page to fill a tracker item and set that this include a registration.
However the user then doesn't receive any email or validation email.

There is a parameter "Validate users" (y/n) that override only part of the process:
"Here one can overrule the default validate users by e-mail preference"

Setting to Y, users are validated automatically.
They don't receive the registration validation email or anything else (all process is overruled) .

Setting to N, users are not validated.
But, they also don't receive the registration validation email or anything else (all process is overruled) .

User have no idea maintenance is underway when they are editing a page.
Admin (or an automated task) have no idea if users are working on a page before staring a disrupting maintenance task.

This is a pain, annoying and really bad for Tiki when after several minutes editing a page on save the user see the maintenance screen.

Due to the way Tiki security check work, reloading the page doesn't work.
{img fileId="1639" thumb="box"}

#__We need this as manual option with "threshold" "time of maintenance" and "message" parameters.__
## This would initiate an alert with a "message" displayed nn minutes (threshold) before the "time of maintenance" activated when a user login
## Admin should receive a warning users are connected before closing a Tiki site
# As automatic option when using tools like Tiki Manager, php console.php or vcs:update
## Warn the user an update will start
## Warn the admin users are connected
## Postpone a process if a user is connected (for big site with heavy indexes the I:r operation could be postponed as log as users are connected or eventually forced "-f")
## ...

Tiki Wiki CMS Groupware v16.0svn (SVN) "Situla"
Last update from SVN (16.0svn): Monday 31 October 2016 12:39:28 GMT-0100- REV 60095

Users register to the site autonomously.
Registration is set to validation by Administrator.
Member of group Admins cannot validate the users - neither by the validation link in the notification email, nor by logging in and trying manual validation on-site.

So no new users possible at this site with registation moderation.
This is a crucial bug.

Update 6 Nov 2016: it was reportedt, that 'creation of users' is broken at all in current Tiki16.

Hello, I'm using tikiwiki 1.9.7 and we have several virtual wikis installed at present. The problem is that the groups we get in the admin section are the groups from the virtual wiki that last made a modification to its groups. So sometimes, on the virtual wiki on which I'm admin, I see the groups of another virtual wiki, and not my own groups. The same happens for the categories. (This might also affect other domains that I haven't identified).

What seems to be happening, is that once there is a modification to groups in one of the virtual wikis, the cache is updated with that content and it seems that all virtual wikis must share the same cache... The exact cause would have to be investigated properlly as this is only an assumption deduced from the symptoms. What I do know, is that in the wiki admin section, I made sure that the cache was set to 0 (no cache), and that the individual cache checkbox was unchecked (no sure what this is supposed to do). So if this is a cache problem, it apparently occurs with a cache that you have no choice of using. Also, it can't be a browser's cache because I never go to the other virutal wikis, so there is no reason these other groups should appear in my browser suddenly.

When I do go in the groups section, the right groups are listed on the page in the section 'list of existing groups' , but in the include box of the 'add new group' section, the groups are wrong.

Well that's about it, I hope this is enough information to solve this bug. Let me know if you need specific information I haven't included in this report.

Kreugen

Using 1.9.cvs

Viewing this page as admin:
http://www.moviments.net/drecerca/tiki-admin_calendars.php

I get this warning 10 times on top of the page:
{CODE()}
Warning: in_array() [function.in-array]: Wrong datatype for second argument in /home/httpd/tiki19/tiki-admin_calendars.php on line 67
{CODE}

The only calendar defined (default) is public.
^
ID nom loc participants cat idm prio subscripció perso
1 Public n n n n n n n permisos elimina editar
^

Bug is not (apparently) important, but looks awful for newbies installing tiki and trying calendars...

---
Confirmed using 1.9cvs from July 9th 2007

To reproduce:

1) Log in as admin.
2) Go to Groups Admin
3) Assign tiki_p_search permissions to a group with no administrative ("tiki" type) permissions.
4) When page refreshes, you will see that all Admin permissions have been assigned to the group, and the Administrative links have been added to the Application Menu module.
---
Confirmed by dthacker

{THUMB(id=44, url="tiki-browse_image.php?imageId=44")}{THUMB}

A user belonging to this group also gets admin menu after logging in.

When the system (in this case was a Linux box) runs out of disk space, a Tiki user cannot login. Basically, the user is sent back to the home page. In other words, it looks like the user has authenticated, but is not logged in. So it looks like a PHP session issue. It could well be.

If the user enters a wrong password, a wrong password message is seen.

It would be nice if Tiki could detect that the disk space is low and alert admin users, especially during install. Low priority of course, but still nice to have.

MoinMoin example:
{THUMB(id=29, url="tiki-browse_image.php?imageId=29")}{THUMB}

https://doc.tiki.org/tiki-admin.php?page=wiki is broken:
{CODE()}Fatal error rendering template resource tiki.tpl
TypeError: Cannot access offset of type string on string in /home/tiki-doc/public_html/temp/templates_c/en_social^ea0943f75a262d8be544059ae17e04e9602d1469_0.file.header.tpl.php:65
Stack trace:
#0 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_64ff5e10934248_92322649()
#1 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()
#2 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render()
#3 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render()
#4 /home/tiki-doc/public_html/temp/templates_c/en_social^0c780eb23ca96bccad634bcfe8b1582ea34cbefc_0.file.layout_view.tpl.php(40): Smarty_Internal_Template->_subTemplateRender()
#5 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_64ff5e1268df80_55684014()
#6 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()
#7 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render()
#8 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(386): Smarty_Internal_Template->render()
#9 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_inheritance.php(116): Smarty_Internal_Template->_subTemplateRender()
#10 /home/tiki-doc/public_html/temp/templates_c/en_social^a242164352b905110d239d535f6a556a33d17bf9_0.file.tiki.tpl.php(38): Smarty_Internal_Runtime_Inheritance->endChild()
#11 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_64ff5e121411a2_61382528()
#12 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode()
#13 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render()
#14 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(238): Smarty_Internal_Template->render()
#15 /home/tiki-doc/public_html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute()
#16 /home/tiki-doc/public_html/lib/init/smarty.php(492): Smarty_Internal_TemplateBase->display()
#17 /home/tiki-doc/public_html/tiki-admin.php(515): Smarty_Tiki->display()
#18 {main}
{CODE}

Hi -

I am using the latest tiki-HEAD and something is wrong with wiki display. The tiki-showpage.tpl has a list of options to show categories on the wiki page, such as $feature_categorypath, $feature_categories, and $is_categorized

It appears from debug that $is_categorized is not set on my pages despite the fact that the pages are, in fact, categorized. Any ideas?

{syntax type="tiki" editor="plain"}
On a Tiki23, I can activate the "Revision approval" feature for Wiki Pages at -+tiki-admin.php?page=wiki#contentadmin_wiki-3+-
Admin => Wiki page => Flagged Revision => Revision approval

This function then requires the user to select the categories that will be governed by this feature using the field "Revision approval categories".

This is workable if you have a few categories (like 10 or 20). However, if you have many categories and subcategories, it becomes very complicated and hard to understand how to manage them.

To add to the confusion, there is an "invisible" limit on the number of categories that will be displayed. By default, you will see only 50 category results because of the setting:
Look&Feel => Navigation => Limits => Maximum number of records in listings: 50

It is very hard to understand why you don't see all the categories if you are not a super power user.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

On a Tiki24, when I enable admin=>Genral=>Navigation=>Close site only if I'm logged as admin I can see the site. Anonymous trying to reach the site get a WSoD.

This is the error in my PHP log.
I can't reproduce on a show instance.

{CODE()}
Oct 12 20:23:41 server001 php: PHP Fatal error: Uncaught Error: Call to undefined function getcookie() in /home/tsaharoniki/public_html/lib/tikiaccesslib.php:362
Oct 12 20:23:41 server001 php: Stack trace:
Oct 12 20:23:41 server001 php: #0 /home/tsaharoniki/public_html/lib/tikiaccesslib.php(312): TikiAccessLib->retrieveTicketFromCookie()
Oct 12 20:23:41 server001 php: #1 /home/tsaharoniki/public_html/lib/tikiaccesslib.php(1507): TikiAccessLib->setTicket()
Oct 12 20:23:41 server001 php: #2 /home/tsaharoniki/public_html/lib/setup/site_closed.php(19): TikiAccessLib->showSiteClosed()
Oct 12 20:23:41 server001 php: #3 /home/tsaharoniki/public_html/tiki-setup.php(88): require_once('/home/tsaharoni...')
Oct 12 20:23:41 server001 php: #4 /home/tsaharoniki/public_html/tiki-register.php(24): require_once('/home/tsaharoni...')
Oct 12 20:23:41 server001 php: #5 {main}
Oct 12 20:23:41 server001 php: thrown in /home/tsaharoniki/public_html/lib/tikiaccesslib.php on line 362
{CODE}

On a Tiki23 I set login to use user tracker information and a corresponding tracker.
User can register and they are assigned to group "Registered".

My use case is that when registering from a specific page the user should be assigned to a specific group.
The group "Mygroup" with the option "User can assign himself or herself to the group" to y (enable)

For this I use a tracker plugin and set it like this : registration="y" chosenGroup="Mygroup" validateusers="y"

The user using this tracker plugin will be assigned to registered no matter what.

Check the instance.

---

In the html I see a hidden input to assign Registered to the variable chosenGroup
{img fileId="1681" thumb="box"}

I tried to hard coded the value (<input type="hidden" name="chosenGroup" value="Mygroup">) at register-groupchoice.tpl to test but it didn't work.

You can get to help easily enough, but it's kind of hard to find the "wishlist" page.