Category: 6.x

===My Setup===
I have file galleries set up with categories, so each category grants permission for a specific group to view and edit file galleries which are categorized to that group. E.g., I have a "group 1" category which grants the group "group 1" permission to access the "group 1" file gallery.

I have a "group administrator" group which has the "tiki_p_remove_files" permission granted in each category. This gives me one group which I can add to a user to give them permission to remove files from whichever file gallery they have permission to view.

Technically, the group admins have permission to remove files from all sections, every category grants them this permission, but because they cannot see the other sections, this is not an issue.

===My Problem===
Even having the "tiki_p_remove_files" permission, group admins are unable to remove files which they did not upload.

I have "tiki_p_remove_files" set for the "group administrator" group in global permissions but the issue still remains.

To do some testing, I granted registered (thus all groups) "tiki_p_remove_files" in the global permissions, and in the category permissions, but section admins (and normal users) were still only able to delete their own uploaded files.

I have a sym link set to my old tiki version, so I can access it via tiki-url/old. I used to this to determine that this is an existing bug, and not a regression. When adding the "/old" to my url, and going back to Tiki6, group admins were still unable to remove these files. The perms are stored in the db, so this would be a valid way to determine this correct?

This makes me think that the bug has been around for a while, as it was present in Tiki6 as well.

I cleared the tiki cache before each testing of permissions, and also cleared my browser cache (just to be sure) multiple times while testing this as well.

It makes it difficult to assign a single user to be a file gallery manager if I cannot give that user the ability to delete other user's files.

{syntax type="tiki" editor="plain"}
Setup: Running 6.4, on Debian. Recently upgraded from 3.x, bug was present in previous version too.

1. In our TikiWiki forums, all discussion is emailed to an external address
2. At the footer of each email message, the Tiki appends a "Reply Link".
3. When a user receives the notification email, and follows the link, the Forum's "Reply to the selected post" fields are incorrectly populated. The "Title" field is for an enitrely different forum + thread, and the reply box contents are also not correct.

Subjectively (not exhaustively tested), this appears to only happen for posts after the first within a thread, e.g. the reply link for the original post functions correctly, but reply link for all following posts does not.

The 'correct' top post reply links are in the form:
<host>/tiki/tiki-view_forum_thread.php?forumId=14&comments_parentId=2994#form
While the 'incorrect' reply posts are:
<host>/tiki/tiki-view_forum_thread.php?forumId=14&comments_reply_threadId=14&comments_parentId=2994&post_reply=1#form

I suspect reply_threadId may be improperly populated with the forumId.

Thanks in advance.

{syntax type="tiki" editor="plain"}
setting User Module parameter to flip=yc does not change enything, even when module shade global is set to Module, tested on tiki 6.3 and 6.4.

Also there is no parameters separator for User Module parameters mentioned anywhere in documentation.

after new tracker item is added there should be any variable like itemId or lastItemId that can be used after adding, like:

{CODE(colors="tiki")}
{TRACKER(trackerId="8",fields="51:52:53:79",showdesc="n",showmandatory="n",showstatus="n",embedded="n",reset="Reset",newstatus="o")}
Action Point was added with itemId = {{lastItemId}}
{BUTTON(href="tiki-view_tracker_item.php?itemId={{lastItemId}}",_text="Details")}
{BUTTON(href="tiki-index.php?page=Add+Action+Point",_text="Add_Next")}
{TRACKER}{CODE}

{syntax type="tiki" editor="plain"}
For a File Gllery with Max Height and/or Width set.
When uploading a new version of a file over the top of an exisiting file, the Max Height and Width settings are ignored i.e. the image is not rescaled.

This item pulled out of Ticket ID 2874 which had several items.

File Galleris should be multilingual including

*Descriptions
*Names

e.g. description has different content for different languages which is then displayed with the image 'caption' automatically in user's language.

See detyailed discusssion and real world use cases at [http://dev.tiki.org/tiki-view_tracker_item.php?page=user&itemId=2874&show=view|linked ticket|_blank].

In Tiki 2.4 the syntax below work:

~np~{img src="img/wiki_up/cabeçalho" }~/np~

In Tiki 6.4 and trunk it doesn't (I haven't tested with other versions).

The problem is the special character "ç" in the image file name.

This bug was introduced in r22212 (http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=revision&revision=22212). If you remove the call to htmlentities() the problem is solved but I'm assuming this function is there for a reason.

At the end of the installer when launch is run we can get a crash with an exception :

__"Session already opened"__

This has been reported since two years may be six times.

I have not made various test, so may be it depends of the context which is :

#Data upgraded from existing connection
#Run without inhibiting installer

This should not have effect. So I don't understand why others don't seem to observe the problem that I had always.

I need to run again directly index.

{syntax type="tiki" editor="plain"}
If only items count needed (max="0"), like:{CODE(colors="tiki")}There are {TRACKERLIST(trackerId="8",fields="51",showtitle="n",showlinks="n",showdesc="n",shownbitems="y",showinitials="n",showstatus="y",showcreated="n",showlastmodif="n",showfieldname="n",showitemrank="n",status="op",sort_mode="created_asc",max="0",showpagination="n",filterfield="68",filtervalue="_%",export="n",silent="y",showwatch="y",displaysheet="n")}{TRACKERLIST}. Please verify the data.
{CODE}

Should return:{CODE(colors="tiki")}There are Items found: 3. Please verify the data.{CODE}, but returns: {CODE(colors="tiki")}There are
Items found: 3
No records found.Please verify the data.{CODE}

* there is additional "No records found" information, even if silent="y" specified.
* there are <BR> commands before and after {TRACKERLIST}

To reproduce, search "wiki" in the admin panel here:
http://branding.tiki.org/tiki-admin.php

And you will get:
"No preferences were found for your search query."

Ideally, the problem is solved, but this is maybe tricky. It could be related to:

{QUOTE(replyto="http://framework.zend.com/manual/1.11/en/zend.search.lucene.index-creation.html")}"Zend_Search_Lucene uses flock() to provide concurrent searching, index updating and optimization. According to the PHP » documentation, "flock() will not work on NFS and many other networked file systems. Do not use networked file systems with Zend_Search_Lucene."{QUOTE}

At the very least, Tiki should detect and report to the site admin that he should use MySQL Full Text Search instead.

Ideally, MySQL Full Text Search would work for tiki-admin.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.

{syntax type="tiki" editor="plain"}
Daily reports: Emails sent mostly every two days instead of daily as indicated in the feature

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.

How to reproduce:

Using WYSIWYG, edit a page which has a link to a wiki page which has an accented character and the link will change from accentué to accentu�


Workaround:

* Avoid non-English characters (éàç) in page names

TikiWiki 6.6

When using banners, and you update the banner table manually, the changes are not visible because the banners are cached. (so far so good).

However when clicking 'Clear all tiki caches' the banner cache (which resides in the /temp dir) is not cleared.

{syntax type="tiki" editor="plain"}
We recently upgraded from Tiki 3.x to Tiki 6.x and noticed that the Tracker Field User Select does not work with the variables of 0,1 entered and the selection of specific users. What it does do is just show the entire list of users as you type in a username.

So for example we have a tech ticket issue system setup using a tracker. Afer a user has submitted a ticket/tracker item, an IT person would go to an "Assigned" field (which is a user selector field) and choose the particular tech from a drop down list which was generated from the option of "Select list items that will be displayed:"

Is this an actual bug or are we misconfigured?

I am pretty new at this, so I am not sure if I posted the bug and patch at the correct place and in the correct form. Please let me know if I should change something. Unfortunately I do not have time at the moment to learn how to commit patches via SVN and am also a bit unsure about my fix, so please take a look and include it in the next release if you think it is correct.

Scenario:
Tiki LTS 6.6, Tracker not publicly accessible (by anonymous users), RSS Feeds enabled, RSS for Trackers and for Individual tracker items enabled, RSS basic Authentication enabled.

Behaviour:
If I try to subscribe to the RSS feeds of my tracker (by adding http://tiki.***.***/tiki-tracker_rss.php?trackerId=9 to Outlook) I always get the error "Tiki RSS Feed Error Message: You do not have permission to view this section". Same happens if I log out of Tiki and copy the address in my browser.

{syntax type="tiki" editor="plain"}
as the topic says

if you youse the redirect plugin in an article you cannot edit the article as it redirect the page even in edit mode

Tested in version 3.3 and 7:
Importing tracker items through CSV does not properly process the date field.

My exported CSV contains e.g. "24/12/2010 19:55"
The imported data only contains "24/12/2010" The time has been left out.

{CODE(caption="incorrect code 3.3" colors="php")}# Version 3.3
Line 1697
} elseif ($field['type'] == 'f' || $field['type'] == 'j') {
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = split('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = split('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
}{CODE}

Replaced by following code :
{CODE(caption="correct code 3.3" colors="php") } elseif ($field['type'] == 'f' || $field['type'] == 'j') {
$l = strlen($data[$i]);
switch ($l) {
case ($l == 10):
# Field does not contain the time
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
break;
case ($l == 16):
# Field contains HH:MM
list($fd, $ft) = explode(' ', $data[$i]);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
}
break;
case ($l == 19):
# Field contains HH:MM:SS
list($fd, $ft) = explode(' ', $data[$i]);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
list($hh, $mm) = explode(':', $ft);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
}
break;
}
}{CODE}

The same for the latest version 8.3

{CODE(caption="Incorrect code 8.3" wrap="0" colors="php")} case 'f':
case 'j':
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = preg_split('#/#', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = preg_split('#/#', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = preg_split('#-#', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
break;
}{CODE}


{CODE(caption="Correct code v8.3" wrap="0" colors="php")}# Line 1730
case 'f':
case 'j':
$l = strlen($data[$i]);
switch ($l) {
case ($l == 10):
# Field does not contain the time
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = explode('-', $data[$i]);
$data[$i] = $tikilib->make_time(0, 0, 0, $m, $d, $y);
}
break;
case ($l == 16):
# Field contains HH:MM
list($fd, $ft) = explode(' ', $data[$i]);
list($hh, $mm) = explode(':', $ft);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = explode('-', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, 0, $m, $d, $y);
}
break;
case ($l == 19):
# Field contains HH:MM:SS
list($fd, $ft) = explode(' ', $data[$i]);
list($hh, $mm, $ss) = explode(':', $ft);
if ($dateFormat == 'mm/dd/yyyy') {
list($m, $d, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
} elseif ($dateFormat == 'dd/mm/yyyy') {
list($d, $m, $y) = explode('/', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
} elseif ($dateFormat == 'yyyy-mm-dd') {
list($y, $m, $d) = explode('-', $fd);
$data[$i] = $tikilib->make_time($hh, $mm, $ss, $m, $d, $y);
}
break;
}
break;
{CODE}

We have a wiki page which has the plugin for RSS feeds. We upgraded from version 3.0 to 6.6 and now the RSS feed plugin no longer works. We have been unable to find a solution on our own and don't know if this is something we overlooked, don't know about or it is an actual problem.

I don't see this reported.

i migrated my tiki 2.x to tiki 6.6 this weekend. Formerly i have configured permissions for specific groups by defining a category and granting tiki_p_view_categorized permission for the category to a group. So it was able to add for example the category "top secret" to an article and just let those users (groups) see the article that had permission tiki_p_view_categorized for this category. Now everyone can see everything because those permissions are obsolete. But how do i configure this then to hide all those categorized items from other users? meanwhile i noteiced that the problem only occurs in articles. wiki pages and so on are doing fine. Can this be a bug, or is here a special configruation reqwuired?

This is the configuration (special permissions for the category are set just for the group "Mitglied":

Hinzugefügte Rechte:


Mitglied: articles_read_heading, download_files, rate_article, read_article, topic_read, view, view_category, view_directory, view_faqs, view_fgal_explorer, view_fgal_path, view_file_gallery, view_freetags, view_html_pages, view_image_gallery, view_sheet, view_shoutbox, view_tiki_calendar, view_trackers, wiki_view_attachments, wiki_view_comments, wiki_view_history

Entfernte Rechte:


Anonymous: view, topic_read, read_article, articles_read_heading, view_directory, view_faqs, view_file_gallery, view_html_pages, view_image_gallery, list_image_galleries, search, watch_structure, list_file_galleries, create_tracker_items, messages, view_trackers_closed, download_files, watch_trackers, view_trackers, read_comments, view_calendar, view_events, list_newsletters, modify_object_categories
Admins: admin
Mitglied: subscribe_email, suggest_faq, forum_edit_own_posts, forum_post, forum_post_topic, forums_report, post_comments, read_comments, send_pages, access_closed_site, view_poll_results, vote_poll, attach_trackers, submit_link
Redakteur Kalender: add_events, change_events, view_calendar, view_events
Redakteur WIKI: edit, wiki_view_history, modify_object_categories
Redakteur Links: admin_directory, submit_link, admin_directory_cats, admin_directory_sites, autosubmit_link, validate_links
Redakteur Artikel: approve_submission, edit_submission, submit_article, autoapprove_submission, edit_article, modify_object_categories
Redakteur Gallerie: admin_galleries, batch_upload_images, upload_images
Gastkartenbesteller: use_as_template
Redaktuer Newsletter: send_newsletters
Redakteur Archiv: edit_gallery_file, upload_files
Einreicher Artikel: submit_article
Mitfahrer Norwegen 2012: wiki_view_comments
Registered: forums_report, forum_post_topic, forum_read, forum_edit_own_posts, forum_post

Importing tracker items through CSV only sets the created and lastModif value properly if the dates from the CSV file are in the numerical php date format.

When you import a csv file where the created and lastModif dates are written as proper dates, the imported tracker items have a created and lastModif date/timestamp of the date & time of the import action.

example csv :

"itemId","status","created","lastModif","VRID -- 265"
"849","o","07/12/2009 13:24","07/12/2009 13:24","4"

Whenever I export a csv file, it contains the dates as shown above, so you can't just export data and import data on the fly without modifying all the values...

c.f. [https://dev.tiki.org/item3500|bug 3500]

{syntax type="tiki" editor="plain"}
I defined a structure Helpdesk FAQ and a categorie Helpdesk.
Now I give a group Helpdeskadmin the permission tiki_p_edit (and a lot of others).

If a helpdeskadmin trys to add a page with the button on the top of the wikipage with over the toc, the message "You do not have permission to edit this page." appears.

The problem seems to be the following permission test in tiki-editpage.php:

// Permissions
$tikilib->get_perm_object($page, 'wiki page', $info, true);
if ($tiki_p_edit !== 'y') {
[...]
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

If I give the permission tiki_p_edit to the group, the helpdeskadmin comes to the wysiwyg-edit-page, also he gets a message like the page must have a categorie. I didn't analyzed that yet.

{syntax type="tiki" editor="plain"}
Does the "Users Information Tracker Fields Asked at Registration Time" work for someone in 6.1? it used to work in 5.x. not pretty.

This feature was not particularly important if the trackers with registration="y" would work nicely. Read more here.
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-01-08,Sat&sel=52#l48]

{img fileId="270"}

Visit these pages to see for yourself:
http://info.tikiwiki.org/Hosting (6.x)
http://profiles.tikiwiki.org/Profiles_in_installer (9.x)
http://dev.tikiwiki.org/Tiki13 (12.x)


It should be a redirect 301. And needs to work for 6.x, 9.x and 12.x

This worked when the feature was introduced so some other fix / enhancement must have broken it.

This is especially not good because in this version the ((canonical)) link is just relative and thus, we have two canonicals for same page...

If you go to front page, it redirects OK
http://info.tikiwiki.org (6.x)
http://profiles.tikiwiki.org (9.x)
http://dev.tikiwiki.org (12.x)