Category: Trackers

Editing https://tiki.org/Consultants and https://next.tiki.org/Consultants or visiting pages like https://tiki.org/tiki-admin_tracker_fields.php?trackerId=22 made the server crash half a dozen of times. When t.o crash I had also crash on next.t.o doing something else.

From my understanding both are not on the same server.
Is it possible something still ties them together or could it be (extraordinary) random server crash occurring at the same time ?

{img fileId="1219" thumb="box"}
{img fileId="1218" thumb="box"}
{img fileId="1217" thumb="box"}
{img fileId="1216" thumb="box"}
{img fileId="1215" thumb="box"}

Note: It happened before I rebuilt the index using the web interface. At the end of the rebuilding they were multiples errors (much diverse than the screenshot show).

{img fileId="1220" thumb="box"}

This is a regression introduced at some point I don't know exactly when) between Tiki6 or tiki9 and Tiki12 at least, and confirmed to be a regression still for Tiki14.

Content of text area fields can not be shown as parsed any more when displayed through PluginTrackerList, but only when displayed through the tracker interface itself. Ideally, there should be a param in plugin trackerlist to allow whoever needs that content not to be parsed in their sites. this currently breaks the display of comments provided to students on their wiki based reports.

This will hopefully be demonstrated in a tiki instance in the following days (probably after a ad-hoc profile is created to help reproducing this setup, linked to Pretty Trackers, etc, even if the issue is reproduced aside of the pretty trackers, just with standard display of the contents of that text-area field)

See the attachment

Not sure if this:
a) configuration error on my part
b) a wish
c) a bug

From the documentation:
https://doc.tiki.org/Dynamic+items+list
it almost sounds as if this should work, except for the opening "to be tested".

Quote: "to be tested filterFieldHere can be an item link, a user selector, a group selector, a country selector, a dynamic list"

Listed a bug for now.

Will create a show.tiki instance for demonstrating

Create a bash or php script which will convert the old type Tracker rating field to the new one for upgraders (people who upgrade) using this field.
---
We would benefit in the Tiki Community itself since we would re-use all the information added by users over the years to indicate which bugs in the bug tracker are more important to them. It could be a way to review the list of pending bugs by priority according to user's opinion expressed in that rating option. Thanks luci for filling this wish report {sign user="xavi" datetime="2014-09-21T07:04:05+00:00"}

{syntax type="tiki" editor="plain"}
I propose that a Tracker field type UUID is introduced. This field would - similar to the autoincrement field - create a universally unique identifier (UUID) https://en.wikipedia.org/wiki/Universally_unique_identifier for every item while it is created or imported and will not change after creation.

With this field it will be easier to connect Tiki Trackers to other systems to exchange data (e.g. be able to push changed data sets from external databases). UUIDs are also common in systems that use calendars and contacts (CalDAV, CardDAV) to be able to identify data sets and avoid data duplication.

php: https://www.php.net/manual/en/function.uniqid.php

We (geoff and xavi) were considering the benefits of creating a Profile out of a use case of trackers, plugin list and custom search. To achieve such a goal, a pre-liminary step is to implement a tiki site in a show.t.o instance here in dev.t.o, which is similar to a custom setup that Geoff has for some project. And then, convert that setup into a profile in profiles.t.o

More to come. And feel free to join us if you have some ideas or spare time to contribute to this project! :-)
(you will learn how to create a profile out of a tiki site)

show instance (based on Tiki12 LTS):
http://xavi-9794-5603.show.tikiwiki.org/
u: admin
p: 12345

If permission is granted to view a tracker then tracker history can be seen (through category or direct permission)

History should be a kind of "editors / admins" privilege.
Creating a tiki_view_tracker_history permission would give more flexibility and I believe it is not big task.

So we can modify title as we do for the other mail notifications.

I would change default from:
[Todo 1.9.x] Tracker was modified at dev.tikiwiki.org

to:
[Todo 1.9.x] Tracker was modified at dev.tikiwiki.org by Jean-Paul

Creating fresh new first Tracker in Tiki 15.x yells an error alert box now:
{REMARKSBOX(title="Error(s)" type="errors")}

Field tracker_id does not exist in the current index. If this is a tracker field, the proper syntax is tracker_field_tracker_id.
{REMARKSBOX}

In the screen shot you can see a second dialogue box appeared after clicking the create item button. I don't know if this behaviour is form tiki or firefox (116 64bit on ubuntu) on , but could it be suppressed as I don't see the point in being given this message after clicking the submit/create new item. Once the item is created, if you re-edit the item and click save/submit the extra dialogue does NOT appear.

{file type="gallery" fileId="2111" showicon="y"}

Creation of tracker items with __relative dates__ from profiles shows the right date in view item but empty when editing item

By __relative dates__ I mean something like:
{CODE()}
+1 day 2 hours
{CODE}

(See more: http://www.php.net/manual/en/function.strtotime.php )

See it reproduced in the show instance of this other bug report ([item5254]):

http://xavi-9794-5254.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=4
u: admin
p: 12345

This item was created through applying the profile "Tracker_as_Calendar_12"

Defined as:
{CODE(ln="1")}
type: tracker_item
ref: event_004
data:
tracker: $Tracker_as_Calendar_12:trac_as_cal
status: open
values:
- [ $Tracker_as_Calendar_12:trac_as_cal_summary, A big conference ]
- [ $Tracker_as_Calendar_12:trac_as_cal_location, room 2.3 (15 seats) ]
- [ $Tracker_as_Calendar_12:trac_as_cal_start_date, +1 day ]
- [ $Tracker_as_Calendar_12:trac_as_cal_end_date, +1 day 2 hours]
- [ $Tracker_as_Calendar_12:trac_as_cal_priority, 5 ]
- [ $Tracker_as_Calendar_12:trac_as_cal_description, "I'm really looking forward to attending at this event." ]
{CODE}

Which produced, once applied, something like:

|| Summary | A big conference
Location | room 2.3 (15 seats)
Priority | 5
Description | I'm really looking forward to attending at this event.
Start date | 2014-05-28 12:58
End date | 2014-05-28 14:58
Created | Tuesday 27 of May, 2014 12:46:16 CEST
LastModif | Tuesday 27 of May, 2014 12:46:16 CEST
||

When clicking at edit, no start or end date are shown in the form, and the icon to open the popup helper to fix the dates is not shown either.

And then, in the wiki page to display items as calendar events ( http://xavi-9794-5254.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12 ), this event is not displayed either.

{flash type="url" movie="display782" width="857" height="741"}

Sometimes after editing and saving the tracker item here I get a CSRF confirmation warning and when I confirm that I see an error on top of the form which says something like:

{CODE()}
The following mandatory fields are missing :
Category
{CODE}

Even though the category field is there filled with correct category values!

__Please note the edited form contains your values but it is not saved yet!__ Only after another "Save" button click attempt it gets saved normally then...

You can see the issue on hovering the "Slider doesn't work" issue title on https://dev.tiki.org/Wishlist+Search+Page?default%5Bcontent%5D=Slider

{img fileId="1524" thumb="box"}

When trying to export to CSV from tracker, I get:

Notice: Undefined variable: my in /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php on line 396

Notice: Undefined variable: ours in /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php on line 398

Notice: Undefined variable: my in /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php on line 409

Notice: Undefined variable: ours in /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php on line 413

Notice: Undefined variable: initial in /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php on line 434

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php:396) in /usr/local/tikiwiki-1.9.4/tiki-export_tracker.php on line 445
"Apellido";"Nombre";"Kitá";"Kehilá";"Punto de salida:"; "balaban";"natalia";"Aleph";"Dor Jadash";""; "slatman";"geraldine";"Aleph";"Dor Jadash";""; "chaia arazi";"gerladine";"Aleph";"Bialik";""; "saccal";"marina";"Aleph";"Bialik";"";


Tracker structure:
[TRACKER]
trackerId = 8
name = Majane Darkei 2006
description = Inscripcion para el Majane Darkei 2006
useExplicitNames = n
showStatus = n
defaultStatus = o
showStatusAdminOnly = n
outboundEmail =
simpleEmail = n
newItemStatus = o
modItemStatus =
writerCanModify = n
writerGroupCanModify = n
showCreated = n
showLastModif = n
defaultOrderKey =
defaultOrderDir = asc
useComments = n
showComments = n
useAttachments = n
showAttachments = n
attachmentsconf = 0,1,3,0,2,0,0,0
useRatings = n
ratingOptions =
categories =

When viewing a tracker item in tiki-view_tracker_item.php, the overall rating doesn't get shown. It worked in my test-installations, but not here on dev.tw.o.

On a tracker set a currency field and set it to display the currency symbol.

It should display $35.00 but it shows ¤ 35.00

{img fileId="1533" thumb="box"}

I can't make the basic example work.
https://doc.tiki.org/PluginCustomSearch#Basic_Usage

I'll reproduce it in show.t.o to make it easy for others to to review where the issue might be.

My goal is to leave one basic working example documented in doc.t.o

Admin password in that instance is:
u: admin
p: 12345

Go to Homepage, log in as admin, and try to search for any word found in the three items in that tracker. No results are found.
Index has been rebuilt many times.

I create a dropdown field and a customsearch template.
Searches on values works unless there are spaces in the displayed value.

It's demonstrated here : [http://jyhem-9952-7502.show2.tikiwiki.org/]

A tracker is created using Date Only field, after the tracker is displayed in a wiki page with a user submitted date, the date format looks something like this.
-1167609600

A show instance will be created with a tracker to use to display date in a wiki page.
Thank you for inspecting this bug.

{syntax type="tiki" editor="plain"}
The styles of the "button" of the date picker (or whatever it's called - the place you click to display the selector for the date and time) such as the font and colors are set dynamically to match the theme being used. This works for the themes in the themes directory, but this doesn't work completely for custom themes.

For example, I have a custom light-on-dark theme with a body background color of #0c0d16 (almost black) and a .form-control background color of #343a40 (also very dark), but the background color of the date picker's "button" (~np~div.dp__main dp__theme_light~/np~) is very light so clearly isn't getting the background color information correctly from the theme stylesheet. In a non-custom dark theme like Slate, I can see the button display with a light background for an instant and then get the correct dark background color to match the Slate theme, but for custom themes this switch doesn't happen, in my experience.

On the other hand, the date picker is using the right font, as specified by the custom theme, so there's partial success here.

I tested with the Switch Color Mode not active and with it active and set to both light and dark and the date picker button background was never correct. A workaround would be to add a CSS rule to the custom theme to correct the background color, but it would be nice if it worked automatically as it does for the themes in the themes directory.

Actually, now that I look again, it appears that the background color for the popup (with date and time selectors) isn't correct for non-custom themes, either. Using the Slate theme, which has a dark background color, the date picker popup has a light background with light text. This bad contrast is maybe due to the correct text color but wrong background color being used.

Also, the selector and popup backgrounds aren't sensitive to Color Mode switching.

Hopefully the same fix for these issues will work for both custom and standard themes.

The date picker is supposed to use the site styles (font, colors, etc.)
There is a difference of style when you see today's date and other dates (has been fixed recently)

Both are present in Tiki25 and gone in TIki26rc.

{img fileId="2107" thumb="box"}

{img fileId="2108" thumb="box"}

{syntax type="tiki" editor="plain"}
I've updated a Tiki27.x (after the Tiki 25.7 release) and now the date and time selectors are broken.
It is visual and forbid entering a date. I found a workaround, see below.

This is an old Tiki (started in Tiki9x) that was updated years after years.
I couldn't reproduce on demo.

{img fileId="3233" thumb="box"}

I don't see errors on the console on Brave.

On chrome:
{CODE()}
min_main_235ae2033a9c3fb4320e739db2fbcd55.js:137 JQMIGRATE: Migrate is installed, version 3.5.2
injected.js:3 [Detection] Sign in with intersection observer was watching an unacceptable node.
WI @ injected.js:3
injected.js:3 [Detection] Sign in with intersection observer was watching an unacceptable node.
WI @ injected.js:3
{CODE}

{CODE()}
if (!No(o)) {
console.error("[Detection]", "Sign in with intersection observer was watching an unacceptable node.") || logger.report(["Sign in with intersection observer was watching an unacceptable node."], {
severity: "error",
fileName: "js/b5x/ui/inline/frame-manager/src/sign-in-with/detection/manager.ts",
lineNumber: 230,
prefix: "[Detection]",
highlight: !1
}),
t.unobserve(o);
continue
}
{CODE}

Date validation (at Registration) is not validation the date field correctly. Validation only accept if day of the date is under 12. It seems it understand the number as as months not days. And it is not themonth field, since the month field popup menu is just next to the date field.

I checked all the date formats and reseted it to the Tiki default and the error still persists.

In tiki-admin_trackers you can only use fields explicitly belonging to the tracker for default sort - it would be good to have the possibility to sort by default by Created or Modified, too.

Should be possible to even default sort by Comments, Attachments, Downloads etc.

UPDATE:
Even TrackerId would be interesting. This occured to me, when trying to make bugs duplicate - that wasn't possible by TrackerId or other standard fields. So problem has been rephrased:

Opened up a New Trackeritem for this and marked
THIS one DUPLICATE of
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=256