Category: 18.x

It would be good to make the 'User' (i.e. user name) a required field when adding a new Tiki User (Admin Users)

Recently, I tested adding a new user without this (left blank), but added the password (2x) and an email. Tiki went the the next step, 'Confirm adding new user', then went to the full user list. Of course it was not visible anywhere in the full list of users (only one page, under 10 users total).

Also, it might make sense to change the name from 'user' to 'user name', or even more direct 'login'.

br,
Mike

When someone changes the Related-to field here I receive email notification like this:
{CODE()}
Item Modification

Tracker:
Bugs & Wish list
Item:
6887 WSOD (again) on tiki.org forum thread link

View the tracker item at:
https://dev.tiki.org/item6887-WSOD-again-on-tiki-org-forum-thread-link

Author: luciash d' being
Date: 01 Nov 18 11:51 CET

Status: Open
----------

----------


{CODE}

I added the related tracker item to the Related-to field on https://dev.tiki.org/item6887-WSOD-again-on-tiki-org-forum-thread-link
__As you can see it does not report the change on that field at all.__

Admins or Moderators should be able to manage (edit and delete) tags from the web interface.

https://tiki.org/forumthread67133

I guess we have similar tools/page we can reuse.

On the admin page to enable/disable plugins (tiki-admin.php) paymentlist is missing the checkbox, instead only this text is displayed: "paymentlist: Show details of payments. The payments considered may be restrained by user or date.".

The result of this bug is that the plugin Paymentlist cannot be activated or de-activated! Whatever the setting is on your Tiki installation, you cannot alter it through the Admin UI.

When the wrong URL is entered, such as when an admin page URL is miss-typed, instead of a normal 404 error, this is displayed: "No route found. Please see http://dev.tiki.org/URL+Rewriting+Revamp". Many people who see this will have no idea what it means or what to do with it. Can this be replaced with something more user friendly, like "Error: no page found. Please check the spelling of the URL."? Can it be done within the Tiki interface and not be an empty unformatted page with that one line of geeky text?

While I added and saved some plugin icon (PluginSign) on toolbars on tiki.org and cleared the Tiki cache, the change is not reflected when editing a wiki page. It still shows the previous older toolbars setup and the icon does not appear there while on Admin Toolbars it is shown. See Row 2 on https://tiki.org/tiki-admin_toolbars.php (when you have Admin access of course).

The advanced rating is so advanced, that you can only add new ratings and edit them, but there is no delete functionality... The wrench icon carries only "settings", which simply reloads /tiki-admin.php?page=rating, and there is no delete anywhere :-)

Empty date tracker-field shows data through Mathematical calculation tracker field


An item from our intranet (item65 ) has no value at a date field (trkDeliveryDate). trkDeliveryDate is a date field (date picker) with only date, and no default value set in this preference.

Field trkDeliveryMonth is a Mathematical calculation tracker field, extracting the month from that date field, which should be empty, but it's not, it shows some month (current month, I don't know if by chance or by which means).

trkDeliveryMonth:
{CODE()}
(date (str y-m) trkDeliveryDate)
{CODE}

On tracker Check Out:
Orders are correctly registered in the data base and correctly handled with payment
But in Cart Trackers
* If I buy one product it is registered in Orders Tracker
* If I buy several products the first one is registered in Orders Tracker ... the others are correctly registered in Order Items Tracker

Is this a BUG or a Configuration issue ?

Observed in the PROFILE Shoping cart configured from install.

In 18.x (and probably earlier) you can print the table of contents on the fly in the pdf produced by mpdf (at pdf generation time), regardless of using hardcoded maketoc calls, o hardcoded title calls with wiki argument variable -+{ { page } }+- (no space intended between angle brackets).

^ Preference: Control Panels > Print > mPDF > __Table of contents__ ^

This feature is nice, but if would deserve another minor level of integration, for those cases in which:
# the Wiki page title is hidden by default, and placed by hand in the wiki page where needed (or replaced by human-(more-)readable text), usually at the top with a heading 1 level style.
** current behavior: mpdf places the table of contents at the top, and page title is shown below the table of contents, which is counter intuitive
# A wiki page has the AutoTOC setting disabled at wiki page level, and a hardcoded call to __~np~{maketoc}~/np~__ is placed below the page title (or wherever, with whichever maketoc params for the users like, such as levels="2,3", my favourite, btw).
** current behavior: mpdf keeps the table of contents produced by itself, plus the table of contents that was previously generated in the rendered html page by the wiki markup). therefore, 2 table of contents are shown, which is not what most users would expect.

Potential solution to both issues: (2 birdies in one shot)
__Allow replacing hardcoded call to maketoc in page with the one produced by mpdf__

How? Brainstorm mode on:
* add a new param -+inpdf+- in maketoc plugin, with several values:
** __replace__: -+~np~{maketoc inpdf=replace}~/np~+- Replace that maketoc call in the wiki textarea with the output of the table of contents from mpdf
** __keep__: -+~np~{maketoc inpdf=keep}~/np~+- keep same behavior as nowadays, for those edge cases in which user has custom maketoc for partial sections of the page (or whatever), which want printed also besides the full table of contents at the beginning, etc.
** __ignore__: -+~np~{maketoc inpdf=ignore}~/np~+- ignore the maketoc call when creating the pdf, so that the only maketoc is the one produced by mpdf at the beginning (for cases with wiki page created by Tiki itself, etc, so that placement of the maketoc from mpdf is the expected one, etc)

Opinions?

Current feature Profiles in the Control Panels in Tiki searches profile names by category filters (15.x, etc).

Most profiles in profiles.t.o were reviewed in the last years and the suitable ones were added to the ((Profiles Wizard)), in most cases, and added tags to them to facilitate the discovery of profiles that will let you learn how to master feature X or Y that you might be more interested in (e.g., trackers in general, plugin listexecute, spreadsheets, tracker field itemlink, mathematical calculation field, staging and approval, etc).

Searching profiles from within Tiki by tags (folksonomy-based search) is not yet possible. The interface is ready to search by categories (top-down approach, if the naming of the profile doesn't match your expectations, you will miss it probably). "Who knows that Barter_Market will let you practice with itemslist tracker fields? or which profiles will let you learch how to use maps with tracker items? or with convene plugin? or with listexecute plugin? etc.

We currently allow the profiles control panel to search by profile name filtering by category matching the corresponding tiki version. __We should allow that profiles control panel (and /or the Profiles Wizard interface!) to search by tag name while filtering by the same category corresponding to the corresponding tiki version.__

https://profiles.tiki.org/tiki-browse_freetags.php?tag=listexecute&category=18.x ...

I tried once, but my php skills were not high enough, and didn't get the desired result.
Anyone willing to give it a go? (it shouldn't be that difficult for a senior dev, I reckon)

The User favorites feature (enabled by preference user_favorites and [https://doc.tiki.org/Favorites|documented]) allows users to define favorites, but does not let them view the favorites they have defined.

A controller similar tiki tiki-user_watches.php could be added so that users can actually use the feature.

{syntax type="tiki" editor="plain"}
For example:
https://tiki.org/Why-Wiki-Syntax-Is-Important

It seems to me that on all *.tiki.org sites, anonymous visitors should be able to see the history of pages they can see.

I wonder why I haven't seen this before. But now I see a CSS problem with the already bug-ridden calendar feature:

When you click on an event, to view it, on my site the classic 3-container layout produces an obscure error: The right module zone "jumps" to below (!) the center, the content zone...

It is kind of similar to the complete breakup of the layout when I test-migrate the test instance of the site to 21.x, but with one significant difference: When the layout breaks down upon upgrade to 21.x, the right modulezone is on the left, in between the left module zone (which remains left) and the center content zone. And on upgrade, the entire layout shows this behaviour, on every page of the Tiki.

HERE this happens ONLY when viewing a specific calendar event. It does not happen anywhere else in Tiki. It also does not happen when viewing the calendar as a whole, only when viewing an event...

So this is obviously a CSS issue. This is with a customized version of Geo, written by Gary. I have to try if it also happens on non-customized, original Geo.

Thanks

When choosing to "edit" an "Item Link" type tracker field, saving will always convert the Item Link type field to a "Relations" tracker field.

The reason for this can be seen - in the "Advanced" part of the edit popup, the only option in the "Field Type" dropdown is "Relations".

I realise that an Item link may just be a kind of relation in the "backend", however the interface for both configuring and using an item link is much better than the relations field, and any paramaters entered in to the item link do not trafer to the new "relations" field.

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

Tiki 18.01 running on Ubuntu 16.04 LTS

Attempt to apply Personal Blog and Profile on clean 18.2 install does fail.

Here is the [http://gour-11559-6743.show.tikiwiki.org/tiki-wizard_admin.php|show.tiki.org] instance which shows the problem:
u: admin
p: 12345


__Edit:__ Here I also include screenshot with the error after trying to apply profile from within Control Panel (as advised in #tikiwiki):
{img fileId="1208" thumb="box"}

When you define workspace areas, there is no mechanism to delete them. They can be edited, but not deleted.

The article feature has a setting, where you can define the sort order. It's a drop down list, but with just one option:

{CODE(Colors="Tiki")}
$article_sort_orders = [
'publishDate_desc' => tra('Newest first'),
];
{CODE}

Work in progress?

If you have an article listing on your front page, and you create a "breakout" page with older articles, you want to skip those that have already been presented on the front page. In order to achieve this, you can instruct the plugin to skip a number of articles (or a period). But this does not work together with pagination...

{CODE(Colors="Tiki")}
{articles max="6" topicId="2" largefirstimage="y" actions="n" title="News" quiet periodQuantity=3 start=5 periodUnit="week" more=y}
{CODE}

would be the code to display articles older than 5 weeks. And this works. But displays only 6 articles (as instructed). Once you add

{CODE(Colors="Tiki")}
usePagination="y"
{CODE}

The articles plugin no longer skips older news, but starts with the very same, newest article like to front page does... It does paginate, but it starts at the wrong article...

Articles do not have history. With wiki pages, there is always an undo (and multistage, and with comparison etc.). Articles don't have that, and I believe they should, and it shouldn't be hard to add... The revision system could be shared, or at least recycled, from the one wiki pages have.

When you sort a listing of articles, you can have the results sorted on the size of the articles. But the result is illogical, which is more visible when sorting descending, but in principle ascending is affected as well: The sorting is done NOT numerical (which you would expect on a numerical value like size), but by string representation.

The result is e.g. that "456 bytes" is being considered larger than "1.2 kBytes"...

If you go to articles home, and have your articles listed, you can have the list sorted by clicking on the column header. By clicking that again, you can change sorting direction (ascending/descending).

This doesn't work with the ID of articles. They are always listed ascending. However, the small arrow indicating the order DOES change to descending, but the listing isn't altered at all.

I have trackers with the field "Category" and a list of categories for the tracker to be assigned to upon item creation. The item never makes it into the category chosen.
A show instance will be created.

Auto Toc is misplaced and run over the content if your Tiki is right to left.