Category: Feature request

After deleting spam, we can ((doc:Ban)) users but this should be easier/faster.


Ex.: after deleting a comment or rollbacking a wiki revision, have a link to ban the user.

Or maybe a "ban user" link from tiki-adminusers.php

Add empty lines after each section of records, not just bold text for the first entry of the new section of records as it is nowadays.

Check if there is an easy way to differentiate in the daily reports changes made in general objects and changes made in objects created by the user.

"htmlwrap() is a function which wraps HTML by breaking long words and preventing them from damaging your layout. This function will NOT insert <br /> tags every "width" characters as in the PHP wordwrap() function. HTML wraps automatically, so this function only ensures wrapping at $width characters is possible. Use in places where a page will accept user input in order to create HTML output like in forums or blog comments.

This function will not insert line breaks within HTML tags or HTML entities such as  . It treats all HTML entities as single characters, when taking them into account for string length. It will also attempt to find logical line-break insertion points (like after periods or slashes) before inserting breaks at $width characters."

http://www.greywyvern.com/code/php/htmlwrap

Discussed on wiki pages:
* ((Screencast))
* ((Copy-Pasting an image))

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.

{syntax type="tiki" editor="plain"}
Wiki plugins, like ((doc:PluginBigBlueButton)), you can have the situation where the cached version of the page reports "Last time we checked, the room you requested did not exist.", but since, it has been created, and this prevent people from joining the conference.

So in the plugin code, you should be able to override the wiki page cache setting.

{syntax type="tiki" editor="plain"}
Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

Sometimes, you want to show a module just for Registered, but not Admins. So a notgroups param would be nice.

This idea is from Bernard Sfez on the Dev mailing list.

I am referencing forum post: https://tiki.org/tiki-view_forum_thread.php?comments_parentId=43682&topics_offset=1

I would like the ability for users in child domains to access the TikiWiki site the same way users in the parent site are able to access it. According to the forum post, "Tiki is not currently capable of authenticating against multiple domains (or multiple LDAP servers)" and "The code could be modified to search, say, the global catalog for the user's DN and then authenticate against the corresponding domain, but this would be custom coding"

I would like an option to specify multiple domains, or a custom code I could use to search the global catalog for the user's DN.

Basically I want all of my users in all of my offices to access the Tiki site. Not just the home office users.

We already have categories, etc.

((doc:Edit CSS))
((doc:Edit Templates))

Please see: ((Extendable meta-data for all features))

Currently I can turn the display of page names on or off in the admin panel.

I would like to hide the page name on some pages but not all.

Thus a per page override would be nice, similar to the per page override of contributors display.

Thank you,

Problem:
Some changes in Tiki code (especially the parser) between versions cause slight changes of behavior. Devs have no comprehensive way to test the result of a change on a large data set.

We have a large data set with all *.tiki.org sites.

Similar to ((tw:Pre-Dogfood servers)), we could have a script which checks the HTML output for all wiki pages for a given version, and compare this to another version.

And thus, we can check if this is a desired behavior.

The HTML entities change in Tiki9 would be a great 1st test of this. It would have been nice to have it for UTF-8 changes in Tiki5 as well...

This should be done as part of the script for ((tw:Pre-Dogfood servers)) so we have daily reports on issues. (and we know that it's the same data)

Every time a link is clicked, add the keywords of the search result in the index...

See also: ((Machine Learning))

When nested divs (or other nested plugins of equal name) need to be edited, the edit-plugin-window, does not detect the plugins beginning and ending correctly. Eg:
{CODE()}1. {DIV()}
2. {DIV()}want to edit the nested plugin{DIV}
3. {DIV}{CODE}

If your mouse is within the "want to edit the nested plugin" text and you select the plugin-type because you want to edit using the gui (usefull if the text is quite long), it will pop-up the gui with the text:

~np~{DIV()}want to edit the nested plugin~/np~

Thus it detected the ending of the plugin which started at line 1, to end in line 2, which is not correct. Also, when the mouse is within a nested plugin, the gui should detect the beginning of the plugin in line 2, instead of line 1.

Hope this make sense...quite an annoying behaviour.

It would be nice if it was possible to enable something like a syntax highlighting/coloring when in edit mode, such that plugins are easily detected or that layout is also colored. Wouldn't a tikiwiki syntax highligher be cool! Or is that already available? :)

Say I have a ((doc:TrackerList)) report: I want to edit several items, I would like the whole report to become editable with a single save button

Say I have a desktop spreadsheet file. I can copy-paste this to Tiki spreadsheet and it makes it fun & fast to move data to Tiki. (It's also easy to export to .csv to re-use in the desktop spreadsheet).

But what if I want my info in a tracker?

((doc:PluginTrackerList)) has displaysheet=y which displays in spreadsheet view. This is nice but we'd need to be able to edit existing records, and easily add records.

{syntax type="tiki" editor="plain"}
I looked if something like this has been reported previously, but didn't find something that completely fits, so I post this and apologize if I missed something.

Since I have already put some detail into a [http://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=44097#threadId44102|support request] and at the moment I believe it only concerns two Wikis belonging to the same admin, here is a description:

Steps to reproduce:
1) Take any Tiki installation and move a new directory
2) Create a new DB with a copy of the original DB
3) Upgrade and start it up
4) Log into the old installation as admin
5) Find out you're admin on the new one, too.

It may well be that for some admins this is a wanted behaviour like as a single-sign-on (SSO).

But it is my firm belief that any such behaviour is to be considerd a breach of security unless both admins have expressley activated this as a wanted behaviour. Possibly the problem also exists if two different admins operate two different Tikis on the same hosted volume, that somehow were created from one single predecessor, so maybe this is not as harmless as it might seem to be.

I do not know, but suspect, this could be a cookie issue.

Resolution could be that tiki-installer regenerates all security structures upon installation and/or upgrades, or at least asks the admin whether such should be reset. Also, there should be a button in the administration panel to reset this at any later time. In my opinion TikiWiki should at all times, if not told to behave otherwise, protect its instance against all other possible instances of itself...

At some point confusion may get so high to a user's browser that logging into Wiki B alone will not function, and you have to log into Wiki A to be able to access Wiki B. At the moment I experience this with my new 6.7 LTS and my old 1.9.8.3. sitting in different directories on the same volume, accessing to different MySQL DBs with differing user names and passwords...

{syntax type="tiki" editor="plain"}
Often, we don't remember if we have already registered...

a) There is no way of displaying __all__ available tags.
b) There is no way to sort the available tags in alphabetical order when editing a wiki article -> properties.
c) The list of tags from case b) is hardly readable because the formatting leaves something to desire
d) There is no way to influence the sorting when displaying the freetags using the module Most Popular Tags.

The module upcoming_events does not indicate whether an all-day event lasts longer than one day. Such an event is only listed once on its first day. If the end date of events, that don't last all day is not displayed (parameter showEnd=y), an event lasting multiple days is indistinguishable from an event lasting only a few minutes.

phpBB is a popular open source forum software.
Sometimes, a forum is not enough.
So, the data must be migrated from phpBB to Tiki forums...

If you want to help:
Please post links to similar scripts.
ex.: phpbb to invision board, etc
If/when we do a script, we should do for all major forums.
---
__From kerrnel22 on 11/20/07:__

I have almost completed an integrated TikiWiki forum migration tool for 1.9.8.x and 1.10. Initial release will be to migrate only Tiki forums from one Tiki install to another. However, hooks are in place, and the intention is there, to work on extending the migration tool to importing of phpBB2 (or any other forum software) into Tiki. If you would like more information, email tiki.kerrnel@kerris.com. I expect a general release of the forum migration tool (for Tiki forums only) into cvs of both branches for beta testing by December 1/07. If all goes well, I'll have something released for phpBB2 migration prior to Dec 31.