Category: Usability

This bug is seen by our IE 8 clients. We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

When our users are editing in the CKEditor WYSIWYG and try the File option in the toolbar there is a Javascript error for lib/jquery_tiki/tiki-jquery.js at line 808 char 4. What is happening after the error is thrown is that no new window is opened (as expected) but the File selection fields are now under the WYSIWYG Editor. This wouldnt be an issue, but there is no OK button to select the file so our users can not like to a file in the File Gallery.

If I try using the File option in FF then it opens a new window and I can select the file just fine.

Since IE is our corp standard our users need to be able to add files using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

Thanks,
Tim

By default, creating a file gallery marks it as locked (the "Gallery is unlocked." checkbox is unckecked and the public property is disabled). This causes users other than the gallery's owner to be unable to upload files to galleries by default, even if they have tiki_p_upload_files on the relevant gallery.

There are several ways to see the problem:
# An object should not be created locked by default.
# The description of tiki_p_upload_files, "Can upload files", is misleading as it does not mention locking.

This can be considered as 2 different problems, but it would be prioritary to fix at least one, no matter which.



I think that by default "Gallery is unlocked" should be checked, but changing such a default would be dangerous if users relying on the current behavior don't realise the change. So I think my recommendation would be to replace the current checkbox with 2 radio boxes (labelled something like "Only owner can upload files" or "All users with permission can upload files"), with none selected by default.

File gallery slideshow does not work.

editor is not defined
file4?&slideshow
Line 12

The file templates/file_gallery_slideshow.tpl requires lib/slideshow/slideshow.rc1.packed.js but the latter file is missing, as is the "icons" directory which it requires.

On a related note, the directory lib/slideshow now contains directories css and js but no instructions on their use.

File galleries have a useful feature: You can store more versions of a file than one. That allows for images to be updated with higher resolution ones etc.

When you browse a file gallery, the wrench icon gives you access to the other archived versions of the file. However, when you access the file gallery by the ID of a specific file (which doesn't change when you upload new versions!), then the wrench icon lists Archive, but does NOT give access to any older, archived versions. Thus, the Archive feature cannot be used (at all) when accessing the file gallery by file ID...

It is possible to create several galleries in the root gallery of the file gallery.

It is possible move those galleries into sub-galleries and move everything into other sub-galleries.

It is not possible to move nothing back to the root gallery. In the move dropdown menu the "root" (File Galleries) item is not available.

Should not be restricted.

{syntax type="tiki" editor="plain"}
The list of actions that can be perform is limited to <move to> when others actions (individual list) could be performed as <delete>

The usability bug appears while updating the newer version of the file.
There is a field for a comment given to the newer version of the file being uploaded, however, what is being typed is not displayed:
{img fileId="1062" thumb="box"}
{img fileId="1061" thumb="box"}
If we then look, it displays what I typed as metadata (works properly here):
{img fileId="1062" thumb="box"}

I believe that the feature is unimportant and the bug it comes with confuses a non-technical user, the feature is to be fixed or got rid of

auto categorization does not work in drag an drop. This can be a huge problem for those who use category jail, as all files will become invisible.

This bug occurs when using multiple workspaces, where each have a perspective with a category Jail.

Consider each workspace to have a main file folder (that belongs to it`s main category, and is only acessed by a certain group when it enters the workspace).
If you upload a file with the normal way, it will acquire the category by the autocategoriation pref.
But if you use the drag and drop feature, it will have no category, and will become invisible to the users, even if is inside the main group folder (because it has no category, and the category jail pref is on)

Show instance: http://fvtorres-11800-5950.show.tikiwiki.org/
User: admin
Pass: 12345

{syntax type="tiki" editor="plain"}
I want to use backlinks in File Gallery to show me what wiki pages reference the files. This is how I can identify orphaned files. However, this function is so broken that it is unreliable.

What I would expect from this feature is the following behaviors:
#Each file referenced in a wiki page has a single backlink to that page recorded in the File Gallery that contains the file
#Backlinks to wiki pages are uniquely indexed, so that even if there are numerous references to the same file on a page, there is only one backlink to that page shown in the File Gallery, rather than multiple backlinks to the same page
#Removing a reference to a file from a page will remove the backlink to that page from the file in the File Gallery
#Deleting a wiki page will delete all backlinks to that page in the File Gallery

The behaviors I have been able to duplicate in the demo wiki ([http://demo.tiki.org/11x/tiki-list_file_gallery.php?galleryId=6]) are as follows:
#Linking to a file in a wiki page will create a row in the ''tiki_file_backlinks'' table for that page in the File Gallery every time you save the page, even if there is already a row for that page
#If you edit the page and then save it, the backlinks to the referenced files are sometimes incremented, and sometimes not
#Removing the link to a file in a wiki page and then saving it ''does not remove the backlink'' in the File Gallery to that page
#Completely removing a page from the wiki that is referenced by backlinks in the File Gallery will not remove those backlinks, but will instead leave orphaned backlinks to non-existent pages
#There is no reindex or cleanup function built into Tiki for File Gallery backlinks, and no way to manually fix or remove bad backlinks (other than directly editing the database tables)

I tried the file gallery from tikiwiki 3.2. in opera 10, the loading screen (uploading) never stops and the image is not shown in the gallery (empty picture frame) or when used inside a wiki page. When clicking at the icon symbol or empty space shown there instead the invisible thumbnail is opened correctly though showing the full picture. Works fine in IE 7 and latest Firefox.

Chose a non-default workspace:
{img fileId="1064" thumb="box"}

Open File Gallery and upload a file:
{img fileId="1065" thumb="box"}

Choose the file and see that the checkbox marking the category corresponding to the workspace is checked:
{img fileId="1066" thumb="box"}

The file is uploaded:
{img fileId="1067" thumb="box"}

Browse the file gallery - it is empty, where did the file go?
{img fileId="1068" thumb="box"}

Open the file gallert from the default perspective (workspace), the file is shown, thus, it was uploaded:
{img fileId="1069" thumb="box"}

Let's see its properties:
{img fileId="1070" thumb="box"}

It doesn't belong to the category it was said to belong during the upload:
{img fileId="1071" thumb="box"}

We add it to the category that we intended it to belong to:
{img fileId="1072" thumb="box"}

We switch back to the desired workspace, open the file gallery, our file is there:
{img fileId="1073" thumb="box"}

__Very low usability!__

I recently upgraded our tiki install to version 2. Most things survived the upgrade, however the most obvious thing that was broken is the file galleries feature.

All links to files previously in the gallery still work correctly, however when I select the option to list galleries, none of the existing galleries are displayed. It just shows "No records found"

Looking in the database, all files and galleries are there.

When i attempt to upload a new file, I am still given the option to select a file gallery (all gallery names are still shown). When I select the appropriate options and confirm the upload I can link to it as usual but it does not appear when I select to browse the gallery.

[http://tikiwiki.org/tiki-download_forum_attachment.php?attId=231|Screenshot]

when listing a gallery via tiki-list_file_gallery.php?page=fgal&galleryId=<GALLERYID> (with mode set to Browse), the filter section is always opened, even without filters being set, eating a lot of space.

probably comes from the other submitted but where uselessly empty filter parameters are added to the url, like find=&type=&types=&topic=&lang=&langOrphan=&exact_match=&categId=&find_from_Month=&find_from_Day=&find_from_Year=&find_to_Month=&find_to_Day=&find_to_Year=

when you list a gallery, tiki automatically adds all those useless parameters find=&type=&types=&topic=&lang=&langOrphan=&exact_match=&categId=&find_from_Month=&find_from_Day=&find_from_Year=&find_to_Month=&find_to_Day=&find_to_Year=, probably that's why u1 (see below) happens.

Withing a file gallery, the "parent gallery" navigation button appears even if that user has no permissions to view the gallery it points to, of course causing an error, and allowing google to index the error.

To reproduce: set global tiki_p_view_file_gallery to allow. Create a child gallery. Set the tiki_p_view_file_gallery for the parent gallery to deny. Navigate to the child gallery. Click the "parent gallery" link. The error appears.

What it should do.

Instead of checking if the user has permissions to view the page they are navigating from, check if the user has permission to view the page they are navigating to. (in this case the parent page.) & do not display the navigation link if here is no permissions to view it.

if you go into "edit properties" of an image, it doesn't drop you back into the gallery afterwards where you have been before, so HERE the offset needs to be remembered but gets lost. best would be if you would just click the image, overlay for editing appears, and on save it would just close again.

Bug 1: In a File Gallery the Actions Icon opens a pop-up list of Options. The Replace option does not appear to be a link (No link selector pointer or Status bar message). It does actually work, which is very confusing. Browsers: Firefox and SeaMonkey on Linux.

Bug 2: When a file is replaced, the Name property is set to null. Really annoying because you then have to use the Properties Action tab to set the Name, if you remembered what it was.

The first image displays but is badly distorted (available image lib is GD). The name of the second image moves into place, but the first image (its right-hand side) continues to display. Then it moves offscreen at about image name number three and no other images display.

The File Gallery Template feature is still in Tiki, and it seems nobody really knows what it was used for, if you will here is something I wrote a couple years ago on this, at https://tiki.org/forumthread59522
If this is supposed to work somewhere, it sure would be great to have it working if the intentions were to build upload templates from it.
Thanks for looking
John

Right now, it's a group permission (tiki_p_batch_upload_files) but if I give tiki_p_admin_file_galleries, it included tiki_p_batch_upload_files, which is not always what I want. (It adds clutter to the interface, when uploading a file)

It should be an option here:
tiki-admin.php?page=fgal

And maybe add a check to see if this is supported by the server (if easy)

Here on this site I get:
{CODE()}
Fatal error: Uncaught --> Smarty: Not matching {capture}{/capture} in 'layout_view.tpl' <-- thrown in /var/www/virtual/dev.tiki.org/html/vendor_bundled/vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_capture.php on line 139
{CODE}

Steps to reproduce:
# go to https://dev.tiki.org/File-a-bug
# in Description field click the {icon name=image} icon with the tooltip saying "Choose or upload images" from the toolbar
# in the popped-up window click the "Browse Gallery" button
# click on "Bug report images" folder trying to step inside

You will get the error reported above with the following URL:
https://dev.tiki.org/tiki-list_file_gallery.php?galleryId=13?filegals_manager=area_5e20296fb945a

__Duplicate of__ https://dev.tiki.org/item7267-It-is-not-possible-to-select-a-gallery-when-uploading-an-image-using-the-toolbar-tested-dev-tiki-org

When you open a file gallery, above the files stored in there are some functions for searching, and one that specifies how many results are to be displayed. The latter is misleadingly labelled "Number of lines". If you set the file gallery for list view that is correct. If you didn't, it's incorrect. In browse view your results will be in five columns, giving __five__ lines (with the default setting of __25__).

Therefore I suggest to rename this to "Number of results" which would be correct in all view settings.

When trying to move a file from one Gallery to another, the "Perform action with checked: Move Selected Files" option does not seem to list the Galleries that are an immediate sub-folder to the existing folder. All other folders are listed except these.

{syntax type="tiki" editor="plain"}
PopUp window for viewing image does not show up when browsing to a 2nd page.

Instead it shows the picture file going out the File Gallery.

Using Firefox, Chrome