Category: Trackers

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

In the function: function send_replace_item_notifications($args)
in lib/trackers/trackerlib.php, and change to the tracker generates an error and a failure for attempting to assign() to a non-existent object.

The line that generates it is:
$smarty->assign('mail_date', $this->now);

But if I comment that out, the next one generates it - so I think it is all assigns.

The error occurs if: I have a standard "watch" on all tracker activity. I have not tested moving the notification into the tracker setup screen.

To test, I:
1. Manually set $simpleEmail = "y"; error goes away
2. Set the Simple Email flag on the edit tracker prefs screen - error does NOT go away

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

{syntax type="tiki" editor="plain"}
Example: I've created a created including two date fields, Date Started and Date Closed.

Both are date and time data type, with options d,2008,,blank

I've also created a wiki page and added a tracker new item form with PluginTracker, configured to display only Date Started. When saving the new item, the visible field (Date Started) inserts a blank as expected (from the values in the controls), but the hidden field (Date Closed) inserts today's date. If Date Closed is made visible, it starts defaulting to blank as well. So hidden fields appear to be behaving as if option 'empty' rather than option 'blank', or not picking up the option at all.

If I add a rating to a new tracker, the rating is not saved.

Also the rating value star has an opaque white background.

These occur on dev.tiki.org presently.

~~#F00:Update:~~ Still not working on dev.tiki.org revision 48335. {sign user="Bsfez" datetime="2013-11-05T07:14:49+00:00"}

The rating gets saved now but is not displaying. {sign user="pascalstjean" datetime="2013-11-24T00:42:50+00:00"}

~~#F00:Update : ~~ I retested on the 28/11/13. {sign user="Bsfez" datetime="2013-11-28T13:22:50+00:00"}
Not logged i saw that they were 3 votes but could see star on or off;
{img fileId="645" thumb="y" rel="box[g]"}

Once logged i voted and the score was reseted to 0;
{img fileId="646" thumb="y" rel="box[g]"}
---
This worked well in Tiki9., and it's still borken as of r49090 (December 15th). {sign user="xavi" datetime="2013-12-15T10:27:49+00:00"}
If Rating with "Stars (system)" is supposed to be deprecated, could someone please help to switch the rating system in the dev.t.o Bug Tracker ([tracker5]) so that it can use whatever new rating system is not "deprecated"?
This way, since the new [http://doc.tiki.org/Rating%20Tracker%20Field|Rating field is not documented] as of Dec 14th 2013, we could see it here at least as a working example.{sign user="xavi" datetime="2013-12-15T10:39:46+00:00"}
---
Ok, added the new Rating system myself to the Bug Tracker (new field 152: "New Rating"). And it works out of the box. Good job whoever coded the new feature. {sign user="xavi" datetime="2013-12-15T10:45:10+00:00"}

{syntax type="tiki" editor="plain"}
I create the first tracker (tracker01) with three fields.
The tracker has the ID 1 in the tracker overview and the fields have the IDs 1, 2 and 3 in the field listing.
After I create a second tracker (tracker02) it will get the ID 2 in the tracker overview.
But now the second field in the first tracker get lost.

In tiki-admin.php?page=sefurl, we have
* Display blog title in the sefurl
* Display article title in the sefurl

which is really nice.

Even better would be to also have:
* Display tracker item title in the sefurl

So
https://dev.tiki.org/item1000
becomes:
https://dev.tiki.org/item1000-Tracker-mail-in-in-addition-to-forum-wiki-articles

{syntax type="tiki" editor="plain"}
Does the "Users Information Tracker Fields Asked at Registration Time" work for someone in 6.1? it used to work in 5.x. not pretty.

This feature was not particularly important if the trackers with registration="y" would work nicely. Read more here.
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-01-08,Sat&sel=52#l48]

{syntax type="tiki" editor="plain"}
images in trackers are not multitiki aware (they are all saved in img/trackers instead in the img/trackers/site1.org , etc. as for images in img/wiki_up/site1.org etc

5x: tracker comments should allow self-subscribe option for poster, like in forum posts or page comments. Right now, lost of interaction and feedback is lost for users until they learn how to subscribe to tracker items....

That was the same problem in forum posts for years, until some one added that feature to forum posts and wiki comments...
However, it seems that tracker item comments didn't benefit from that enhancement.... and honestly, they deserve it...

---

UPDATE:
* Still a very much desired feature in MANY tiki sites (including *.t.o sites). {sign user="xavi" datetime="2013-11-17T09:30:58+00:00"}
* Still a wish...{sign user="xavi" datetime="2014-07-13T10:00:49+00:00"}
* Still a wish (many years later). Sniff ... {sign user="xavi" datetime="2016-06-28T08:55:07+00:00"}
---
Gorgeus, fixed, Victor! Thanks! (tested in tracker comments, and adapted the profile "Bug_Tracker_15" to allow commenting by registered to easily test/debug this issue also in the future (or in other branches). {sign user="xavi" datetime="2016-10-11T17:21:14+00:00"}
---
Update: {sign user="xavi" datetime="2016-10-11T17:38:28+00:00"}
* emails are duplicated if the user was also selected in a "user selector" type of field, with notifications on. We should check that no duplication of emails is sent: one as commenter, and another one duplicated as user selected in the "user selector" field with notifications on.
See it reproduced in the show instance:
2 emails have been sent in some cases:
http://xavi-9794-3214.show.tikiwiki.org/tiki-syslog.php
u: admin
p: 12345

* Tracker item commented:
+ http://xavi-9794-3214.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
* see email corresponding to each user:
+ http://xavi-9794-3214.show.tikiwiki.org/tiki-adminusers.php
* see tracker field definition:
+ http://xavi-9794-3214.show.tikiwiki.org/tiki-admin_tracker_fields.php?trackerId=1
** note last 3 fields, all of them user selector with email notification on.
---
Update {sign user="xavi" datetime="2016-10-13T10:40:17+00:00"}
In addition, other systems maybe sending a duplicate of the same email message (see https://doc.tiki.org/Watch ), and we'd better add a system to prevent those duplicated emails to be sent.
To be checked for duplicates (and remove them before sending):
# generic (wildcard-like) user watches through the "__My Watches (UI) > Add Watch > Event__"
# Objects
** user watches on objects
** group watches on objects
# Categories
** user watches on categories
** group watches on categories
# Structures
** user watches on structures
** group watches on structures

I'm usure about category watches. Maybe we can leave those messages also, since they are not 100% equivalent to the other notification emails?
---
Sure, see comments. Issue fixed. {sign user="xavi" datetime="2016-10-14T10:13:36+00:00"}
And duplication of emails was due to some other issue, fixed by kroky6 also (great, thanks!).

Tracker item history seems to be unreliable: it works for me on some 6x sites but I haven't been able to make it work in a local 6x or proposals_6x .

# I create a tracker item
# I edit the tracker item again, changing some fields (1 text area, and 2 text fields ) and save changes
# refresh the tiki-tracker_view_history.php?itemId=1 page but I see nothing there

9.x - trunk: Can NOT export fields nor synchronize a big tracker

Smaller trackers seem to be fine with exporting tracker fields.
But with this one, no content is shown in the popup box where the exported fields should be shown.
Somehow I managed to replicate this issue in my localhost in a Tiki 11.x, and I see this error message then:
{CODE()}
Request-URI Too Large

The requested URL's length exceeds the capacity limit for this server.
--------------------------------
Apache/2.2.22 (Ubuntu) Server...
{CODE}

This seems to be related to these two apache directives, that I didn't manage to change in my localhost (or at least, the error didn't dissapear):
# http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline
# http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

Show instance created.
U: admin
P: 12345
To reproduce, try to export all or any of the 167 fields here:
http://xavi-9794-4756.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1

---

I tried also exporting the whole tracker, fields and data through the tracker synchronization feature (), but After I click at the button to "search the trackers to clone" (or similar), at teh remote tracker duplication step, then I get this fatal error page:

{CODE()}
Fatal error: Uncaught exception 'Zend_Http_Client_Adapter_Exception' with message 'Read timed out after 10 seconds' in /path/lib/core/Zend/Http/Client/Adapter/Socket.php:511 Stack trace: #0 /path/lib/core/Zend/Http/Client/Adapter/Socket.php(329): Zend_Http_Client_Adapter_Socket->_checkSocketReadTimeout() #1 /path/lib/core/Zend/Http/Client.php(1075): Zend_Http_Client_Adapter_Socket->read() #2 /path/lib/core/Services/RemoteController.php(57): Zend_Http_Client->request('POST') #3 /path/lib/core/Services/RemoteController.php(26): Services_RemoteController->getJson('list_trackers', Array) #4 /path/lib/core/Services/Tracker/SyncController.php(266): Services_RemoteController->__call('list_trackers', Array) #5 /path/lib/core/Services/Tracker/SyncController.php(266): Services_RemoteController->list_trackers() #6 /path/lib/core/Services/Tracker/SyncController.php(280): Services_Tracker_SyncController->getRemoteTrackerList('http://ueb.vhir...') #7 /path/lib/core/Services in /path/lib/core/Zend/Http/Client/Adapter/Socket.php on line 511
{CODE}

Any help to get the tracker exported, by any means, to another Tiki install?

__Update:__ Clarified some of the description below.

^Please note this field type is marked "experimental" in 12.x^

[http://doc.tiki.org/Action+Tracker+Field|Action Tracker Field] type does not work in Tracker plugin.
I have tried it but no button appears labeled "Reset" on the action field row next to the "Reset Password" in the table.
To reproduce:
General > Name: Reset Password
Options for Action > Name: Reset, Post: get, Script: tiki-remind_password.php, Parameters: name:userName

{img fileId="941" thumb="y" rel="box[g]" width="320"}

__It should render a post or get form or just a button labeled "Reset" pointing to tiki-remind_password.php__ but renders nothing in the Tracker plugin. Maybe it should render below the tracker form in the code to avoid ''form in a form'' conflict and be placed on the row position of the field using jQuery?


It only shows up (while editing the Tracker item) in a special section called
"__Special Operations__".

But clicking the button from there is buggy too. Goes to:
tiki-remind_password.php?name%3AuserName=name%3AuserName&trck_act=Reset

Instead of:
tiki-remind_password.php?name=admin&trck_act=Reset

Actions in tracker fields don't post variables
though they post parameters
I used the example
Register,post,tiki-register.php,name:login,pass:pass,passAgain:pass,email:email,register=register
from tikiorg but doesn't pass any new user
If I use the syntax Register,post,tiki-register.php,name=login,pass=pass,passAgain=pass,email=email,register=register
it works but it doesn't register variables but words (login, pass etc.)

When you create a tracker field Radio Buttons or Dropdown you can set in the options, option field values, labels and ===default selected value===.

''If an option contains an equal sign, the part before the equal sign will be used as the value, and the second part as the label
Separate multiple with commas.''

The tooltip says how to set a value and a label (1=One).

The tooltip omit (it was there at some point for the dropdown) to explain that a double entry will be seen as the default selected value for the field.
IE: 1=One,2=Two,3=Three,3=Three (Three will be the default selected value).

From my understanding, the time (or several times) recorded inside the tracker field duration are some kind of "independent" entity inside a tracker item.

IMO, we should have option(s) to "lock" the time recorded to avoid further changes after an action is done.

IE: If I record the work time of someone and if at some point it is approved or validated it should locked and only an Admin (or a user with permission) would be able to change it or unlock the entry.

by extension may be something simple can be done as a start with the tracker item status.
If open (or open and pending) it can be changed else immutable.
If the item is close durations recorded can’t be changed.

I've been thinking for ages that this kind of option is REALLY needed, and I thought it should not be much coding effort:

Automonitoring each own's posts, through either:
# Add a select box to monitor each own's forum post or tracker submission at post time, in a "per forum post or tracker item insertion" basis, or
# with a user preference for all forums, or all trackers, blogs, etc..
---
Still needed...

I test the field duration on nextdev and suggest some improvements.

I wonder if end-users (not Tiki/Techie) won’t be confused by so many modals, buttons and with many click before starting a simple timer (not happy UX). From the item creation to the timer running it is 4 to 6 six click/selection not to mention other fields that may be in the trackeritem.

Actually to user the timer function you have to give a title, a descriptopn and you have more options. That’s is good if you have ONE item and you will attach to it SEVERAL durations. While you are limiting yourself with the information you can attach with a duration.

It make more sense to me to create ONE item per duration and use the item fields to attach what you need with it. (label, description, date, reason, category, etc). Then using trackers or list plugins you can do whatever you want and use whatever you want. In that case the user can see a simpler version of the timer with a start/stop/pause (reset?) buttons only.

We could have an in the tracker field options an option to have only ONE duration recordable per item simplifying everything. So both case are covered.

I test the field duration on nextdev and suggest some improvements.

It is really nice and complete however came to me 2 fears when it will be under the hand of end of users (not a Tiki/Techie user).

User will forget it.
Imagine having it running on a mobile device for a training sessions or as employee workclock. People will forget it is running quite easily.

In the tracker field options I suggest we add (simple) alerts parameters:
* enable alert (this duration is running)
* every 15mn, 30mn, hours, 5hours, days... (more seems to me too much, but...)

I suggest also we add a limit (after what we stop the timer)
* After [ ''value'' ] [mn,hours,days] stop the timer (a notification will be displayed)
* Send a mail notification
** to the admin
** to the user/owner of the item
** to this mailbox [''value'' ]

add antibot captcha for anons to newsletters, calendars and tracker item comments

There is a parameter "Update Empty" in the tracker field type.
I don’t see any documentation about it but it is supposed to add auto-increment numbers to items in this tracker that don't have one yet.

I tried it on Tiki18 it didn’t filled the empty fields.

After testing it it seems a auto-increment number is added to empty fields if "itemId" is not the parameter selected. Would be nice to fill in this case too and not to have the admin to open and save each item.

{CODE()}
Update Empty
Add auto-increment numbers to items in this tracker that don't have one one. ********** N.B. This modifies data and there is no undo **********
{CODE}