Category: Bug
Tickets reporting bugs. Some bugs reports can be categorized in more specific categories such as "Bug::Security" and do not *have* to be directly categorized in this category, but it is never an error to categorize a bug report in this category.
Show subcategories objects
| Name | Type |
|---|---|
| Bug or feature in tra() ? | tracker item |
|
Bug when saving with French language
Hello, Updating an article, there is a problem of images not saved when the Tiki interface is in French, image disappear from the article. The problem do not occur when the interface is in English or other language. I have fixed the problem and the solution I found is on your forum, ((https://tiki.org/tiki-view_forum_thread.php?forumId=6&threadId=76791&comzone=show|here)) https://tiki.org/tiki-view_forum_thread.php?forumId=6&threadId=76791&comzone=show Sincerely Patrice |
tracker item |
|
Bugs that cannot be explained?
There are also those bugs, whose inner workings look like a miracle to someone who is not familiar with the code. For instance, I cannot translate "Sticky Popup" from the admin page of calendar. There are two different features by the same GUI (!) name on lines 62 and 826 of /lib/wiki_plugins/wikiplugin_trackerlist.php: {CODE(Colors="Tiki")} 'stickypopup' => [ 'required' => false, 'name' => tra('Sticky Popup'), 'description' => tra('Choose whether the popup tooltip will stay displayed on mouse out (does not stay open by default)'), 'since' => '2.0', 'filter' => 'alpha', 'default' => '', 'options' => [ ['text' => '', 'value' => ''], ['text' => tra('Yes'), 'value' => 'y'], ['text' => tra('No'), 'value' => 'n'] ] ], [...] 'calendarstickypopup' => [ 'required' => false, 'name' => tra('Sticky Popup'), 'description' => tra('Calendar item popups will stay open if set to y (Yes). Not sticky by default'), 'since' => '6.0', 'doctype' => 'calendar', 'filter' => 'alpha', 'default' => 'n', 'options' => [ ['text' => '', 'value' => ''], ['text' => tra('Yes'), 'value' => 'y'], ['text' => tra('No'), 'value' => 'n'] ] ], {CODE} As you can see, both (!) call the translation subroutine, and both (!) have a description, so that help string should be visible under a blue question mark icon, next to the feature checkbox on tiki-admin.php?page=calendar, but they don't !! And I cannot translate the name, so it shows only "Sticky Popup" and the checkbox, and that's it. The reason must lie deeper than what I can see in the code by going over it... And yes, I did check that the space between "Sticky" and "Popup" is really a space (0x20) and not something weird like a shift-space... Pls see the attachment. |
tracker item |
|
Buttons for Toggling Items Display Incorrect Results
{syntax type="tiki" editor="plain"} The buttons to toggle between open, closed, and pending items are not working as expected. Below are the observed issues: __Open Items Button__: Clicking the button to toggle open items displays pending items instead. * Expected URL: https://dev.tiki.org/tracker5?status=o&sort_mode=created_desc * Actual URL: https://dev.tiki.org/tracker5?status=p&sort_mode=created_desc __Pending Items Button__: Clicking the button to toggle pending items displays open items instead. * Expected URL: https://dev.tiki.org/tracker5?status=p&sort_mode=created_desc * Actual URL: https://dev.tiki.org/tracker5?status=o&sort_mode=created_desc __Closed Items Button__: Clicking the button to toggle closed items displays all items instead. * Expected URL: https://dev.tiki.org/tracker5?status=c&sort_mode=created_desc * Actual URL: https://dev.tiki.org/tracker5?status=opc&sort_mode=created_desc __Steps to Reproduce__: #Go to https://dev.tiki.org/tracker5. #Click on each of the toggle buttons for open, pending, and closed items. #Observe the items displayed and compare them to the expected results. __Expected Behavior__: Each button should toggle the correct set of items: *Open Items Button → Displays open items. *Pending Items Button → Displays pending items. *Closed Items Button → Displays closed items. __Actual Behavior__: The displayed items do not match the button's intended functionality, as outlined above. |
tracker item |
|
Calendar : No way to create a calendar
When you want to add a new __Calendar__ by adding all the related information, for example __Name__ and __Description__ and when you click on __Save__, you are redirected to __tiki-admin_calendars.php#contenttabs_admin_calendars-1__ but the __Calendar__ is not created. I was using Chrome Version 75.0 and Opera Version:60.0 |
tracker item |
|
Calendar class 'opaque calBox' broken
The class 'opaque calBox' from the calendar is broken. It is supposed to show the details of a calendar event, insted it shows raw Tiki syntax, in the case of a test event from admin on my site it is this that gets presented as text (!) to all users: {CODE(Colors="Tiki")} <div class=\'opaque calBox\' style=\"width:200px\"><a href=\"tiki-calendar_edit_item.php?viewcalitemId=323\" title=\"Details\">Testevent #3<\/a><p class=\"text-muted\"><strong>Erstellt von:admin<\/strong><\/p><br><\/div> {CODE} |
tracker item |
|
Calendar crashes in Year mode
When you switch calendar into year mode, 23.0vcs immediately crashes with these errors: {CODE(Colors="Tiki")} NOTICE (E_NOTICE): Undefined index: openidconnect_details_url At line 52 in lib/OpenIdConnect/OpenIdConnectLib.php NOTICE (E_NOTICE): Trying to access array offset on value of type null At line 178 in lib/OpenIdConnect/OpenIdConnectLib.php NOTICE (E_NOTICE): Undefined index: optionId At line 100 in lib/smarty_tiki/function.menu.php {CODE} Demonstration available at the show instance attached to bug report https://dev.tiki.org/item7666-Impossible-to-create-menus#showtikiorg236_7666_view Thanks hman |
tracker item |
|
Calendar does not show creator of events in mouseover
When placing the mouse over an event in the calendar, a mousover popup comes up informing of the event's text and it's date/time (or duration .i.e. whole day). That is nice and comes in handy, thanks for that But: After those lines comes "created by" and then nothing. It can be debated whether or not the event's creator should be displayed, but even if some rule somewhere dictates that the creator is NOT to be displayed, then the line "created by" should IMHO also be omitted. Thanks hman |
tracker item |
|
Calendar inexplicably jumping when in quarter mode
When the main calendar is in quarter mode, skipping to next or previous quarters is completely inexplicable. I skip the discussion whether or not quarters should be aligned to years. One could argue that the first quarter starts with January (method #1). But it could also be assumed that it starts with the current month (method #2). Personally, I am undecided on this. But the problem is somewhere else, and it is severe. If you switch to quarter mode starting today (today is February 6th) you end up here: /tiki-calendar.php?viewmode=quarter which displays February through April. That can be considered correct (see the above caveat), being method #2. Then a click on "Previous Quarter " SHOULD bring you to November through January. But it doesn't. It brings you to October through December. This is wrong, because this is method #1, while the start was method #2. Tiki's calendar cannot asssume both, and switch between them... Further, if you go another quarter in the past, you will get two possible correct results: Assuming method #1 you would get July through September. Assuming method #2 you would get August through October. Calendar does none of those, it yields June to August... |
tracker item |
|
Calendar localization breaks layout
The German localization breaks the layout of the calendar list list mode. If an event spans several days, and each of those days are entirely covered "whole day" calender obviously introduces the text "whole day" in that. But in the German localization it reads "den ganzen Tag" which is considerably longer in pixels than "whole day", and thus breaks the layout, overwriting the finishing date of the event. Either the localization has to be abbreviated, or the layout should adapt to the rendered length of the text in pixels... Not really an important bug, but looks really awful... |
tracker item |
|
Calendar template tiki-calendar_nav broken
The template displays arrows to navigate to the previous and to the next period the calendar shall display, but the template pumps the raw internal values into the tooltips, and even that without translation, breaking the GUI, because "Previous" and "Next" get translated into the target language, but not the period label (e.g. "week") so giving the user a mixture of target language and English that is actual raw Tiki code. {CODE(Colors="Tiki")} {*previous*} <div class="cal-prev" style="display:inline-block; padding-right: 6px; position: relative; bottom: 20px; right: 100px"> <a class="tips" href="{query _type='relative' _ajax=$ajax _class='prev' todate=$focus_prev}" title=":{tr _0="{$viewmode|escape}"}Previous %0 {/tr}"> {icon name="previous"} </a> </div> {CODE} and {CODE(Colors="Tiki")} {*next*} <div class="cal-next" style="display:inline-block; padding-left: 6px; position: relative; bottom: 20px; left: 100px"> <a class="tips" href="{query _type='relative' _ajax=$ajax _class='next' todate=$focus_next}" title=":{tr _0="{$viewmode|escape}"}Next %0{/tr}"> {icon name="next"} </a> </div> {CODE} |
tracker item |
|
Calendar uses wrong permissions
I have created a calendar in my 18.3 installation. This is to be the first calendar, others will follow. The first shall be world-readable, but writable only to registered users. The later calenders will also have read-restrictions to registered users, but at the moment they still don't exist. So I started the calendar with individual permissions. The admin GUI of the calendar feature says that these individual object rights supersede the global rights, which had not been set. But: As a registered users I could read the calendar, but NOT create new events in it, although object permissions should allow me to do so. I had to enable this globally (!), which is not what I want to do. Therefore it looks like the calendar feature only looks for global permissions, and not for object permissions. Thanks hman |
tracker item |
|
Calendar won't jump into next month if in week or day mode
Sigh. Yet another bug in calendar. In the main calendar window, when you are in the last week of this year's January (/tiki-18.8/tiki-calendar.php?todate=1611529200) the link to next week points to /tiki-18.8/tiki-calendar.php?todate=1612047600, which results in precisely the same week shown. Once you are at that point, "next week" will ALWAYS point to /tiki-18.8/tiki-calendar.php?todate=1612047600, so you cannot enter February by means of (repeatedly) clicking next week. This means you get stuck there! The workaround is to pick (or enter) a specific date from February. In February, the same bug strikes again: You cannot go into March by clicking next week. hman |
tracker item |
|
Calendar; Days to display in the calendar (admin settings and calendar settings) selection is not applied
Admin can set the days displayed in Tiki calendar. It can be set from the calendar admin panel : tiki-admin.php?page=calendar#Calendar {img fileId="1807" thumb="box"} It can be set from each calendar edit settings (wrench => edit) : tiki-admin_calendars.php {img fileId="1808" thumb="box"} However the days are displayed in the calendar {img fileId="1809" thumb="box"} By extension they will be seen as "existing" days for a calendar event created/used with tracker field calendar item. |
tracker item |
|
Calendar: Update all events with this repeat rule doesn't update any event
When you update a recurring calendar event (say, a yearly commemoration date) then you have a selection, to update only the current event or all events with the same rule of repetition (radio buttons). If you check the latter, none gets updated. Not even the current one. Oh, there are so many bugs in the calendar feature... Thanks hman The calendar feature needs a deeper investigation and it has been done a lot of development around versions 21 LTS and 24 (trunk, future LTS). This and possible further calendar bugs have to be reviewed, discussed and fixed in a broader context. Regards, Torsten |
tracker item |
|
Calendar: Updating recurring events mass produces double entries
If you edit a recurring event in the Calendar and save for all recurrences, Tiki creates double entries. All the events remain unchanged, and get a double that contains the changes. As the number of recurrencies can be 99 this creates 99 double entries which then have to be killed all manually... VERY time consuming... This bug was already present in 18.x, nobody fixed it... |
tracker item |
|
Calendars: error saving event when feature_jscalendar disabled
When feature_jscalendar is disabled, there's an error message upon saving an event (seems to be ok in Tiki21): System error. The following error message was returned: Column 'start' cannot be null The query was: INSERT INTO `tiki_calendar_items` (`user`,`calendarId`,`name`,`description`,`status`,`url`,`lang`,`allday`,`start`,`end`,`priority`,`locationId`,`categoryId`,`nlId`,`lastmodif`,`created`) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) Values: admin 1 gdfgdfgdf dfgdfg 0 0 0 0 0 0 1576261805 1576261805 The built query was likely: INSERT INTO `tiki_calendar_items` (`user`,`calendarId`,`name`,`description`,`status`,`url`,`lang`,`allday`,`start`,`end`,`priority`,`locationId`,`categoryId`,`nlId`,`lastmodif`,`created`) VALUES ('admin','1','gdfgdfgdf','dfgdfg','0','','','0',NULL,NULL,'0','0','0','0','1576261805','1576261805') |
tracker item |
|
Calender: Edit broken
Not only that there is no direct access to the edit function (if you look at a calendar event, no tools icon is displayed, and when you click on an event, as I wrote in another bug report, you only get a huge mouseover containing some source code) - if you wiggle the mouse enough, you get another cursors, not the question mark. With that cursor comes a hyperlink to the edit function, but not as a clickable hyperlink. But you can copy the URL into the clipboard. If you past that into the URL bar of your browser, voilá, there is the edit function. But it is broken. First, it does not save everything you edit. If you make an event a repeated one, that will be forgotten. If you make an event one of a whole day, that will also be forgotten, but more so: A new, duplicate event will be created with no name and a subset of the events details... Thanks hman P.S .: Because I cannot edit bug reports, I cannot enter the relation to the other bug report - because dev.tiki.org does not allow that to be entered in the first place, it can only be entered by editing a bug report. |
tracker item |
|
Can view tracker item comments (tiki_p_tracker_view_comments) is not properly applied
On a tracker I set comments and that the last comment and last modifier should be displayed. On the same tracker, permissions "Can view tracker item comments (tiki_p_tracker_view_comments)" is not checked. Admin can see in the tracker list the last comment and last modifier. {img fileId="3064" thumb="box"} A user from a group that Can view trackers (tiki_p_view_trackers) and Can create new tracker items (tiki_p_create_tracker_items) cannot see in the tracker list the last comment and last modifier. {img fileId="3066" thumb="box"} But, a user __see the comments and add a comment__ in the tracker through the tracker editing interface. (while he may get permission to comment from somewhere else - I can't see - this is not the point, please continue reading) {img fileId="3065" thumb="box"} If, on the tracker permissions, I check "Can view tracker item comments (tiki_p_tracker_view_comments)" for this user group, then the user can see the last comment and last modifier in the tracker list. {img fileId="3067" thumb="box"} Seems like this permission doesn't work properly (user can see comments without permission) and is applied only for the tracker list view. |
tracker item |
|
Can't change language on homepage
I can't change the language in the homepage using the switch language module when on a homepage when sefurl is active. This is incomplete: I mainly wish to try if the wsho keys were moved when amette moved the dev.tiki.org server |
tracker item |
|
Can't find any profiles
No matter what I search for, I can't find any profiles to apply, at all. When I attempted to "Refresh" the registries, I had a tcpdump running, which showed a 404 error from http://profiles.tiki.org/profiles |
tracker item |
|
Can't remove the last related item from Relations fields
Once you have related something using a Relations field (or I imagine any other ways you can relate objects) you cannot remove the last related object, only change it to something else. We had a similar issue with category checkboxes a while ago, it's because once none of the checkboxes are checked the request doesn't contain anything of that -+name+- so the field doesn't get updated. Note: This for me is when the number of possible results is more than tiki_object_selector_threshold and the objects are shown as checkboxes - but others report it works ok... hmmm {sign user="jonnybradley" datetime="2019-05-07T14:59:15+00:00"} |
tracker item |
|
Can't switch order of menu options
At https://nextdev.tiki.org/tiki-admin_menu_options.php?menuId=47 I can't change the ordering of the menu options by ''drag and drop''. They just stay at the original place after mouse up. Moving them as sub options by moving them to the right also gives weird results. They do move but not at the appropriate place. |
tracker item |
|
Cannot choose image into blog post when enabling SEF URL
__Setup:__ tiki 17.1 on Linux, nginx, mysql, php 5.6 I have standard text editor and default file gallery stuff.. Short story: I cannot put images into blog post via "Choose or upload images" button. The files are being downloaded instead of inserted into opened blog post. It is something regarding __SEF URL__ feature.. when I enable it .. the bug is being triggered.. when I disable it it works as before. The other strange thing is that I cannot edit already inserted images via double clicking. __Steps to reproduce:__ 1, open blog post 2, click "Choose or upload images" - three squares behind each other icon 3, Upload screen is opened in another window 4, click Browse Galleries 5, choose gallery and hover on the particular image 6, popup with thumbnail of image and caption "Download" shows 7, after clicking the image starts downloading via browser This is the screenshot showing that it will download instead insert: {img fileId="1143" thumb="box"} This is the failed-to-construct edit image dialogue: {img fileId="1144" thumb="box"} __What I was doing:__ Enabling SEF URL.. Fiddling with some settings, not sure if related - user settings, permissions, batch directory, disabled image gallery etc. I tried Batch directory in File Galleries, it worked via syncthing.. then I processed the files.. probably it caused the thing.. Moved files from database to directory. __Show tiki instance:__ I was not able to demonstrate bug so far (I have SEF URL set) Password for admin: 12345 .. test/test123 set/set123 if anybody is interested in playing with that. |
tracker item |
|
Cannot click on events in calendar view and other calendar issues
When you click on an event in the calendar in calendar view, you cannot open the event to see details. In list view this works, in calendar view it doesn't... It doesn't matter whether you click on the title of the event or the info-"i". Both are non-responding. Furthermore, if the event has start and end times, the beginning time is displayed with broken formatting. Settings are "%H:%M:%S %Z" for long format, "%H:%M" for short format. Everywhere else Tiki shows the time correct. The mouseover of calendar parses incorrectly and displays a stray "%" between time and time zone. Furthermore, the wrench symbol is non-responsive in list mode. |
tracker item |
Example to illustrate: /lib/prefs/feature, line 2425:
{CODE(Colors="Tiki")}
'feature_wiki_argvariable' => [
'name' => tra('Wiki argument variables'),
'description' => tra('Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}'),
'type' => 'flag',
'help' => 'Advanced+Wiki+Syntax+usage+examples',
'default' => 'n',
'keywords' => 'arg var vars',
],
{CODE}
The output of this descriptions stops at the pipe symbol between paramname and default, supposedly in all languages, including English. I cannot translate into German with this entry in custom.php:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname|standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
but when I replace the pipe with a slash, all is well:
{CODE(Colors="Tiki")}
"Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname/standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}",
{CODE}
So please check whether this is a bug or a feature of tra(), and depending on this check either fix it or change in English this description, to use text without a pipe.
Side remark: The pipe doesn't show here, just as the the arguments in double curly braces! Although I enclosed my code sample in CODE tags! ({sign user="Jyhem" datetime="2022-03-03T14:30:00+00:00"} Arguments are interpreted first before anything else. That's what ~np~~~/np~np~nonparsed~np~~~/np~/np~ is for)