Category: Admin Interface (UI)

Sometimes, we want people to participate to one wiki page, to access their user tracker to update personal information or access a ((workspace))

Right now, we need to

#create a user
#create a group
#assign user to the group
#give permissions to group ( in general or for a specific item)
#inform this person, typically by email, on how to access this page


Instead, I would want to
#add an email
#pick the permissions this person has
#any limitations (works x times, or for x days/weeks)
#an optional message

And the system should send a 1-click login email (an email with a link in it which is unique / very difficult to guess).

Whoever clicks that link
*Would be authenticated with the appropriate permissions and according to the limitations.


Related:
Expiry date for group membership
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1071

Somewhat related:
Send welcome email (by admin to new user or user that has not connected in a while)
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1016

I would like a way to invite people to come to a Tiki site after I have added their login. (different of the use where people self-register)

Right now, I simulate a lost password message (which I customize).

Maybe this could become a new feature available to admins when

1- after a successful user creation at tiki-adminusers.php
2- when administering a user account
3- from : tiki-adminusers.php with the batch command to send to many new users.

The system would send an email with a one-click login and be sent to the user tracker
tiki-view_tracker_item.php?view=+user

Person who triggers this email alert should be in BCC. (to have a trace). Even better would be to have this logged somewhere but this could be for phase 2.

We could have a new mail template in templates/mail/welcome_message.tpl or in a wiki page (better!)


What do you think?

So I could show quick_edit module to users with tiki_p_edit

Related:
[wish1783|Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc)]

When defining a field in a mirrored Tracker, the Description of the field is not stored. This was in 2.0, and I'm told on IRC that mirrored trackers are not supported. But mirroring is an option in Admin>Trackers.

I looked today at http://info.tikiwiki.org/tiki-list_submissions.php and there are nearly 300 spam submissions there so far, and no way to delete them in groups. Maybe that's why nobody noticed my prior submission as info.tw.o editor from last month...

(the user need to be in info.tw.o Admin group in order to see the spam list. If your users is just in the info.tw.o_editors group, you'll see nothing but your own submissions if any.)

A text box to select the amount of rows to be listed would be welcome, and multiple checkboxes to select some or all, like with users, etc.

---
By the way, how can anonymous spammers post submissions to info.tw.o? They can't through http://info.tikiwiki.org/tiki-edit_submission.php (at least, nowadays)... Spam hole somewhere?

Our users keep adding large .ogg files in our files galleries and we have been asked to externalize theses files in a special download directory of the web server. Problem is that the admin screen of the files galleries doesn't have a DISPLACE section. You can set the option for the files to be added in an external directory, and the new ones are indeed placed into it, but the existing files stay in the database.

I have discovered that the *Image* galleries admin screen has this DISPLACE section but it will work only for the image galleries, no way to use it for the non image galleries.

Please increase the limit and make it multilingual

I upgraded my Tiki from 4 to 8. Perhaps it was premature to upgrade a busy Tiki with many users to Tiki8. Anyway, I found a few issues. I am not sure if they would be characterised as bugs, or just stuff that has not yet been implmented. Here are the issues:

(1) The login prompt kept floating around the screen, appearing and disappearing in random places at random times, so I went to Admin-Modules to try to fix it.

(2) The next issue, is that in Admin-Modules, the tabs do not work. Clicking on a tab does nothing. Fortunately, I can proceed by clicking on the "No-tabs" button. Good idea that.

(3) Editing the login module didnt seem to help. So I came up with a cunning plan: Delete the module and then add it back in again. In hindsight, that was a pretty risky thing to do in beta software.

(4) I deleted the login module, but now I cannot add it back in! According to the instruction text, new modules can be dragged from the "All Modules" tab. But this either doesnt work or has not yet been implemented.

My Tiki is at http://lockbox.seanbdurkin.id.au

Fact : with the module action_calendar the popup can't be reached.So it is impossible to access to the command buttons of the popup

Analysis : conflict or bad logical test between :
*the popup activation condition "on the date cell"
*"the need to let the popup opened or when the pointer remain over the popup"
*"sticky popup"

Same remarks as for the previous tracker about calendar feature.

After a new calendar is created, the create calendar form is still populated, and subsequent changes will edit the already created calendar instead of creating a new one. This behavior is not apparent to the user until the edit has taken place.

Ex.:
tiki-adminusers.php?group=Editors


It will make it easier to manage groups.

Admin -> General -> Navigation

It's very easy to add manually by editing templates/footer.tpl, it would be nicer to have the _uacct saved in the database with the rest of the settings. Upgrades would be easier for site admins.

Please see:
https://www.google.com/support/analytics/bin/answer.py?answer=55488

This would be similar to gmap.

Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=1177


Maybe this feature request could be even more generic to include easy ways to add other services and/or make it easy to use with open source apps like phpOpenTracker or phpMyVisites.

http://www.phpmyvisites.us also recommends putting the code just before /body>


Also, there should be a way to exclude certain or all groups from tracking. If I use 1 Tiki for a public website and and Intranet, I don't want my Intranet traffic to pollute my public site stats. I could just want anonymous users to be tracked.


Also, let's integrate more tightly with the new [http://www.google.com/analytics/GATCmigrationguide.pdf|ga.js] code so we can track downloaded files, and take advantage of other nice stats.

If I create a new group in tiki-admingroups.php, and want to add a user, I must go to tiki-adminusers.php

I should be able to add users to groups from tiki-admingroups.php, with a drop-down (if < 500 users) or a search username box (if users > 500) , or something like this...

Keep it optional - even activating something just to see, how you admin it!

Is there any reason this has to be this way?

Bugs & Wish list

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

In Opera and IE7 (didn't check yet in IE6), all sublevels of the Tiki Magic admin menu display all the time. Sublevels aren't top-level item sensitive as in Firefox.

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).

See video:

{FLASH(movie="tiki-download_item_attachment.php?attId=62",width=>876,height=>677,quality=>high)}{FLASH}

In Tiki 1.9.8.3, even if the feature is off, you can see references to trackback pings in tiki-view_blog.php , tiki-view_blog_post.php, tiki-edit_blog.php and tiki-blog_post.php

Proper feature checks for {$feature_blogposts_pings}, {$feature_trackbackpings} and if the feature is activated per blog should be done.

CSS... Themes...

Fact : when you submit "preview" for a new event, a great part of data are lost, there is no real preview, and when you return to creation most of optional data are lost.

Too many things don't function : the job is not ended.

Sometimes, first day of the week is Sunday, even if you set that to be Monday on Calendar settings.

This bug shows up for us (catalan interface, time zone "Europe Madrid (UTC+1)" when we have in tiki-admin.php?page=general, at preferecnes syntax:
"1.10 - $prefs.feature_foobar..."

When we swich this parameter to
"1.9 - $feature_foobar"

then fist day of the week in calendar is Monday, as expected

Right now, there's no way to resend either the email to the admin to validate a user or resend the email to the user to validate their email address. If either of those emails fail to happen or they get sent to "spam", the user cannot log in.

when you click on the polls icon on the Admin Home page, you are taken to the polls comments admin page instead of the polls admin page. User should not have to make an additional click to start work.

Tiki has a lot of features. But sometime, we have to hack it up with various things that we can't share back to the project.

So we want to modify Tiki, yet, keep upgrades easy.

It is already possible to add custom language strings.
It is possible to override Smarty .tpl files with our own
It will soon be possible to add custom CSS strings


It would be nice to have this for javascript as well.

A custom.js somewhere. If it can be kept in the database, it makes site migration and backup even easier

Or it could be in styles/*/custom.js


It would be nice to have the option of putting towards the top or towards the bottom. Maybe Site Identity custom areas already permit this?

Sometimes, we want to change a few language strings from the original Tiki. It could be because of regional or community expressions.

Currently, we need to change language.php and/or the template (tpl) files.

It would be better to have a custom language file which would override default text. (Like we do for tpl files). Therefore upgrades would be smoother.

Even better if we could edit this language file via the GUI.

Sometimes, users forget their usernames and end up creating duplicate accounts.

Here are two things which would help:
1- Users should be able to have a password reset/reminder while only knowing their email. __fixed in 1.10__

2- In tiki-adminusers.php, the search box should work for emails also (not just usernames) __fixed in 1.10__


Related: [tiki-view_tracker_item.php?itemId=1069]
Also, in 1.9.x, usernames are CaSe SenSitive. __fixed in 1.10__

TikiWiki often has drop-down menus with many choices.

Ex.: drop-down list of users, or wiki pages, etc

That is ok for a few hundred. But what if you have 300 000 users or 300 000 wiki pages?

There should be a setting where beyond a certain number, the drop-down become a search box.

We need to decide about ((tw:DefaultSettingsChanges)) in 1.10

Some of the new features are much better than previous ones (ex new diff engine). People upgrading their Tiki could conserve their setting. However, new installs should take advantage of the new features.

A note should be added in tiki-install.php This must be low maintenance for Tiki dev team.

I would like to have the templates include a comment line such as: <!--start template: tiki.tpl--> and a corresponding <!--end template: tiki.tpl-->. As a non-developer performing minor overrides and adaptations to the existing templates, this would greatly improve the time needed to locate the correct template to override for a certain page, as you could just go into the HTML source code and see which templates are involved in generating the page you are looking at.

This setting:
Contact Us
Contact Us (Anonymous)
here: tiki-admin.php?page=features

And this one:
Contact user:
tiki-admin.php?page=general

Plus, "Contact user" should be a drop-down menu with the user list


Should be added to a new admin tab "Contact us":
tiki-admin.php?page=contact_us

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

These settings:
Categories
Show Category Path
Show Category Objects
here: tiki-admin.php?page=features

And this one:
Ignore category viewing restrictions :
tiki-admin.php?page=search

Should be added to a new admin tab "category":
tiki-admin.php?page=category

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

This setting:
User Messages
here: tiki-admin.php?page=features

And these ones:
Users can opt-out internal messages:
Users accept internal messages by default:
Maximum mailbox size (messages, 0=unlimited):
Maximum mail archive size (messages, 0=unlimited):
Maximum sent box size (messages, 0=unlimited):
here: tiki-admin.php?page=login

Should be added to a new admin tab "Inter-user message":
tiki-admin.php?page=inter-user_message

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

tiki-admin.php?page=general
Use direct pagination links:
Maximum number of records in listings:

The two pagination settings should be together in a section "pagination". (on this page is OK)


Would be even better to move all to tiki-admin.php?page=pagination

As suggested by Nyloth at TikiFest Strasbourg,

1- "Sender Email" could be set by default to no-reply@domain.tld
2- It could be requested as part of the install script.

Many features don't work well until it's set (ex.: Inter-User message, registration with email validation, etc)

These settings:
Theme:
Slideshows theme:
here: tiki-admin.php?page=general

And theses ones:
Theme Control
General Layout options (all)
Edit Templates
Edit CSS
Tiki Template Viewing
Use Tabs
here: tiki-admin.php?page=features

And this one:
Reg. users can change theme:
here: tiki-admin.php?page=login

Should be added to a new admin tab "Theme & Layout":
tiki-admin.php?page=theme

IMHO, it is OK for options/settings to be in more than one admin panel, if relevant to both.

As the calculated size of the line, depends of the size of the panel (resizable) is wrong (too of some ... <unable to translate, in printing in french the length unit "point">).
Then the line is always too long of a few for the panel (words or half of words cut before splitting the line).

This makes the blog edition unusable in normal conditions because to edit a text we have to make horizontal scroll continuously.

Analysis : the calculation of the length of line written in text editors is always complex. Generally today there is no problem, but the system which is behind editors is very complex to take in account all display configurations.

(nota : For my own I had developed some years ago a draw system - for engineering, Computer Assisted Drawings - system for windows displaying HPGL2 language drawings with fonts conversion from HPGL2 fonts system to True type, then I know well in details the whole problem)

~~#F0C:__With this problem, I can't let use the tikiwiki 5.3 by my bloggers.__~~

So I have written a warning take care "sorry very difficult to use"

I have a problem, i dont know how fix it
In tiki4.2 in wiki pages (others doesn’t show this error) editor wysiwyg, does insert an image but it change the code with this code
{…}, (I know cos I saw it , in the html view)
But when I save it doesn’t recognize the image, If I return to the html editor and change the {…} With <…>, it works

Somebody can help me??
(:wink:)

tiki-admin.php?page=general

1- favicon box is limited to 32 characters. This is not enough for people using multiki.

2- When I try to change path to favicon, it doesn't save.

3- How do I deactivate this feature?

Shouldn't this feature be in Site identity?

Right now, it's a group permission (tiki_p_batch_upload_files) but if I give tiki_p_admin_file_galleries, it included tiki_p_batch_upload_files, which is not always what I want. (It adds clutter to the interface, when uploading a file)

It should be an option here:
tiki-admin.php?page=fgal

And maybe add a check to see if this is supported by the server (if easy)

on the features selection page there is a checkbox for each feature with its name next to it. In normal Web UIs a checkbox is next to a &lt;label&gt; tag which contains the text referring to the setting the checkbox controls. If you set up the name= and title= for both the input and the label then clicking that text automatically selects the checkbox.

This is not always implemented properly across the web but it is the way forms are supposed to be used and it is easy and no one ever complains about it. It increases the effective size of the checkbox and cements the relationship with the word.

On the features selection page, however, the text instead links to the tikiwiki.org descriptions of the features. This confused me and happened several times before I retaught myself to not click the words.

Calendar should be like the other elements in the menu

for exemple:
Calendar
view calendar
add an event (which means we need an URL for this)
admin calendar

Make it more consistent. The feature has a different name in admin wiki than on wiki pages.

Why do they look different?
tiki-browse_categories.php
tiki-admin_categories.php

If the user didn't change the value of the destination of the help system, it should be updated to what the default value is now.

Need to hunt down what all the previous values were (ex.: http://doc.tikiwiki.org/tiki-index.php?page=) and to update via sql

And for clean installs as well (of course)

However, if someone modified the default value, we don't touch.


Reminder to add a reset to default value in 3.0 (new admin panel should permit this)

The URL's for the help buttons are not being built correctly. Users are unable to get help during the initial setup.

Tested on 1.10.0b1. To reproduce:
After a fresh install go to the Administration:Administration page
Click on the General icon.
Click on the help icon at the top of Administration General
The help URL will use the local host name instead of doc.tikiwiki.org

Other notes:
Help shows enabled on the features page (apparently enabled by default)
All pages reached through tiki-admin.php seem to have this problem

Levels in tiki-assignpermission.php are confusing to the new tiki admins.

just like this ((text中文))

it can't be parsed correctly as a page referer.

{img src=images/code.png}%%% {CODE(wrap=>1)}
(7:48:16 PM) marclaport1: polom
(7:48:21 PM) ***marclaport1 has an idea
(7:48:31 PM) marclaport1: to make tiki easier to install
(7:48:34 PM) marclaport1: and safer
(7:50:54 PM) marclaport1: say I point to tiki-install.php
(7:51:07 PM) marclaport1: on a tiki which is already in existence
(7:51:27 PM) marclaport1: i get a choice of clean install (tiki.sql) with various profiles
(7:51:59 PM) marclaport1: or to upgrade (1.8.x_to_1.9.x.sql)
(7:52:20 PM) marclaport1: why offer a clean install unless db is empty?
(7:53:33 PM) marclaport1: so if tiki-install.php can only can the upgrade sql (which is designed to be run over & over again) tiki becomes safer
(7:54:55 PM) marclaport1: if the database exists, there should be a note the admin to use phpmyadmin to go and empty the database of create a new one for tiki
(8:00:29 PM) ***marclaport1 feels that must be something wrong with this idea, or else all the smart people in tiki would have though about it.
(8:03:38 PM) ***marclaport1 has the impression that most tiki devs don't use the web installer
(8:04:21 PM) marclaport1: ...
{CODE}

{THUMB(image=>img/wiki_up/Smarter_Tiki_install.jpg,)/}

I have several tikiwikis (v 3.0 beta 4) on the same domain. Both behind the same .htaccess protected directory. The goal was to setup a working instance of InterTiki between these two Tiki's.

By way of example
* Apache .htaccess limit: http://www.mydomain.com/p/
* Master e.g. http://www.mydomain.com/p/master
* Client e.g. http://www.mydomain.com/p/client

__BACKGROUND__
A few setup issues have been noted (these details have now been added to the InterTiki documentation). Most notably is correctly specifying the location of "/remote.php" for the above case. For our above example to following is req'd:
* host: http://www.mydomain.com
* path: /p/master/remote.php

On the master, I have successfully made contact using either the IP shown in the Apache logs, or by simply using "127.0.0.1" in this case.

Likewise (also added to InterTiki docs) there was some oddity related to order of events with how the server info was being plugged into MySQL tiki_preferences interlist table. I have not properly tracked this down so will not go into it further at this time.

Also of note (for another bug or support request) is that I am unable to get InterTiki on the master to log out anything.

__BUG/FEATURE REQUEST__
''Note: InterTiki operates as designed and is simply unable to get behind an Apache Basic Auth wall. However, hard-coding in setCredentials line for the XML_RPC_Client should work in this case but does not.''

After getting setup dialed in like above, the client received the following message:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 401 Authorization Required)''

Some digging into /lib/userlib.php finds the calls for setting up the XML_RPC_Client at lines (around) 228, 2812, 2831, 2860 and 2905. Looking into the XML_RPC_Client class in /lib/pear/xml/rpc.php shows that there exists a setCredentials($username, $password) method. The setCredentials method exists to allow for RPC calls to get through Basic Apache Authentication.

__Possible Bug__
I went ahead and modified the clients (and eventually the master's) /lib/userlib.php in the above locations with a simple addition of:
$client->setCredentials("myApacheUsername", "myPassword");

This time, when logging in from the client, the response was:
''XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.1 302 Moved Temporarily)''

And with that I am stuck. It seems like (as a workaround hack for the time being) the ability is there in the XML_RPC_Client methods to get through an Apache Basic Auth, but the return code is weird at best.

__Possible Actions__
#Ignore -- Explicity note that InterTiki masters/clients must not exist behind Basic Auth walls.
#Investigate why a hacked userlib.php returns a 302 code and determine if this is as designed or a bug.
#Possibly add a basic username/password entry field in the client administration page for driving the setCredentials method.

The tabs in the administrative interface use an onclick to run some AJAX code to change the interface. The problem is that they don't work in Chrome 17. They seem to work fine in Chrome 16.

More strangely, the method signatures of the tikitabs function actually appears quite different between the two browsers.

On Chrome 17 it is


function tikitabs(focus,max,ini) {
var didit = false, didone = false;
if (!ini) {
ini = 1;
}...

function tikitabs( focus, tabElement) {

The problem appears to be that the ini variable is not set, so it we set the ini to 1, then it skips down all the way to if (didone && ...) which gets bypassed, and we exit right away.

Why do you have different code for different versions of the same browser?

in debug mode (eg. when debugging ldap logins) many log entries are created at the same time so sorting by time is not sufficient to get the entries in their real order. Sorting by ID is better then.

Unfortunately sorting by ID leads to an unexpected result.

Looking at the code the problem can be fixed easily: The problem is that two tables are being joined (actionlog and actionlog_conf) and sorting by ID leads to sorting by actionlog_conf.id instead of actionlog.actionID.

Both needs to be fixed - in the SQL query the table for sorting must be added in the sort statement, in the template the columnname must be changed from Id to ActionId.

See patch.

When groups are synchronised with a big LDAP organisation many empty groups may end up in Tikiwiki.

This enhancement / patch adds an option to let the administrator of a tikiwiki instance decide whether during synchronisation of groups only the user assignments to existing groups will be done or if non-existent groups will be created in tikiwiki.

The default behaviour - as of now - is that when a LDAP user logs in all the groups he belongs to will be created in tikiwiki and he is being added as a member of these groups.

This enhancement adds the preference "ldap_create_groups_tiki" which is "y" by default - which corresponds to the current behaviour.

If "ldap_create_groups_tiki" is set to "n" and a LDAP user logs in the group synchronisation process will silently ignore groups that exist in LDAP but not in tikiwiki. Existing groups will be synced, though.

Fatal error: Call to a member function toArray() on a non-object in /var/www/rtsdata/apps/WiP/tiki/tiki-8.3/lib/prefslib.php on line 243

New install, following "Tiki for Smarties" examples,
Install is successful. No problems.
Log in as admin. ... good.
change password ... good.
go to Admin page from menu ... good.
select "general" ... fatal error.

try ..."Getting started using Profiles" ... same error.

!!!After upgrade the admin can't login anymore

!!!The failure sequence :
#Create a new directory or repository for the new version
#Update with your files (particularly images or icons)
#Site enable (example a sub-domain) on Apache
#Copy the database on new name
#Install manually .htaccess (compare and insert your valid options )
#Update "local.php"
#run <your new domain>/tiki-install.php. Goto the end (note an error occurs if your say at the end "run tiki" without locking or not because tiki-setup tries to re-open a session already automatically opened by installer). You just launch again (default tiki-index)
#~~#F00:__Try to login as admin : You will be rejected as wrong password __~~

!!Analysis - many possible reasons :
There are a lot of reasons to be in this situations. So to be successful a lot of conditions must be satisfied :

#If your new version uses the same current domain (after upgrade for my own I defines the same "servername" as current one and then keep the other when a particular name containng the version :
- The Cookies of session will try to reconnect an older version and a trace shows that the password is not the one you have given (generally empty). So the cookies of the site name must be cleared on your navigator

#The temp files or session table contain too wrong data : they must be cleared on server for your current copy (SVN update case)

#Your admin record in user_user record contains sessions data : they create a conflict which makes crash your login

#Be careful of the fact that you can have an open session in your navigator with the same site (sometimes we uses a lot of tab management which can create this : on firefox use showcase and search to clear your old sessions

#Generally avoid these problem is sufficient but at the end you will be prompt to update your password (as for the first login as admin with password admin). This can fail for the following reason : if the .htaccess is not set or modrewrite not well operational the <site name> will include the "port" used by your server. If your NAT translates the port address (i.e. 80-> 4397) you will get the following url <site>:4397/.... which fails

It is sure that if you use only one site close everything and upgrade you will get the minimum of problems but you will get someone anywhere.


!!~~#099:This situation is common and complex for whom have to manage product and data migration from one version (or several) of tiki to a new one.~~
It is not seen generally by developers, because it is not at all their common upgrade process nor test.