Category: Usability

===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"}
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()}<script type="text/javascript" src="http://www.ohloh.net/p/39/widgets/project_cocomo.js"></script>{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.

I updated a copy of our wiki to 8.0rc1 to have a look whats new

but the first thing i saw was that all line breaks in the heavily used split-plugin were actually displayed as ~lt~br /~gt~ instead of being actual line breaks

I updated a copy of our wiki to 8.0rc1 to have a look whats new and just wanted to tell you the first problem i immediately saw:

but the first thing i saw was that all line breaks in the heavily used split-plugin were actually displayed as ~lt~br /~gt~ instead of being actual line breaks

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

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

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

{syntax type="tiki" editor="plain"}
A category field in a tracker is not displayed in list view, nor in item view/edit.

Hi,

There's a small issue on dev.tiki.org. So that should be the same with the corresponding feature (tracker) on tiki 8.1.

When looking at my "bug and wish list", all my tickets are listed in the 3 categories: open, pending and closed. Apparently the status filtering is not done correcly.

Attached a "screenshot" of what I see.

BR,
Yannick

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

{syntax type="tiki" editor="plain"}
During edition (creation) of a tracker the use of the format button "code" (plugin) generates when the "close" button of the plugin panel is used :

1- Stop of all edition of the tracker which is saved as it was before the action on the button "code"

2- The tracker remains not completed, not to be edited to end the redaction of the message.

A proposal of enhancement (separated tracker):

If the tracker can be edited a tab can remain but why not too the standard icon

{syntax type="tiki" editor="plain"}
If I upload a large transparent PNG as an avatar which Tiki must resize, it ends up with a black background instead.

{syntax type="tiki" editor="plain"}
If one is typing in the login hover and mouses out, no more typing is entered until one hovers over the login again.

When trying to create a Wiki Link using the WYSIWYG, the auto page find doesn't work anymore making it almost impossible to link to another wiki page without knowing exaclty the page name

{img src="https://img.skitch.com/20111124-r2ai2a29x2xyriua1mu3a3996h.jpg"}

{syntax type="tiki" editor="plain"}
After 8.1 installation, I need a long time to be able to login as admin (not tested till now for other, two many problems to solve, test are programmed).
I was upgrading data from 7.2.

In fact the lonely way needs all these steps :
- clear all local cookies
- clear caches of server (temp/cache; module/cache)
- reinit as new (tiki.sql and some complements as the length of passw is we don't change the admin pass, no object, the SQL import file reset admin user and checks admin configuration)

Then when you login admin admin you are normally asked to set a new password, as for new installation. Everything seems OK, it is not true.
!!!~~#F00:__If you quit the browser you will be reconnected automatically even though "you have not checked remember me".
__~~
!!!~~#F00:But if you quit~~, for example to login for test with another login (the reason why for dev I don't check remember me) ~~#F00:and try to reconnect you get __"Invalid login or password"__ ~~

No other solution than a full reinit of admin login.
__
I checked :__
*clear local cookie alone : no result
*clear only tiki caches : no result
*clear cookies and cache (the db data are good for admin identification) : no result
*clear cookies, caches, reset admin as new install : OK

{syntax type="tiki" editor="plain"}
The default value for styles which supports "fixedwidth" parameter title "layout... " is 990px.

This option is useful and should be included in a module (I will do when if will function globally). Depending of the job done 990px on a 1920 is often a straight workplace.

If it is activated and you set any value you will get as the option "fullwidth".

This option make a wrong calculus of the real available width (a problem with js functions and margins) and generate a larger layout that the width of the display device.

{syntax type="tiki" editor="plain"}
After a search (general by text) the beginning of text which is displayed is not decoded-re-encode for the context.
On the screenshot joined you can see parts of text with tiki tag (!! for h2), HTML tags, problem of encoding UTF8 probably or old text not re-encoded (not yet checked).

{syntax type="tiki" editor="plain"}
(Not yet checked for trunk)

After running installer with upgrade we get the message "Invalid database run installer..."

Running installer don't changes anything to database, but the message is still displayed.
It is a consistency "deadlock by soft".

The lonely thing generated by installer is a reset which needs to reset manually the admin account and clear all caches and cookies (see #4066 admin login problem).

~~#090:!!!Going on 12/06/2011~~

I need to check the soft.

The message is sent by "installer" $installer instance of class installer in installib
It checks before the validation of patches on db using $installer->recordPatch($patch) for each one.
recordPatch function in installer records the patch into tiki_schema as done with his full date.

The concerned (got by a var_dump) patch is "20110904_shoutbox_def_tweetid_tiki"
is not into the tiki_schema table.
So the test functions, but the tiki-install failed to make this patch on another version OK, as it is defined.

__~~#F00:When it runs now (installer at 8.1 level) it don't tries to make the upgrade. This is the deadlock.
__What is done if an old patch is not there !!!__

More there is no report at all.~~__

{syntax type="tiki" editor="plain"}
When you use on whishlist of dev.tiki.org the option "listyour", you get an unsorted list.

The most useful list is inverted sort by ID.

To get this you need :
#to sort by id
#Use again the column header to sort in reverse order.

I place it in bug usability and whishlist.

The first default display should be : ID reverse order sorted

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

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

On host without exif support tiki-8.2 gives blank page with
Fatal error: Call to undefined function exif_read_data() in /.../public_html/lib/images/abstract.php on line 236
when there are .jpg images on the page.

{syntax type="tiki" editor="plain"}
I've enabled the option "Admin Home>Comments>Comments below wiki pages>Display by default" but I still need to click on the "comments" button at the bottom of the wiki page to see or post a comment

If an attribute other than imalign or image sources are used, then a preview of the page cannot be made and a white page is shown when a save is attempted.