Category: Consistency

in full screen mode, the column headers take the full width of the screen instead of staying the same size as the columns. (see screen shot)

{img fileId="589"}

When you extend one of the two drop down menus ("View" and "Style") two things can be observed (besides the fact that View and Style do not translate): The menus are in the background, i.e. ''behind'' the icons... They should extend in the foreground, thus be painted over the icons, partially obscuring them...
Thanks
hman

The history of Spreadsheet completely ignores all date und time rendering prefs, and renders timestamps in US format, see screenshot (attachment).

Also note that the "compare" button doesn't translate due to a missing tra().

Noticed here: https://dev.tiki.org/Tiki12

I am pretty sure Tiki11 was fine. I will make a screenshot of Tiki11 on another site

If I have a tracker here I store people from many cities. And every city has its page with a plugin trackerlist what filters just the people in that city. So the people can "see" each other.
But
You can play around in the adresslist of the browser to find out the data from people of the other city (what i shoudn't see.
Thats not nice!

=> Solved by upgrade from 12 to 17
{sign user="Torsten" datetime="2017-10-26T22:06:38+00:00"}

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

This is a new formulation of 3029 problem after near 200 hours of test and debug.

!The problem is now precise and near solution :
I can't affirm that I wrote debug because the execution stop on another problem.
The time spend is not only on TikiWiki, a had to solved installation problems and find a bug into easyphp and addresses resolution on the server.
The problem began with 4.1 and php 5.3.0 and I upgrade to 4.2 and 5.3.2 to be sure of the problem and the available solution.

!Span of the problem :
# Definition of main classes TikiDb and TikiDb_Pdo and PDO->function execution
# Progs : tiki-db-pdo.php, tikisession-pdo.php and naturally pdo.php, tikiDb.php
# PDO extension and behavior of objects and classes

!Description
note : Because I found the nature of the problem, I don't start from the nature of the crash but the analysis, but I produce a selected track made with xdebug var_dump)

# In tiki-db-pdo.php:40 we create the Pdo object
<$dbTiki = new PDO("$db_tiki:$db_hoststring;dbname=$dbs_tiki", $user_tiki, $pass_tiki); >

# just later In tiki-db-pdo.php:49 we set the singleton of TikiDb_Pdo into TikiDb abstract class with scope operator
<TikiDb::set( new TikiDb_Pdo( $dbTiki ) ); >

# further we call In tikisession-pdo.php:28 we can find the session read
< $sth = TikiDb::get()->prepare($qry); >
This instruction generates the fatal error :
__ Fatal error: Call to undefined method TikiDb_Pdo::prepare() in D:\Trebly\Teawik-ld8-422a\lib\tikisession-pdo.php on line 28__

!Explanation and solution implemented
The reason is simple and explained by the error comment :
we try to run the prepare function which is a PDO function on a TikiDb_Pdo object which has no reason to inherit of these Pdo function even <TikiDb::get()->db->prepare> could have a meaning.

Then the solution is in what is made in ZEND lib (not yet used), create an interface to PDO into Class TikiDb_Pdo.
This functions and it is written.

! A major question
One important question is why and how the same instructions seems to be available and functions well on Linux (I have a site which runs normally with 4.1, not yet upgraded to 4.2, a to-do)

I believe that the actual solution that I have developed for 4.2 on Windows with PDO (compiled) extension, should be extended to the normal version.

As I have said before I can't confirm completely that the solution is correctly tested and free of bug because, the program have a FATAL ERROR PDOException: SQLSTATE[HY093] later on the prefs restoration I create another report for this.

Note :
the execute statement written execute() without parameter generates each time a warning message when xdebug is activated with STRICT option (default in 5.3.2) for errors handling in php, and necessarily makes the code lightly slower. I developed an enhanced error template according to the error handler which displays much more informations about the context and, into these, the parameter (title) of execute statement. This make an enhancement to find much more quickly the errors.

The diagrams of site statistics cannot handle if in the translation diacritic characters like German umlauts are used, instead some random looking special characters are rendered. In German "FAQ" are "Häufige Fragen"...

See:
{img fileId="1248" thumb="box"}

TW really should not be sending spoofed e-mails.

Wiki content watches, Structure Watches, Tracker Notifications etc use the system wide sender e-mail address as set on Control Panel -> General in the Mail sub section of that page to send their notification e-mails.

However, it seems as though e-mail notifications generated by the Inter User Messaging system don't use this system wide sender e-mail address. Rather it sends messages with a spoofed e-mail address of the user who is to receive the e-mail.

As Mail Service Providers rightly tighten their spam filtering techniques, Message notification e-mails sent by TW are getting impacted.

Might TW avoid this issue by providing admins with an option to also use the system wide e-mail sender address for Message notification e-mails, please?

Yet another bug with the strange layout of the calendar feature. I created one event, that spans several days, each of them for the whole of that day. On all days this event is painted at the top of day, in the view that you get when you click on the event in module (that I placed left). All of them.

Except for the very first. Seemingly because of no reason at all it appears vertically centered... See attachment.

Thanks
hman

In lib/prefs/wiki.php there is a strange feature name I cannot translate. After the experience with all the tabs and newlines and stuff in feature.php, I did check this string with a hex-editor: No special characters. It as plain as it looks: "inline auto-toc". And it is correctly pumped through tr(), so it should translate. But it doesn't. Event if I copy & past this string directly. Please have a look at line 706:

{CODE(Colors="Tiki")}
'wiki_inline_auto_toc' => [
'name' => tr('Inline auto-toc'),
'description' => tr('Change the display of the table of contents for wiki pages to inline.'),
'type' => 'flag',
'default' => 'n',
'dependencies' => [
'wiki_auto_toc',
],
{CODE}

Check
https://dev.tiki.org/How-to-release

vs

https://dev.tiki.org/How-to-release?structure=Developer+Documentation

{syntax type="tiki" editor="plain"}
When the system is set up to use staging & approval and the Structures are turned on, pages/topics created using the Add Page feature included with Structures get created with a staging name. The structure fails/disappears when the page is approved (fails in that the structure loses the staging name and does NOT substitute in the page without the staging name).

On Tiki structure you can have one or several top page and its subset of pages inside the structure.
If you edit your structure "tiki-edit_structure.php" and delete a page ALL the subset of pages will be removed from the structure without a warning.

First a warning should tells the user is about to remove the subset of pages (this can be catastrophic !).
I think a question should be asked about it;
You are removing page of a structure that has a subset of pages:
❑ Remove all the child pages from the structure ?
❑ Keep the page in the structure (they will be moved to the next top page) ?

When you create a new structure you can fill a tree.
This will create subset pages inside the structure.
Below this you can "Categorize" (no more explanations).
As result only the first page will be categorized.

On a Tiki 25 I tried 3 times and I couldn't see any message about the page(s) categorization and only the first page was categorized.

On a fourth attempt (different structure) below the success feedback for the structure creation I could see a feedback about categorization of pages but only the first page was categorized.

On a fifth attempt (different structure) all pages added were categorized.

First, there should be some help the user to understand what will be done about it. (structure and subset of pages will be categorized).

Second... it should work all the time. 🤷🏻‍♂️
I still need to find a way to reproduce...

{syntax type="tiki" editor="plain"}
Here:
http://doc.tikiwiki.org/tiki-index.php?page=Structure&structure=Documentation -> structurs is 8.48

Yet, here: http://doc.tikiwiki.org/tiki-index.php?page=Documentation&structure=Documentation , it is 4.31


I don't understand the 8.48

Should be 4.31, no?


See related chat log:
http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2008-12-16,Tue&sel=315#l311

Hello,

The default templates displays paneled hierarchical menus.

The second level must test is bottom position so that it will display a bottom arrow to scroll the options naturally hidden by the window inferior (here) limit.

For the moment the second level menu panel is truncated : this is a BUG.

So the user must understand or prepare by a general scroll (if possible) to allow a sufficient place to the menu to be displayed

trebly

In order to get it translated, I enabled the survey feature. It's admin GUI is highly confusing and counter-intuitive. After enabling, you can enter the admin GUI and create a survey, so far absolutely intuitive. But then you are stuck. You have entered a name and a description, but no questions! They are simply no part of the process of creating a survey ?!

In order to create questions, you have to go to list surveys, and from the properties of the wrench icon you can go to questions, tiki-admin_survey_questions.php?surveyId=NN

In the upper left corner is a large button labelled "Add a new question", which is completely void of any function (!), because it only links to the very same page (tiki-admin_survey_questions.php).

Over the (now still empty) list of questions is a (compared to the large functionless button) rather unspectacular text written in blue "Add a New Question to this survey". This seems like the same function as "Add a new question", but it isn't at all:

This, and only this, will link to tiki-admin_survey_questions.php?surveyId=NN#contenttabs_adminsurveyquestions-2 and give the user the means to create a question.

Surveys can have more than one question, that is fine. But questions are per survey only, questions do not form a pool, i.e. it is impossible to create a question and use it in more than one survey. That is impractical.

Also, the questions property of the wrench always directs to the creation of new questions, and does not (at first) show the list of existing questions. They can be listed with questions tab, yes, but it's counterintuitive to always start at creation and not at the list of existing.

We have no syntax for expressing we want an unlimited number of LIST plugin results.

Using mysql Full-Text indexation, one can express the idea with a huge number like so :
{CODE()}{LIST()}
{filter field="object_type" content="trackeritem" }
{filter field="tracker_id" exact="1"}
{pagination max="99999999"}
{OUTPUT(template=)}
{LIST}{CODE}

It is ugly but it does the job in an expressive way (people will understand 99999999 does not mean exactly 99999999).

Using Elascticsearch, the above will fail with an obscure error message « all shards failed » because Elascticsearch has a hard limit which defaults to 10000 but it can be changed at the server level.
See ''Results Per Query'' in [https://www.elastic.co/guide/en/app-search/current/limits.html]
So I need to use:
{CODE()}{LIST()}
{filter field="object_type" content="trackeritem" }
{filter field="tracker_id" exact="1"}
{pagination max="9999"}
{OUTPUT(template=)}
{LIST}{CODE}
Because "10000" looks like I really want "10000" rather than unlimited.

__It is bad that the LIST plugins need to be rewritten when one changes the unified search indexation method.__ Also, it is not obvious why it fails.

__SUGGESTION__ I feel we should allow for a real syntax for unlimited results such as :
{CODE(caption="SUGGESTED SYNTAX" theme="default")}{pagination max="-1"}{CODE}

Then if Tiki uses Elascticsearch searches it could look up the ''Results Per Query'' value (or assume 10000 for starters) when "-1" is encountered.
If Tiki uses "Mysql Full-Text search" if should not have a limit (or it should have a very high one).

t.o calendar: warn the user about the time zone being used at time selection by the user

I added an event at a calendar in Tiki.org community site, and selected the chosen time for the event (13h UTC).
https://tiki.org/tiki-calendar_edit_item.php?viewcalitemId=142

There was no indication of which time zone was Tiki going to understand for my selection, so I chose the time in my time zone: 15h (UTC+2). Tiki stored that time as if it was at 15h UTC, and then display the time of the saved event to me as 17h (UTC+2).

So Tiki was expecting the user to introduce the time in UTC, apparently, but there was no indication about that to the user. Some info should be shown. Maybe that will depend on the settings being set in the tiki site (there are a few combinations to test, I guess). So at least I'll leave the bug report here about it.

I recall Jonny saying that there was some new jquery library that was aware of time zones for time and date pickers? :-)
---
In addition, the time recorded for the item doesn't match the time the user selected in the edit form, or even shown when the user opens the item for edition again. This type of issue seems to have been solved recently (months) in tracker fields date and time (date picker, by developer kroky6), so it may probably just need porting similar fix to the calendar feature itself {sign user="xavi" datetime="2017-01-12T14:51:14+00:00"}

I instaled a tiki site using tiki 3 svn. Installed collaborative community profile (althought it might not affet the bug). Just in case, this implies: strasa.css

When the user goes to admin trackers i order to import a tracker from another tiki site, there is not tab for "import export" (at tiki-admin_trackers.php). However, the interface is under the tab "Duplicate tracker".

Later on, when you have trackers, you see the tab, but not at the beginning.

Tablesorter doesn't allow to filter on Tracker item status

See it reproduced here:
https://dev.tiki.org/Trackers#Pending_and_Closed

Tablesorter doesn't allow to sort on tracker item status

See it reproduced here:
https://dev.tiki.org/Trackers#Pending_and_Closed

Reproduced here:
http://xavi-9794-6037.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12#contentTracker_as_Calendar_Tabs-2
u: admin
p: 12345

See field "Location" shown as text input field, evevn if defined as dropdown.
When you change the param server=y to server=n, dropdown is shown as expected.

See this code:

{CODE()}
{TRACKERLIST(trackerId="6" fields="20:27:31:33:34:43:46:36" showstatus="y" status="op" sortable="y" server="y" editable="43" tsfilters="type:text|type:text|type:text|type:text|type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31|type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31|type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31|type:dropdown" showlinks="y")}{TRACKERLIST}
{CODE}

The tsfilters code __type:date;format:yy-mm-dd;from:2016-06-01;to:2016-12-31__ is now {sign user="xavi" datetime="2016-08-12T09:19:21+00:00"} in trunk applied (so that items without date or not matching the date range are filtered out), while in Tiki 15 they were just used to preselect the date of the rate range filter, but those date ranges were not applied (items without date or not matching the date range where also shown in the results of the table).

---
If this is confirmed as a regression and fixed in trunk, I reckon that we need to revert this commit I made before I knew that this looked like a regression:
{CODE()}
[ENH]Warn the user that this apparently is the new default behavior for 16.x. Probably feature fix since it makes more sense to be like this, but it was not the default behavior until short ago, afaik. Subversion: Committed revision 59430.
{CODE}
---
Fixed reference to affected branch. It was trunk, and at the time of the bug reporting, that meant 16.x. This issue is not seen any more in 16.x, however, it is in trunk still. Therefore, I tagged it against 17.x and 17.x regression. {sign user="xavi" datetime="2017-01-03T23:23:27+00:00"}

Reproduced here:
http://xavi-9794-6200.show.tikiwiki.org/tiki-index.php?page=Bug6201
Last column for LastModif
u: admin
p: 12345

Currently using:
Last update from SVN (17.0svn): Tuesday December 13, 2016 15:09:21 CET - REV 60628 (MyISAM)

And using 16.x, reproduced here:
https://demo.tiki.org/16x/tiki-index.php?page=Homepage+for+user+Gc
u: admin
p: 12345