Category: 7.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.

Installed new site using v7.1. WYSIWYG editor was working OK (not perfect, but could at lease copy and paste Word documents with 85% accuracy, switching between source and WYSIWYG worked, tables worked, inserted HTML tags worked).

After upgrade to 7.2 WYSIWYG has become unusable. The following problems have been seen (there may be others):
#Toggling between source and WYSIWYG (using the SOURCE button) gives mixed results. Wiki syntax in source is correct but in WYSIWYG it displays wrong (most notable is bold not parsed). WYSIWYG will display page semi correctly in the editor window with some of the formatting, e.g. auto numbering is correct, but when displayed in preview (or saved page) wiki syntax is ignored and is display as one long line (no cr or formating).
#Editing a table in Source will cause any other table to break by changing the wiki syntax by adding a carriage return after each cell and the cell delimiter.
#Can not post text copied from a Word document any more. Comes out as HTML code unparsed, then on save displays as one long string of HTML code.
#When inserting HTML code using {CODE()}{HTML()}...{HTML}{CODE} to change styles, save sometimes drops first two character, changes first > to HTML {CODE()}& gt;{CODE} and drops closing HTML tag, at other times will add {CODE()}< x >{CODE} at third character. Can not correct using any editing method in the WYSIWYG editor.

Standard editor works fine.

{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"}
Both the Unified Search and the MySQL Search results page displays the wiki syntax instead of parsing it. This occurs with the MySql Search whither or not "Parse the results" is checked on the admin page (there is no similar setting for the Unified Search).

This same behavior has been seen on the tiki.org pages. Here's an example result from searching the Community: {CODE()}CoCoMo
{HTML()}&lt;script type=&quot;text/javascript&quot; src=&quot;http://www.ohloh.net/p/39/widgets/project_cocomo.js&quot;&gt;&lt;/script&gt;{HTML} Reference: http://en.wikipedia.org/wiki/COCOMO
Last modification: Monday 24 October 2011 16:18:35 PDT{CODE}
and
{CODE()}Features/Usability: Re: Re: Re: Re: anyone ? anyideas? anything?
Thanks ricks99, the example you gave is what i want to do. However, when i include the poll in my wiki page, the ratings results still don't show up. I've tried it as a poll using {POLL(pollId=>2)}{POLL} and a module {MODUL
Last modification: Wednesday 02 April 2008 21:56:01 PDT{CODE}

This makes if very difficult for a user to determine if the page is relevant to their search.

It would be nice if some of the simpler formatting was displayed, e.g. bold, code blocks, underlining, etc. to make the results more legible to the user.

{syntax type="tiki" editor="plain"}
v7.1 & 7.2

Searching Wiki pages does not return expected results.

*It appears that the default search only searches part of the page text and not the titles.
The search does not return pages from a structure that I know have the search phrase displayed on the page. When this happens I usually get an empty "List Wiki Pages" with "Exact match" checked (I don't know what the exact trigger of this is but it occurs most often while searching titles). Unchecking this will then return results. It would be nice to have "exact match" be an option -- not the default -- on the admin page to reverse this behavior.
*No search will return a match for text in a structure alias name, even though the text is display to the user.

I setup a test structure like this:
Page 1 -> Page One
Page 2 -> Page Two
Page 3 -> Page Three

The text on each page was "Now is the time for all good men"

Searching for "Three" returned nothing.
Searching for title "Three" returned nothing.
Searching for "Page" returned all three pages.

It seems to me that a user would be typing into the search box a word or phrase that they expected to be on a page, whither it be a title, alias or text and would therefore expect a search of "the entire site" to return one or more pages that display some form of their text without having to click on several buttons.

{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].

Im tikiwiki using a my new web site tiki installing after get some big problem ( first using tikiwiki 1 versions)
Problem:- 7.1/7.2 editions
This testing home virtual sever and x10 hosting (not including x10 hosting URL s but I can send it ). admin edit after not working site



http://www.spacenet.x10.mx/ look at

http://www.spacenet.x10.mx/tiki/ not working


eg http://localhost/tiki-7.1/tiki-7.1/ not working


http://localhost/tiki-7.1/tiki-7.1/tiki-admin.php working

http://www.spacenet.x10.mx/tiki/tiki-admin.php?page=general working



I checking a web directry it still including a index files


This type using tiki 6 vertions not get this type problems (install and edit after 6 )


Thanks

i cant uploding images
Capee
(sorry to my English )

{syntax type="tiki" editor="plain"}
No html links are shown for uploaded images in the file gallery. Only wiki display and download links appear in the "Additional Info" screen.

Users just have to "know" that to display in html you must use /displayFilenumber

Also, there is no direct way to get BACK to that Additional Info screen from the gallery once the file is uploaded. i.e. it does not appear in the image's 'tool' pop-up menu, which just lists for us Dowload, Replace, Properties, Open in WebDav, Email this, and Delete only. No way to get back to the "additional info" screen.

Also, the images don't have a suffix when the URI format is /display123 and this causes problems with some software which expects one.


The old image galleries had an html link for the images.

It would be nice if menu option positions renumbered when you make changes. I know they're positioned 10 apart, I assume so you can insert things later, but I'm OCD so I'd renumber them anyway if I ever had to make changes (:razz:) If I had to guess, this would be a fairly easy change, module orders already do this so the code can probably pretty much be copy/pasted from there.

Hi,

Reporting this bug, which is apparently still present.
Other users are facing that issue: http://blog.gmane.org/gmane.comp.cms.tiki.user

When uploading a bundle of images contained in a zip file, and selecting the option "Unzip zip files", all the images are well extracted and added to the gallery. However, the file type (in my case png, but I guess this is the case for all file types) is not reconize and the files have the type "application/octet-stream". Consequently, inserting the image in a wiki document for exemple, and changing its size, will produce the message "File is not an image"

I was able to reproduce it on tiki 7.2. Attached some screenshots of the problem.

Yannick

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"}
I TRIED TO SUBMIT THIS BUG BUT I CAN'T FIND IT AFTER SUBMIT. SO I AM TRYING TO RESUBMIT IT AGAIN. SORRY IF IT CAUSES A DUPLICATE.

I upload an image to the File Gallery, which gets assigned id=19.

Then I go to a page and insert the following Tiki markup:

~np~[tiki-download_file.php?fileId=19]~/np~

~np~{img fileId="19"}~/np~


To (a) provide a link to download the image, and (b) insert the image inside the page.

Works up to here.

But then, I do:
* File Galleries > List Galleries > Browse Images
* I locate the image I just uploaded, and click on the the wrench icon, and then on "Upload New Version".
* I upload a new version of the image
* If I go back to File Galleries > List Galleries > Browse Images, I see that indeed, the old image has disappeared, and it has been replaced by the new version

The problem however, is that the new image has id=20, not the old id=19. But the id has not been changed on the link and IMG plugin that I inserted on the page. So they still point to the old image with id=19.

The weird thing is that I can still download image id=19 (even after clearing my cache), eventhough I can't see that image in the gallery anymore. In other words, the image is still in the DB and can still be accessed.

This is definitely not how things should work. If I upload a new version of an image, then all references to that image should be updated accordingly, and I should not be able to access the old version, except in a "view history" kind of context. No?

{syntax type="tiki" editor="plain"}
The following settings do not get saved when you create a new sheet or configure an already created sheet.

Class Name:
Header Rows:
Footer Rows:
Wiki Parse Values:

{syntax type="tiki" editor="plain"}
The two icon flags (eye.png and eye_magnifier.png) that are used to show the "watch" status of a forum are always switched together, so one doesn't really know what kind of watch he set on the forum.
See also {img id=128}.

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

{syntax type="tiki" editor="plain"}
From 2011-06-23 to 2011-10-11, the bug tracker of dev.tiki.org was not properly recording the "submitted by" field (because of Tracker Revamp)

All the data is in the notification emails, and just needs to be restored manually.

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

{syntax type="tiki" editor="plain"}
With revision 31581 the LDAP group synchronisation has been limited to only happen 60 seconds after the login:

http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/trunk/lib/userslib.php?r1=31565&r2=31581&pathrev=31581

So far as I can see this method is only called during the LDAP login procedure, so the if-statement in line 1415 will always be false, thus no synchronisation will happen.

I checked this problem with 7.1, 7.2 and 8.3 and never succeded to get the groups from an AD although the LDAP login worked. After disseminating the code and removing this if-statement the feature works again.

I wonder what the the use of this if-statement was? The commit message refers to webdav changes - how does it affect this?
Can this statement be removed so LDAP group synchronisation works or is there another way to fix this?

{syntax type="tiki" editor="plain"}
!!!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.

{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}

{syntax type="tiki" editor="plain"}
Hi,

After a version upgrade (any data transfer etc...), if a dir containing gallery is forgotten in the new installation (nothing is perfect), it seems that there is no check when the gallery is loaded, this can (most of time) crash Apache.

nota : I have not tested for "files" only for "images" but I pur it into the the categories before I imagin that the problem exist on both.

Checked on 6.x and 7.1

The WYSIWYG editor should have a button to create HTML comments that will only be visible in edit mode, and not in read mode.

As with all HTML, the comment tags should not be visible in WYSIWYG mode. The commented text should be a different color; perhaps grayed out.

This feature would enable editing discussion to happen right within the page being edited. Editors could more easily reference the text under discussion, since it would be right next to the comments. Discussing pages separately in the forum would no longer be needed, or would be optional.

Feature request: Add an etherpad module to Tiki.

Etherpad allows __really__ real-time document collaboration for groups of users.
It's free and open source, with parts under Apache License 2.0, BSD, LGPL 2.1 and GPL 2.0 licenses.

On August 14 2011 the people at etherpad have released a jQuery plugin and a PHP class for easy injection of pads into web pages.

More at etherpad.org