Category: 9.x

Sometimes, you want to show a module just for Registered, but not Admins. So a notgroups param would be nice.

This idea is from Bernard Sfez on the Dev mailing list.

Importing tracker items through CSV only sets the created and lastModif value properly if the dates from the CSV file are in the numerical php date format.

When you import a csv file where the created and lastModif dates are written as proper dates, the imported tracker items have a created and lastModif date/timestamp of the date & time of the import action.

example csv :

"itemId","status","created","lastModif","VRID -- 265"
"849","o","07/12/2009 13:24","07/12/2009 13:24","4"

Whenever I export a csv file, it contains the dates as shown above, so you can't just export data and import data on the fly without modifying all the values...

c.f. [https://dev.tiki.org/item3500|bug 3500]

To reproduce: tag something with an apostrophe, like "l'apostrophe".

get to tiki-browse_freetags.php
This tag is displayed as "l\'apostrophe" instead of "l'apostrophe"

Note: it still works for searches, so fixing the display of the freetag should not break the search feature.

When using the UserList plugin, the links on the user names leading to their personal information pages, are shown and hidden depending on privileges of the logged in user. Unfortunately, the logic is reverse of what it should be.

Correct logic is: show links for all users that when either A.) You have admin privileges. B.) User listed is yourself. C.) User listed has chosen to make his profile information public.

Current logic is: show links when A.) You have admin privileges. B.) User listed is NOT yourself, AND user listed has chosen NOT to make his information public.

Please see: ((Extendable meta-data for all features))

{syntax type="tiki" editor="plain"}
This is a minor issue, and not sure if it something for tiki or google to fix. However I try to push Chrome as the default browser in my school because we use Google apps and it works better for that.
I don’t want to have to tell my users they need to switch browsers to insert an image. This will not get tiki accepted very fast.

I have tested this on a fresh install of 8.3, svn pre8.4, and svn pre9.0

I am on a windows 7 system with Chrome 18, Firefox 11 and IE9.
In wiki syntax mode the file galary image selector works fine.

In WYSIWYG mode the image slector works fine in Firefox and IE, in Chrome I have a new window that tries to open. The window is listed in the task bar but I cannot access it.

I have turned off pop up blockers and disabled all extensions while testing with the same result.

I have also tried from different computers.

Problem:
Some changes in Tiki code (especially the parser) between versions cause slight changes of behavior. Devs have no comprehensive way to test the result of a change on a large data set.

We have a large data set with all *.tiki.org sites.

Similar to ((tw:Pre-Dogfood servers)), we could have a script which checks the HTML output for all wiki pages for a given version, and compare this to another version.

And thus, we can check if this is a desired behavior.

The HTML entities change in Tiki9 would be a great 1st test of this. It would have been nice to have it for UTF-8 changes in Tiki5 as well...

This should be done as part of the script for ((tw:Pre-Dogfood servers)) so we have daily reports on issues. (and we know that it's the same data)

{syntax type="tiki" editor="plain"}
Relation should be
* visible in view mode:
* and editable in tracker item edit mode

ex.:
https://trunkdev.tiki.org/tiki-view_tracker_item.php?itemId=4025

If you create a tracker with one field which is a text area set to WYSIWYG, plus another field which is an Item Link that has the "Add Items" options set, the WYSIWYG editor will not load using the TRACKER module. It must be a conflict in the two scripts. Disabling the "Add Items" option allows the WYSIWYG editor to load fine.

{syntax type="tiki" editor="plain"}
When 0 is put in the Parent Category option of the Category field, no category selection is offered in the item creation form.
Even for admin.

This makes it impossible to offer a way of selecting first-level categories in tracker items.

So, tracker items can not be categorised in the first-level categories that way.

I suppose the workaround would be to create a useless category and put all the others as children. Nobody will figure that out and it is uselessly complicated

Go to tiki-list_trackers.php → Edit one Tracker → Categories tab → Only first-level categories can be selected.

With this bug and bug 4208, it seems totally impossible to design elaborate category-based permissions with trackers.

As an admin, I change the group of a user, and the default group.
The user needs to logout/login or the default group is not changed

Have just upgraded from 4.3 to 6.7 and find Plugin Showpages is no longer producing output.

Looked at [http://doc.tiki.org/PluginShowpages] for inspiration and notice that the examples there do not seem to be functioning.

Suspect plugin Listpages now has --equivalent-- similar functionality. --but we have at least one other broken plugin (WantedPages), so want to ask if there is a wider issue here, please?--

Was using ~np~{SHOWPAGES(find=>FAQ_ display=>desc) /}~/np~ but I don't see how to simply display the page description with ListPages.

--Also is there an easy way to find all the pages within our wiki where ShowPages has been used so I can change them to Listpages??--

Thanks,

Martin

Updated 08May12. The issue with WantedPages is now felt to be a separate issue and I'll open a new ticket for that.

Have also now found new to v6 Mass Search & Replace tool within Wiki Admin which is great.

Spotted by a user who noted that the URL of a suggested Calendar at the bottom of a wiki page returned an 'invalid URL' error. I tracked the error down to the sefurl modifier in the template not handling calendar URLs properly. The tested correction to modifier.sefurl.php is:
{CODE(caption="add after line 95" wrap="0" colors="php")} case 'calendar':
$href = $sefurl ? "cal$source" : "tiki-calendar.php?calIds[]=$source";
break;{CODE}

A Page Selector field from a Tracker plugin on a wiki page does not populate with the name of the page even with option Auto-Assign set to 1. Replicated on clean installs of 8.1-8.4 and 9.0b. Works fine on 7.2.

Bug is still present in master.

a) The german localization has a lot of errors, mostly typos.

b) The wording and/or spelling some of the original (english) phrases in the language file appear to me as questionable, eg line 655 "New articles submited"

{syntax type="tiki" editor="plain"}
To reproduce

# Install a fresh Tiki
# Create some usernames as usual
# Set "Use email as username" feature to yes
# Create more users (this time, username will be the email)
# Create a newsletter
# Subscribe the Registered group to the newsletter
# Send a newsletter

The system will crash and be unable to send the newsletter because some users don't have valid emails. If you error reporting is activated, you will get a message like this:

{CODE()}
System error.

The following error message was returned:

Duplicate entry '3-mcradmin-g' for key 'PRIMARY'
The query was:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES (?,?,?,?,?,?,?)
Values:

3
mcradmin
6b78cc21c16e768dd8fbb6b538c6bf78
y
1339700591
g
n
The built query was likely:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES ('3','mcradmin','6b78cc21c16e768dd8fbb6b538c6bf78','y','1339700591','g','n')
Things to check:

Is your database up and running?
Is your database corrupt? Please see how to repair your database
Are your database credentials accurate? (username, database name, etc in db/local.php)
Did you complete the Tiki Installer?
Please see the documentation for more information.
{CODE}

{syntax type="tiki" editor="plain"}
Often, we don't remember if we have already registered...

{syntax type="tiki" editor="plain"}
Activating the PlugIn FullCalendar for the display of calendar items does not show event information as expected when using the 24h display mode.
It seems that FullCalendar is not aware of the setting (12h/24h) and shows the time as AM/PM anyway.

{syntax type="tiki" editor="plain"}
It is not possible to delete a calendar as long it contains a recurring event. The User does not get proper feedback as why he can not delete the calendar.

Conflict detection when page is saved would be nice too. Often happens when people are translating pages.


It should offer disambiguation page...

For example http://dev.tiki.org/Download gives an error but it does contain
{CODE()} (alias(Download)) {CODE}
As you can see here:
http://dev.tiki.org/tiki-pagehistory.php?page=Get+code&source=0

So the page is not found, but when you try to create, you get:
{img fileId="562"}

So clearly it exists...

a) There is no way of displaying __all__ available tags.
b) There is no way to sort the available tags in alphabetical order when editing a wiki article -> properties.
c) The list of tags from case b) is hardly readable because the formatting leaves something to desire
d) There is no way to influence the sorting when displaying the freetags using the module Most Popular Tags.

{syntax type="tiki" editor="plain"}
When using field names with text for group titles, only the last part of the string is used. For example
GROUP [project_name] "AAA [project_name] ZZZ":H1
If the project name is "upgrade system", the group title should be "AAA upgrade system ZZZ" Instead I get "ZZZ"
Using: GROUP [project_name] "AAA [project_name]":H1 I get "upgrade system"

It looks like the parser that is separating text literals from [field names] is discarding all but the last one.

Edit 16 Jul 2012 Also broken in v9.0

The module upcoming_events does not indicate whether an all-day event lasts longer than one day. Such an event is only listed once on its first day. If the end date of events, that don't last all day is not displayed (parameter showEnd=y), an event lasting multiple days is indistinguishable from an event lasting only a few minutes.

The module freetags should have an option to disable the display it as a menu item in the main menu.