Category: 2.x

Currently, (2.2) when using the mailin feature to post to a forum, Tiki does not actually check the email until a user views the forum. Only then, is the email checked and new messages posted to the forum.

This means that the RSS feed for the forums, and modules such as last_post will not be correct until a user goes to the forum.

Instead, Tiki should check the email at regular intervals (in the same way that Tiki checks for article mail-ins.

After posting to a non-moderated forum, users sees the message as if the forum was moderated:
^
Your message has been queued for approval, the message will be posted after a moderator approves it.
^

Message is posted instantly, without any check from anybody

{syntax type="tiki" editor="plain"}
When user replies to a forum the pagination changes so that only shows 2 posts:
The topic post and the first reply

It still shows only 2 replies per page don't respecting the configuration for the forum ( 10 replies per page, 20, etc ).

Say I find a nice/useful forum post and I want to email it to someone, it is very long for no (apparent) good reason.

In the "last forum posts" module, the URL is like this: (which is OK)
http://doc.tikiwiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=438

But if I find that same link from here:
http://doc.tikiwiki.org/tiki-view_forum.php?forumId=1

It is:
http://doc.tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=438&topics_threshold=0&topics_offset=0&topics_sort_mode=commentDate_desc&topics_find=&forumId=1

Imagine you have 20 forums (>10 is common case in some educational scenarios).

Forums list indicates 2 pages of forums list.
Then you select the 15 first forums to a categ. with restrictive permissions, so that normal users don't have the perm. to see them. The last 5 are supposed to be seen by users.
The first 15 are in a section called "Salut i Medi Ambient" (without quotes), and the last 5 are in a section called "Salut i Medi Ambient 2005-06"
Those last 5 are not listed in the first page of the forum list, which appears to be empty, and the users see as if there were no forums (they are in the second page of the forums list).

This should be modified so that the available forums to a user are listed in the first page of forums list.

Using 1.10cvs.

In forums:

Topics are first level (discussion starters)
Message are replies. This uses the same code as comments (used in wiki pages, image gallery, etc) and has threading.

In 1.9.x, an admin can move a reply to another topic. This is of limited use. It is as if the admin decides "Your answer is more suited to another question"...

What would be much more useful:
To change a topic (and all threaded replies) to another forum.

So an admin could start with one general forum, and create more specific forums if/when the volume of messages justifies it. Right now, the admin has to plan all these forums in advance. And a list of empty forums is not very inviting...

If someone starts a thread in the wrong forum, it should be easy to correct.

===v2.2===

When an item has a Freetag added and the Freetag menu looks for content with a designated tag it will list ALL content - even if some pages are Categorized and the particular user doing the search does not have permission to access the page.

Obviously the user cannot actually access the page but being able to see it makes them think it is available to them and just knowing a particular page exists may create difficulties.

Need to filter the objects being listed (presumably in tiki-browse_freetags.php in a similar way that tiki-listpages.php does this) so that only objects that the individual user is allowed to see are listed.

Using 1.10cvs from mid june 2007.

Created a tiki from scratch (basic enabled profile). change features, and make sure freetags are enabled.
Added freetags to a wiki page.like this:
{CODE()}
help ayuda ajuda cómo com howto
{CODE}

After that, I can see the list of words on top of the page. When we click on any of the freetags, it goes to : http://yourdomain/subdir/tiki-browse_freetags.php?tag=help

Ann nothing is displayed there in the table of tagged content:

^
Browse related tags


Tots Planes Wiki Galeries d'imatges Imatges Galeries d'arxius Formularis Trackers Items
Troba:
type name href description










[[ant] Pàgina: 1/ [prop
^

Btw, it's a multitiki installation, on subdirectories (not virtual hosting)

The Full Screen edit button is visible in my quicktags list, even though I have the __Allow fullscreen edit__ option disabled.

The full text search module should provide means to determine what operators work with it. Perhaps a large tooltip or a link to an "advanced search" page. Syntax for the module is [http://tikiwiki.org/tiki-index.php?page=FullTextSearch|here.]

"Fullscreen Edit" is a new cool feature of 2.x

Quicktags are kept, but Wiki & Plugins Help are missing so it makes editing less enjoyable.

"Edit Summary" is missing as well. Maybe it's intentional?

I am poking around trackers trying to maybe copy the code to make a personal module or some such, and I noticed this:

[r@s tw]# grep -R function\ get_item_id ./*
./lib/trackers/trkWithMirrorTablesLib.php: function get_item_id($trackerId,$fieldId,$value) {
./lib/trackers/trackerlib.php: function get_item_id($trackerId,$fieldId,$value) {
./lib/tikilib.php: function get_item_id($trackerId,$fieldId,$value) {

Seems risky to me to have 3 version of the same function. Is that as designed?

To allow admins to set an exclusion list of pages to be included in the list of top pages or rankings. Useful for excluding pages like home pages.

Please see: ((Project Management)) and ((TrackerToGanttChart))

I would suggest the creation of two simple tikilib functions: have_permission() and feature_enabled(). These functions need to take the name of a Tiki permission or feature respectively, and should return a boolean if the permission is set, or feature enabled.

These two functions are obviously pretty simple to implement. After their introduction, all Tiki applications should be migrated to use them (a job I would suggest may take until 1.11 or later!).

The benefits of doing this include:

* Less programatic reliance on global variables
* No need to read entire permissions or feature database tables to return each page
* Lower in-memory information required to run the application
* Allows for finer grained permissions and feature control without affecting scalability
* Permissions and features can subsequently be replaced by more sophisticated, scalable, usable or effective solutions later without futher disruption to applications.

The last point is the key here: Whilst there are currently hundreds of permissions and features, there are lacking in places where they should exist. Clearly adding yet more permissions and features isn't really viable.

Also, having a replaceable solution means it would be possible to move to an "entitlements" based solution without breaking the entire system. Entitlements may offer a way to provide extreme customisation abilities, with scalable and flexible permissioning, control of features etc.

The subject of permissions and feature control is obviously broad. This RFE only aims to facilitate the future discussion and adoption of a more generic model for control of the application.

Like Wikipedia



In a more advanced form, the references could be kept in trackers, as Tiki would be a
[http://info.tikiwiki.org/Use+Cases#Bibliography_D_|Bibliography Management System].


Related:
[wish1769|Bibliography management system (references)]

((doc:PluginCode)) doesn't show colors for php code, as it should according to doc page:
[http://doc.tikiwiki.org/PluginCode]
Tried with param colors=>php or colors=>phpcode:
{CODE()}
{CODE(colors=>php)}
/** Return system defined temporary directory.
* In Unix, this is usually /tmp
* In Windows, this is usually c:\windows\temp or c:\winnt\temp
* \static
*/
function tempdir() {
static $tempdir;
<b>$tempdir = '../tmp';</b>
<b>/*</b> if (!$tempdir) {
$tempfile = tempnam(false,'');
$tempdir = dirname($tempfile);
@unlink($tempfile);
} <b>*/</b>
return $tempdir;
}
}
{CODE}
{CODE}

And it returned:
{CODE(colors=>php)}
/** Return system defined temporary directory.
* In Unix, this is usually /tmp
* In Windows, this is usually c:\windows\temp or c:\winnt\temp
* \static
*/
function tempdir() {
static $tempdir;
$tempdir = '../tmp';
/* if (!$tempdir) {
$tempfile = tempnam(false,'');
$tempdir = dirname($tempfile);
@unlink($tempfile);
} */
return $tempdir;
}

}
{CODE}

---
Update: RFE for plugincode:
Why not using "wrap=>1" as default param instead as "wrap=>0"?

Not totally sure if this is feature request, bug, or lack of knowledge. Basically I need some way of supporting maketoc with WYSIWYG pages.

Having a wiki plugin that is not readable by apache in the plugin directory causes an infinite loop when the user attempts to edit a page, because edit page tries to load a list of plugins and descriptions in the help.

tiki-editpage.php calls wikilib.list_plugins(), calls get_plugin_description(), which doesn't check open status after fopen().

"__Getting Things Done__ (commonly abbreviated as __GTD__) is an action management method of the __David Allen Company__, and the title of the book by __David Allen__ that describes the method. Both __Getting Things Done__ and __GTD__ are registered trademarks of the David Allen Company.

__GTD__ rests on the principle that a person needs to ''move'' tasks out of the mind by ''recording'' them somewhere. That way, the mind is ''freed'' from the job of ''remembering'' everything that needs to be done, and can ''concentrate'' on actually '' performing'' those tasks. What distinguishes GTD from other time- or action-management systems is the idea of __''grouping tasks'' by the context__ (defined as a place or set of available resources) in which they are to be __performed__."

http://en.wikipedia.org/wiki/Getting_Things_Done


TikiWiki can be configured for this.

http://www.priacta.com/Articles/Comparison_of_GTD_Software.php

After clean installation on tiki-wiki 2.2 (2.1)
the gmap plugin does not work.

For example following string
{img src=images/code.png}%%% {CODE()} {GMAP(type=>page, width=>560, height=>350, controller=>large, mode=>normal)/} {CODE}
in wiki-page does not generate any html-code.

The Google Map key issued for an nternationalized domain name is not accepted by the system with an pop up error saying like "the key is issued for another site"

Categorisation is a social problem - different people have different words for the "same" category.

Use Google-like tags (check schtuff.com for a nice example) - this would make lots of wiki pages easier to find, IMHO.

{syntax type="tiki" editor="plain"}
This has been seen on Tikiwiki 2.0 & 2.2: Trying to install the "googlecalendar" wikiplugin from "Admin mods" fails. A page appears stating "wiki-plugins/googlecalendar/wiki-plugins/wikiplugin_googlecalendar.php to impossible to copy".

This appears to be caused by a typo in the Packages/wikiplugins-googlecalendar.info.txt file on the line that states where to copy the plugin file to. There is no space between the source and destination paths and the "lib" directory the plugin should be copied to is missing.

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