Category: Administration

{syntax type="tiki" editor="plain"}
It would be lovely to set some new user defaults at
* Admin (home) > Login > User defaults, and/or
* Admin > Groups > (Edit a single group)

The ability to Subscribe/watch/monitor new users in the site or to that specific group, to specific Tiki objects.

Which tiki objects?: I would say, in this order:
# specific forums
# specific blogs
# specific calendars
# specific newsletters (ML: we can already subscribe groups to newsletters)
# specific wiki pages
# specific structures
# specific trackers
# specific categories
# new articles

This is specially useful for new users of the site, where they don't know yet how to subscribe to specific areas, etc. Very needed for educational scenarios, but I can see many other places where new users are a bit lost for some time while they learn how to use the Tiki site.

Related:
*[wish988|Forum: Let forum admins/moderators add groups and/or users as watching the forum]
*[tiki-index.php?page=Business%20Plans|Let small business start ups access collaborative sharing where the document being shared is not visible by anyone else]


Anywhere there is a watch eye, it should be possible for an admin to have group members watch this category

When I go to administer modules I recieve this error.

An error occured in a database query!
Context:
File tiki-admin_modules.php
Url tiki-admin_modules.php

Message:
You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT `contentId`, count(*) AS `future` FROM `tiki_programmed_

This problems started after I upgraded to 2.0. I do not know what any of this means and need some direction.
Thanks
Cindy

The admin menu does not appear on first login after fresh install of 1.10

On the Control Panels page there is a new remarksbox to encourage using the advanced mode switch.

{img fileId="2061" thumb="box"}

No matter how many times I moved the switch to advanced saving or not (Apply) it is not effective and back to the initial position.

The switch from the Preferences Filter is working fine.

Upgraded a test/development site from 1.9.9 to 1.10beta1. Trying to get ldap authentication working to an active directory server. After configuring for ldap auth to AD - with 'use tiki for admin auth' checked - now I cannot log in as the admin user. The AD server is taking a really long time to respond, it's at another location - so it always times out. Unfortunately the Tiki site seems to keep trying LDAP and timing out before it will check internally for the admin user. The net result... I'm currently locked out of my development/test Tiki site. LDAP times out and I can't get in as admin either.

All users with permission tiki_p_search active can admin.

In 3.2, one can create a personal page in MyTiki and use an Avatar (I see from the Community it wasn't always available & I appreciate the feature), but I would like an Administrative feature that could turn these off while still allowing users to access their Preference Screen, especially for changing their password and email address.

User pages and avatars could take up a great deal of space if there are a lot of users. I'd like to turn off the ability of users to have user-pages and avatars. If there's a way to do that now, please let me know, because I've looked everywhere for a way to do that (and there's a note not to edit templates unless you really know what you're doing and I somewhat know, but I'm afraid of creating a problem).

Currently, an administrator of a Tikiwiki installation has to hunt for upgrades, updates, and security related information of his installation. It is often cumbersome and sometimes dangerous, think of the delay in fixing a crucial vulnerability, it has happened elsewhere before. It might also be nice to know that ppl are using current and feature complete software.

When you choose "home Page" on left menu, and you have configured articles like your home, you are not redirected correctly.


I don't have a developer account to CVS. I'm working on 1.9 cvs.
rogeliotg

Dear all,

I'm currently working with RR plugins in [https://wikispiral.org/tiki-index.php?page=Statistics|statistics pages] and very regularly changing those, upgrading the formulas / contents. This makes me validate plugins really really often (say, 5 times per 10 min), and even if the admin plugin validation page is useful, it still slows my work down a great deal, especially when I have to edit 5-6 times a plugin in order to correct its outputs.

Discussing with Xavi he pointed me out that autovalidation is a security problem, as some plugins can inject malicious code. Of this I'm plainly conscient, but it would still be a good option for some usercases to have an autovalidate option, reserved for admins or other special groups. The top option would be to have it only for some chosen plugins.

... I guess that CMS admins aren't there to inject malicious code ;), and honestly, I NEVER read the plugin validation text when I have been writing it (plugin HTML, plugin redirect, plugin RR)... Just validating it, and testing it before putting it on our main server, when its arguments might harm something.

An other option to my usercase would be to have plugin aliases without plugin validation reserved to admins.

Either case, this option might really help !

Joël

When doing administration in the wiki, for instance, in configuring menus, if you want to change permissions, you have to edit each item one at a time.

We are working on some pages, their names being regularly changed, thus their links.

It might be great if it would be possible to have an easy access to pages via their page_ref_id. I can list the page_ref_id in tiki's listpages, but when I use it to build a (more permanent) link, this doesn't work.

For instance it might be, in /tiki-listpages.php, when you use the option show page ID, to have links to wikipages by clicking on their page_ref_id (currently it's the same link as for the page name).

Also, when I do it manually editing the link, like this:
[https://wikispiral.org/tiki-index.php?page_ref_id=155] (the page 155 exists), it gives me it's 404ing.

When I put the page with an alias in a structure, then appears the page ref id, and the number here is different that the one in listpages ???

Is there something I missed ?

It would be useful to extract all permissions of File Galleries or Wiki pages or Forums, etc

This would provide a way for admins to know who actually has access to what.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

hi all,

I've spotted a bug on the forums.

===Here is a case scenario~hs~:===
* Lets say that I have a forum thread in forumId=1 which is constituted of one original message and 4 answers
* and I'm moving it (as admin) to (as an example) forumId=2,
* then I end up with being only able to see the original post (which created the thread) and the last answer

===Note=== that if I move it back to its original location (in this case forumId=1), then I can see the full thread (original post + the 4 answers).

===I did some research:===
When I'm going in the data-base table "tiki-comments", the only difference I can see between the thread being in the 2 different locations (forumId=1 and forumId=2) is the number in the "object" column. This column looks to be used for indicating to which forumId the message belong to. So, if I'm changing the number of this "object" column to the relevant forumId number, then it makes it working as expected (ie: showing all the messages in the thread).

===My conclusion:=== it looks like there is then a bug in the function used to move one thread from a forumID=x to a forumID=y, which somehow does not handle correctly the changes needed in the "object" column of the "tiki-comments" table.

Hope that helps.

I have installed TikiWiki 3rc1 on an IIS (Windows Server 2003) installation with PHP 5 and MySQL. This is a root-level installation. For some reason having to change PATH_TRANSLATED to SCRIPT_FILENAME in line 31 of lib/setup/tikisetup.class.php, which if I don't do I get errors relating to directories not existing and the site not loading at all; this is not the purpose of the support request.

Once I make these tweaks, as well as after setting the tweaks identified in tiki-filter-base.php (that is, changing forward slashes to double-backslashes in quotes), I get the site up and running. ***But*** on administration pages, the buttons created by lib/smarty_tiki/function.button.php (such as "CLEAR CACHE" on the Modules admin page) don't seem to work when accessing the site from Safari or Firefox (Internet Explorer works fine for this).

Instead, in Safari, the clicking on the button will load the script name where the domain name is supposed to go; if my site was on http://site.com/somescript.php?something, it would load http://otherscript.php?something. I don't have my machine handy, so I can't get the Firefox results up at the moment, but IIRC they involved the format http://site.com/\/otherscript.php?something (with a backslash and forward-slash inserted).

A Linux installation of TW3 works fine in Safari and Firefox, so my guess is that it's an IIS issue that has something to do with backslashes and root-directory determination, but I'm somewhat clueless here. I've examined lib/smarty_tiki/block.self_link.php and some tweaking there has produced no viable results.

Also note that this goes away when TikiWiki 3 is placed into a non-root directory; it only affects a root installation at /, rather than at a server subdirectory.

I have two site that I've upgraded from Tiki 5.3 to Tiki 6 and on both sites, clear cache function is no longer working since the upgrade. When I open the 'Exterminator of cached content' window, thit indicates that there are no cached files. I have confirmed via FTP that there are many cached files. Also, when I select 'clear cache', there is no effect on the cached files.

When I click the delete icon for a user in the list at tiki-adminusers.php, a modal dialog displays that says only "null". But the user isn't deleted.

{syntax type="tiki" editor="plain"}
"Delete unused images" in the Admin panels does not affect images uploaded via the WYSIWYG editor, and the user interface does not provide any other means of deleting ANY images from the FCKeditor upload directory.

I do Admin > Wiki > No Tab (i.e., tiki-admin.php?page=wiki) , go down to the Wiki Watch section, I see:

---
Wiki watch Help
Information Feature disabled. Enable now.
---

I click on __Enable now__.

I end up at tiki-admin.php?page=features

I go back to Admin > Wiki > No Tab, and it still says:

---
Wiki watch Help
Information Feature disabled. Enable now.
---

And if I go to a wiki page, I don't see the eye icon for enabling watches.

I just downloaded Tiki 4 on my local Windows machine, and tried to install it.

Everything seems to go fine, except that when I log on as admin for the first time, the system asks me to change the password. I enter the old password (admin), and then 1234 twice, and then hit Change.

But nothing happens! I am stuck at the exact same screen for changing the password.

I have tested this with Firefox and IE, and I get the same behaviour on both.

This essentially means that I cannot log in as admin and change the configuration of the site.

We recently upgraded from Tiki-4.X to Tiki-5.X. We are running Tiki-5.3.

There seems to be a bug when trying to modify a user under the administration page (tiki-adminusers.php). When trying to click on a user, one is asked to confirm (which is a new workflow) and then taken to the Edit User page. However, when one tries to modify something (e.g. password, email address), you are asked to confirm again, but it never completes.

Here is a set of detailed steps to reproduce the problem:
# Go to admin users (tiki-adminusers.php)
# Click on user "demo"
# Click "Click here to confirm your action"
# Change email address from demo@demo.com to demo@demo.org
# Click "Save"
# Click "Click here to confirm your action"
* Nothing happens. The page address is "tiki-adminusers.php#", but it never changes from the confirm action page. "Go Back" does not work, but "Return to Home Page" does.

((doc:CDN)) helps with performance

However, a side effect is that cdn domain can also be visited. It's not linked anywhare so it should stay secret

If you try to login, you'll get: "You have to enable cookies to be able to login to this site"

Currently, there are four preference filters available in the Control Panel interfaces: "Basic", "Advanced", "Experimental" and "Unavailable".

As a user new to Tiki, I have on several occasions noted features that looked interesting, but which I have not enabled as I have subsequently found it is planned to deprecate them. In some cases this was obvious (e.g. a 'warning' icon with the deprecation message on hover next to the feature checkbox), in others it wasn't (i.e. I only found out about it from doc.t.o or related places).

On the assumption that it will help with planned deprecations if new installations don't enable and start using deprecated features, I would propose that a "Deprecated" preference filter be added, that relevant controls be assigned to it, and that it be disabled by default in new installations.

I understand the criteria for such might be controversial (indeed, I hope I'm not reigniting a heated discussion by posting this!) and so would understand if this is WONTFIXED. I also recognise that it is less appropriate for a new user to suggest criteria here than for those that have had Tiki installations for some time and/or are directly involved in development, which is why I haven't listed any in this initial report.