Category: Trackers

When trackers are not present (perhaps lost or otherwise mistyped) a 500 (internal server error) is produced.

At the very least it should be throwing the correct error 404 (page not found), but ideally would produce a Tiki error reporting something like "Sorry that tracker does not exist" or something similar.

This situation of lost trackers happed on dev.tiki.org where trackers where lost:

https://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=4130
https://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=4129

They were indexed by Google and linked within the content of the tiki-sites. It looks bad flaunting server misconfiguration errors on our sites.

{syntax type="tiki" editor="plain"}
The current (as of 25.x) way the form UIs (whether for settings or trackers fields or whatever) lets the tiki help icons "after the setting widget" wrap onto the next line when the widget is full-width, is problematic for a number of reasons, including:

* It creates visual confusion as the beginning of each line is different, and since all those elements are very colorful (ex: in the default theme both the checkboxes and the info icons are blue, which makes it harder to tell them apart quickly when scanning the page);
* It causes row heights to vary needlessly, which is unpleasant;
* It eats more precious vertical space than it should, which causes needless scrolling, with pages up to twice as long;
* It looks and "feels" broken (or "dangling"), visually, which impacts the first impression people¹ get of the software.

My guess is that Tiki lets those things wrap when it shouldn't (maybe using some sort of non-breaking space character, or a div containing both the form field and the related things?)

The only exception I can envision is long explanation labels, those make sense to have on a separate line.

Please see the attached screenshots (and mockups), this will make the problem self-explanatory; compare image no1 vs no2, and particularly no3 vs no4 which illustrate very well the change in the "global feeling" and compactness of the layout when you do this for many fields.

{file type="gallery" fileId="2029" showicon="y"}{img fileId="2029" thumb="box"}

{file type="gallery" fileId="2030" showicon="y"}{img fileId="2030" thumb="box"}

{file type="gallery" fileId="2031" showicon="y"}{img fileId="2031" thumb="box"}

{file type="gallery" fileId="2032" showicon="y"}{img fileId="2032" thumb="box"}

Image no5 shows how this problem also affects Tiki Tracker list tables and such where there are editable cells with clickable icons/buttons in those cells. Those shouldn't wrap either, they should stay on the last line of the contents (or maybe vertically centered in the cell, or top-aligned?) :

{file type="gallery" fileId="2033" showicon="y"}{img fileId="2033" thumb="box"}

---

¹: Humans don't like things that are "dangling" in general... this is exactly why Batman asked Robin to [https://youtu.be/QnFOs7QlJSI?t=12|hand him the shark-repellent bat-spray] to get rid of a dangling shark.

I currently keep track of bugs submitted by me by searching for my username. This results in a list of bugs, currently the first link looks like this:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2561&highlight=tobi_h

Klicking that link gives an almost blank page, removing "&highlight=tobi_h" shows the page as it should.

Update: This only happens if I am logged in. More detail, thx to chibaguy: "...left and center columns are empty, and the right column is a column width off the page to the right."

This does not apply to wikipages, where highlighting works.

If really this is not meant to work, then the button should be hidden, but there is no reason why it shouldn't work, since No Tabs work elsewhere, in the admin pages for example.

{flash type="url" movie="display651" width="1119" height="601"}

This is a different behavior than in 12.x

I can't change a field of type "attachment" to any other kind of field.
No error message, no feedback. It just does not happen.
Rebuilding the index does not help.

I have set : Preference tracker change field type enabled (Preference name: tracker_change_field_type)

I can change the type of a field of type text, but not of type attachment :-(

This worked on Tiki16.x

In a pluginLIST template I would like to have a pluginTracker inside a pluginFade using wikiplugin
Any of these work :
{CODE(theme="default")}{wikiplugin _name="fade" label="Edit item" icon="y" }Some text{/wikiplugin}{CODE}
{CODE(theme="default")}{wikiplugin _name="tracker" trackerId="18" url="this-page?itemId=$result.object_id" }{/wikiplugin}{CODE}

This does not work :
{CODE(theme="default")}{wikiplugin _name="fade" label="Edit item" icon="y" }
{wikiplugin _name="tracker" trackerId="18" url="this-page?itemId=$result.object_id" }{/wikiplugin}
{/wikiplugin}{CODE}

Was doing some tests with JQuery, and found out that any category field will have an extra pair of brackets after the FieldId → ins_341[]
Run into some trouble to use it.
The other tracker fields will just end up in the number. This might be a problem to somepeople, speccialy by using plugins that will target it, like trackertoggle.

Tried to look in the plugin php to see where this is generated but coudn`t find it.

Below is the complete code for field 15 (category field) I used in a test tracker
{CODE()}<select name="ins_15[]" class="form-control" aria-invalid="false">
<option value=""></option>
<option value="1">A</option>
<option value="2">B</option>
</select>{CODE}

Thanks

{flash type="url" movie="display719" width="671" height="535"}

Imagine a site where users can register themselves,a nd select to be just simple registered users, or to join "Comission A" in adition.
Group "Registered" has tracker 1 linked to it, and set to request some fields from it at registration time.
Group "Comission A" has tracker 2 linked to it, and set to request some fields from it at registration time.

And imagine that we want to allow the users initially registered just to "Registered" group, can join themselves the group "Comission A" later on, if they wish. We could use the SUBSCRIBEGROUP plugin for that (nice plugin!)

However, when user clicks on the "subscribe" button, he/she is not requested to fill in the tracker item needed to join that group, but nothing else and sees the same wiki page instead.
For consistency, that user should be directed to the tracker item insertion for that tracker2, so that all users from that group have filled the required fields, agreements (on checkboxes), etc.

If you click (two times...) in order to sort the Wishlist by modification date descending (btw., IMHO this should be the default...), the alleged latest edits are reported to be from Dec. 21. I have opened modified two other bug reports this year, and the list of recent changes shows them, but somehow they are not listed at the top of the Wishlist, at least not above Dec. 21 ?! See screenshot...

Thanks
hman

For POI map items ie a tracker item with an Icon field, the icon image is no longer updating WHEN USING FIREFOX and the tracker_legacy_insert pref is enabled – in the tracker item edit screen a new/different icon image can be selected from the available options in the file gallery, and this is correctly shown just after selection but when the item is saved the icon reverts to the previous image.

Using Chrome it is all OK - not checked other browsers yet

Show instance with tracker setup:
http://eromneg-10122-5815.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1
admin
admin12345

UPDATE: OK – I’ve narrowed down the issue further

I’m using FF44.0.1 so no difference there, but because my test site has evolved from much earlier versions it has got a whole range of tracker prefs that have been set over the years (or have arrived during upgrades to give backwards compatibility)

I’ve spent a bit of time aligning the show instance to what my test site uses and the key difference is the tracker_legacy_insert pref which is set in the Tracker Control Panel. With this set the issue occurs in the show instance with FF but is OK in Chrome

Images uploaded to tracker field image do not respect multitiki paths.

When you upload an image to this type of field, they go to

__img/trackers/__

When you are in a multitiki of, let's say, site1.example.com and site2.example.com, you have a folder for site1 at:

__img/trackers/site1.example.com/__

but your image files don't get uploaded there, but to the general

__img/trackers/__

And the same with all the other multitiki sites.
When you want to backup files, or migate a site to a new server, you are in trouble to know which files belong to which site from the multiki installation.

For consistency with how multitiki works, they should be uploaded to, and used from, the multitiki-aware path:

__img/trackers/site1.example.com/__

I've seen the gorgeus work done with jquery to allow re-sorting data in tables at wiki pages when using the ((doc:PluginFancyTable))

That would be also awesome if enabled in the ((doc:PluginTrackerList))...

This way, we would even allow the conflict between cache and sorting for anons... (see this other report [bug2898] )

Trackers are amazing.

However, how do you get data in & out?

As of now:
IN: you need to type in all the data.
OUT: workaround: change the number of items in a list and copy paste table to a spreasheet.

importing / exporting from .CSV would be much better.

Images could be tricky :-)

The Import/Export Screen displays all parameters of the current tracker, which is great.

it can be used to import fields+parameters to a new (empty) tracker.

currently it does not work to revise current tracker fields, if you edit and "import" the field parameters it creates duplicates that will take a long time to delete.

Tested in Tiki 25:
The Tiki uses Tracker to store users information and email as username.
I have a tracker (user information) with a username field.
I have a CSV with a list of users.
Using the Import-Export feature I created automatically a format with a "userlink" type of field.

If I import my CSV ===but the users don't exist yet===, even if the feedback is "success" and I can see the items, as result when going to the tracker view (tracker1) only the display will be completely broken and unusable displaying only the first items.

The import-export should reject the missing users items.
The verbose shouldn't be success but something like "item for bsfez could not been imported, the user doesn't exist".
Of course even if it happen to be (an item point to a user that doesn't exist) the tracker display should not be broken and allow the other item editing.

Right now PluginJQ documentation ( https://doc.tiki.org/PluginJq ) is very helpful, and I made a profile in 12.x to manage the conditional display of some fields in forms.
http://profiles.tiki.org/Conditional_Display_in_Forms

But in 14.x the required syntax seems to be different, and I don't get it right:
http://profiles.tiki.org/Conditional_Display_in_Forms_14

See it reproduced in here:
http://xavi-9794-5642.show.tikiwiki.org/tiki-index.php?page=CDF+instructions
u: admin
p: 12345

When selecting Case A or Case B in the radio button, all fields are shown, but no bg color for all the shown fields below the radio button.

When selecting Case A in the radio button, still some labels from fields for Case B are shown (text area)

Xavi

The Mathematical Calculation Tracker Field type should be improved in a way to be able to use Javascript and/or PHP code elements for calculations
(in fact maybe all areas where currently the mathematical calculation logic is used in Tiki could be improved by including Javascript and/or PHP).

This would greatly improve the possibilities and power of Tiki and Trackers to include more advanced calculation and logic into the Tiki system.

The tracker search/filter option is not so obvious for new users.

Editing inline on the tracker list can be very handy and even a must for several use case where you need to update many items regularly.

On Tiki21, some fields need more room like the relation field.
Also inline editing save on tab change or return or submit.
It is pretty complicate and unsafe to select the right field just after you search for result as the saving process is already running.
https://share.vidyard.com/watch/HZfjqXGNVPZHszy6ae9X4p?

Also when you are in the middle of a list, the saving process move the display and the success remarks box is displayed awkwardly over your list

PS: By the way the url can inflate quickly as you use a filter, then another, then...

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

Recurrent problem since 4.0. already reported, seems to had been solved, so may be it's a regression. To test.

The sort command (by clicking into header) leads to a crash.

Before we got an SQL error, now the current selection is cleaned.

__Important details :__
* not tested (again) for each column in "table header"
* not tested for various selections of tracker items
* Sure : after a selection of items (content of selection not empty normally without importance : category feature and feature requests for all), a click on date column header which runs a sort command leads to an empty page for a new search.

I am quite sure that an error still occurs into the sort SQL command, but the error is kept and a locate to new search is made.

__What I am going to do :__
* Test for the not tested various conditions (already done six month ago)
* Test on my development version 6.x with xdebug (show the requests, firebug and eclipse)
* Check the SQL request(s)
__
Then write here the report __

In admin tracker list (tiki-view_trackers.php?trackerId=XX), if I filter on an itemLink field which is configured with pointing to the remote tracker's ID and displaying another value, I need to enter the value of the ID instead of the value which is displayed. This is counter-intuitive and hard to guess.

{syntax type="tiki" editor="plain"}
On a fresh Tiki27 => Trackers

{img fileId="3082"}