Category: 15.x

1/ Wrong calculation

There is some issue with the the filtering on status (open, pending, close) and the item count.

The average is calculated on the TOTAL of the item in the tracker and not on the total of the item displayed and thats wrong.

Fixed : https://sourceforge.net/p/tikiwiki/code/61412/

2/ Item list fields are not displayed properly.

See instance.

To reproduce:
#Enable the JQuery upload feature
#Edit a page and upload an image using the icon "Choose or upload images"
#Save the page
#Then you decide to change that picture: Click the img plugin helper icon below the image
#Click the icon next to the fileId field to upload new image insted of the current one
#Upload the image then click it - it should replace the ID 1 with ID 2 but instead it inserts the whole wiki syntax and messes up the img when saved

Kind of an edge case, but if layout theme names change between versions or due to development work, so there's a mismatch between the stored layout preference and the layouts listed in the files, then a blank screen is the result. The database needs to be edited directly to correct the problem (tiki_preferences site_layout updated to match available layout names).

There should be a fallback to a default layout ("basic") if the preference name isn't found, similar to how the site will fall back to the default theme if the selected theme or stored-preference theme isn't found.

When using the WYSIWYG plugin (to edit the contents of a call to the WYSIWYG plugin), a line break is added at the end of the call when saving.

This happens in Tiki 15, but did not happen in Tiki 12, as a result of r55910. However, the proper fix is to leave tiki-ckeditor.js as-is and to instead modify parserlib.php as shown in the attached patch. This dirty patch also solves issue #6592.

When using the WYSIWYG plugin to edit the contents of a call to the WYSIWYG plugin containing several consecutive line breaks, some of these newlines can be removed when saving.

This happens in Tiki 15, but did not happen in Tiki 12, as a result of r55910. This can be solved by removing the line added in r55910, as shown in the attached patch. This patch also solves issue #6591. But I've ended up only applying the changes to parserlib.php due to issues described in my third comment in #6591.

Hello team,

this may be the same for other types of code, but I have encountered this issue with XML because that's all I use.
Whenever you add bits of XML code between {CODE} tags in wiki-syntax mode, when you save, the code is displayed correctly. However, if at any point (before saving or when editing) you switch to WYSIWYG mode, and then save again, the code is not displayed.
If you switch back to wiki-syntax mode, the code has completely disappeared and is lost.

This is an issue in the sense that I only use wiki-syntax as the main contributor to our wiki, but the users may need to complement or amend some pages for whatever reason, and they need to use the WYSIWYG editor, otherwise they get swamped in the wiki-syntax.

Importing of a XML zip fails.

Attached is an XML zip created on 12.x

This is a php7 issue. It works fine with php 5.x

PHP Error: PHP Parse error: syntax error, unexpected 'new' (T_NEW) in /Sites/tiki/vendor_extra/pear/XML_Parser/Parser.php on line 611

Tiki show instance not useful as its hosted on php 5.x

I have a xml.zip attached for trial reasons, but it does not matter what is being imported, it all fails.

XSS Sanitizations seems to amend some input strings in the wiki / blog editor with an ~np~~/np~. The ~np~~/np~ is filtered out again when the text is being displayed to a user.

This works for normal text, but not when a reserved word appears in a link.

Example:

[http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/eval|eval|nocache]

~np~[http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/eval|eval|nocache]~/np~

The ~np~"eval"~/np~ string in the link will also be changed to ~np~"eval"~/np~, but the ~np~~/np~ will not be removed when the link is being displayed, so it doesn't point to a valid destination anymore.

Expected result: The link is displayed correctly.

Using URL-Enoding on the affected strings as a workaround is possible, but a nuisance.

This happens regardless of whether the HTML Purifier function is active or not.

While working on a profile with exported preferences from -+tiki-admin.php?page=profiles&cookietab=2+- I have realized when trying to apply that YAML code as a ((doc:Local Profiles|local profile)) using the following command:
-+php console.php profile:apply my-preferences profiles+-

the result is fatal error:
{CODE()}PHP Fatal error: Unsupported operand types in /var/www/clients/client1/web16/subdirs/.../lib/core/Horde/Yaml/Loader.php on line 363{CODE}

The problem is my profile YAML file (which I saved as -+my-preferences.yml+- in a -+profiles/+- dir) contains one line preferences like this:
{CODE()}
preferences:
main_shadow_end: {if $page eq "HomePage"}</div>{/if}
main_shadow_start: {if $page eq "HomePage"}<div class="home">{/if}
...
{CODE}

When I change it to the multiline syntax (notice the "|" character and new indented line):
{CODE()}
preferences:
main_shadow_end: |
{if $page eq "HomePage"}</div>{/if}
main_shadow_start: |
{if $page eq "HomePage"}<div class="home">{/if}
...
{CODE}
then it works with no fatal error anymore!

What can we do to fix this? Fix the YAML exporter somehow to detect if there are any operands like ~gt~ or ~lt~ and if yes export the preference value as multiline even when it is just one line of text?

Anything else?

Thanks for your time reviewing this bug.
luci

In a calendar, using the "calendar" view and "day" mode, the event information is held in a div id="event_1" that has a z-index of 100. If the event is all day, then the div fills the complete area to the right of the hours column. If I click on the calendar filter button, then a popover is displayed at screen center titled "Group Calendars". But this popover has a z-index of just 1, so it displays under the event information. (The text of the event information is over the popover text and background.)

It isn't obvious why the event information needs a z-index: 100, but maybe it does. Or maybe another fix is possible.

This was working in previous versions of Tiki (maybe 9.x?). I couldn't check when the regression was introduced.

popup box to select visible calendars shown underneath events details (using fullcalendar)
In 15.x: Using theme "Default bootstrap", but also reproduced with fivealive-lite, etc.
In 12.x: using default theme style (fivealive)

See it reproduced in 15.x here:
http://xavi-9794-5901.show.tikiwiki.org/tiki-calendar.php?todate=1459413360
u: admin
p: 12345

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

To see it reproduced in 12.x, visit:
http://xavi-9794-5904.show.tikiwiki.org/tiki-calendar.php?todate=1459461600
u: admin
p: 12345

15.x: Recalculate mathematical calculation tracker field at indexing time fails
The tracker field was set to that option: Recalculate on indexing.
If you set the tracker field to recalculate on save, it works as expected.

12.x - 15.x: Tracker: filter items is broken when radio button with labels set (0=No,1=Yes,2=Dunno).

No matches are found when there are some items which met the intended criteria.

--It'll be-- reproduced in an attached intance --in short. Stay tuned!-- :-) {sign user="xavi" datetime="2016-02-09T12:21:27+00:00"}
Login in here:
http://xavi-9794-5810.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1
u: admin
p: 12345

You will see the field TestRaduio, with some values (0, 1 and 2; their labels, in fact)

Try to filter by that field:
http://xavi-9794-5810.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=f__asc&filterfield=8&filtervalue%5B1%5D=&filtervalue%5B2%5D=&filtervalue_other=&filtervalue%5B3%5D=5+%28high%29&filtervalue%5B8%5D=0%3DNo&filter=Filter#
---
__Update:__ {sign user="xavi" datetime="2016-02-10T10:42:06+00:00"}
the problem is also found (and still unsolved) at teh trackerfilter level. Sorry, I tried for one hour, but I couldn't get the right syntax to port this type of fix there also. :-/
To reproduce, see it here:
http://xavi-9794-5810.show.tikiwiki.org/tiki-index.php?page=HomePage

__The issue is reproduced also for dropdown fields when labels are set, etc. See it reproduced with field "Priority" (Dropdown). __

__Reproduced also with "Dropdown with other" (field __Location__) in the tracker itself, but it works as expceted through Plugin TrackerFilter.__
Does work:
http://xavi-9794-5810.show.tikiwiki.org/tiki-index.php?page=HomePage

Doesn't work:
http://xavi-9794-5810.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=f__asc&filterfield=2&filtervalue%5B1%5D=&filtervalue%5B2%5D=0%3Droom+1.1+%2855+seats%29&filtervalue_other=&filtervalue%5B3%5D=5%3Dhighest&filtervalue%5B9%5D=y&filtervalue%5B10%5D%5B%5D=1&filter=Filter#

Multiselect seems to work well, as expected, in both tracker itself and plugin trackerfilter.

Please, whoever introduced the UI change that did hide the preference filters, please, please, please, expose them back to new tiki admins, since there are tons of support requests in many tiki sites out there about new site admins (even experienced php developers) not finding the preferences that they are looking for in the Control Panels, also following the documentation pages in doc.t.o about them, etc.

This is also affecting people creating show.t.o instances to report bugs and not finding the preferences, etc.

I tried myself but it was beyond myskills when I had a quick look at that, and I was fearing to break some tpl/css, so I'd rather leave ir for an aexperienced UI developers, or even better, to whoever introduced this usability regression (back in Tik1i3 or 14 days, probably?)

Thanks

I get a 404 error while switching from http://dev.tiki.org/tiki-utilities-modal_alert?controller=tracker&action=update_item&fullscreen=n, into full screen mode. That is the page that one is redirected to (and populated with information, unlike if you just navigate to it) That one finds themselves on after updating a bug report.

Ive tried to re-create it by navigating directly to that url, and the 404 does not appear. Im presuming the page content plays a role in this.

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!).

__Describe precisely what you did (how to reproduce)__
On my own Tiki site at http://thepatriotwoodwiki.org/HomePage the Categories load very slowly. This is a known issue when large sites have excessive content in categories.

My tiki was performing well, I have very few items on my site, actually my site is still new with little content and a few categories, until I loaded the "Countries by Region" profile. Once the Countries categories were loaded by the profile, the categories section would not open, or would eventually open.
I understand there is a performance issue with massive content on a Tiki, but the categories are empty.

__Describe exactly the faulty consequences__
When the Categories tab is clicked, the categories page will not open, or will eventually open.

__Explain what you expected instead of the faulty consequences__
I had expected the Categories section to open quickly as the rest of the Tiki does.

The release script checks the syntax of all php files so we need to add a way for each branch to warn when using a newer version of php than the min spec version for that branch.

I know how to do it, just need time so this is a reminder to myself ;)

Add checkbox to tag forum thread as 'expected feedback obtained', or [[SOLVED], and allow filtering and reporting based on that also

Similar to filtering closed item with the chance to reopen, but for support forums and without closing the threaf, but at least indicating to power users that they'd better search first other threads that still require support.

Like the [[SOLVED] manual tag renaming the thread subject in a later stage by the poster of the new thread.

Also show these type of unsolved threads in clear way in the daily reports messages

Add filter param to Plugin TrackerStat (to easily display graphical bars of tracker item answer counts from filtered results)

((doc:PluginTrackerStat)) is an easy way to display results from data in trackers. Trackers can be used to produce advanced custom surveys, and we could use on e single tracker to collect data from different semesters, years, projects, etc., but provide a simple interface to show a filter before showing results of bars with counts, etc., so that the use can choose in a central point which fields wants to use to filter data from a tracker.

This might be solved someway with plugin list and custom search and some tricky advanced display output or format syntax, but this in currently (as of April 2015) undocumented, and even if this might be feasible by experienced devs, it's not going to be as easy for endusers to be reproduced than just using the easy TrackerStat plugin with a new filter param, (similarly to the param filter in PluginTrackerList of TrackerFilter)

---
See some show instance with a call to TrackerStat already in place, if you want a snapshot of a working instance as a base tiki to get your development tests going.

http://xavi-9794-5261.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

add history & rollback capabilities to structures (record dump somehow when struct. changes, or allow saving structure dump for backup...)
This way, when the structure gets mixed by machine or human error, the structure can be rolled back to the previous state.

This way, we could be more open for registered users to manage http://doc.tikiwiki.org/Documentation (or others) without the risk of failure when nodes get moved to the wrong place (due to some bug in the code). Or due to mistake by benevolent newbies mixing things without bad intention.

---

UPDATE: Still desired for some LTS version. {sign user="xavi" datetime="2013-11-17T09:31:50+00:00"}

Right now, if you have a multitiki installation with 10 sites, and you want to rebuild the unified search index for them all, you have to run 10 times the command with the "--site=" para adapted to each case.

However, when you run setup.sh, by default setup.sh runs for all sites in a multitiki installation.

It would be nice if console.php had the chance (by default or not) to be run once for all sites in that multitiki installation at once


with some param like "--site=all":
{CODE(colors="shell")}
php console.php d:u --site=all
{CODE}

Add tablesorter UI to Payments list for easier filtering of real data when many payments done.

Currently there is even no pagination at all. So when many records are there, it's not easy to find who payed whet, when, by whom, etc.

---
We have a dbdump already with a few data on it (of real small transaction with paypal), that we could share with a dev willing to implement this feature, in case this helps the development with fake-ish but real transaction data from paypal in production, not sandbox.
At: http://15x.notre.website

Please, ask me, for instance, and I'll fetch a db dump for you with admin pw reset for you.

Some characters inserted using the special characters palette into an article cut the text of the article behind the new character off after saving the article. When still in edit mode, the preview shows the complete text.
I tested a few greek characters, since we need them. Test items can be both omegas, but other greek characters cause the same problem.