Category: Easy for Newbie Dev

tiki-list_quizzes calls for an icon named "gear" which does not exist. Although it is clear what such an icon could depict, there is no icon file of that name (I checked both low-res and higher res "large") and no definition exists that could point otherwise. Checked in legacy and checked in Glyphicon, there is no gear.

Line 6:

{CODE(Colors="Tiki")}
{button href="tiki-edit_quiz.php" class="btn btn-link" _type="link" _icon_name="gear" _text="{tr}Admin Quizzes{/tr}"}
{CODE}

The page name of the "View Articles" automatic page doesn't translate (tiki-view_articles.php), while "List Articles" does (tiki-list_articles.php).

This leads to a mixture of English and target language in the browser history, and possibly in bookmarks/favorites. The page name, as displayed by the browser "View Articles" should be fed through tra(), IMHO.

I use TikiWiki as a platform for teaching at the college level, and one of the main things I do is require that students create and maintain their own blogs -- each student has one blog and should post only to that blog. My suggestion is that although I understand why there's an initial option to "allow others to post to this blog" in the blog create dialogue box, it would be a good idea to leave this option's availability and visibility up to the administrator -- in my situation, this option, if accidentally checked by students, creates confusion at posting time. I don't want students to see this come up as an option when they create their personal blog.

On fresh install of 19.x the form on -+tiki-remind_password.php+- page is really ugly first impression.

See https://screenshots.firefox.com/3SNIvciKwFHlLJVF/demo.luciash.eu

Please use Bootstrap4 form classes to fix the tpl file to make it look nice.

In /templates/modules/mod-login_box.tpl there are two (?) broken translations, tr in curly braces not closed & not opened, thus creating a HUGE text that gets pumped into tra, which contains mostly Tiki source code and of course lots and lots of line breaks and tabs...
{CODE(Colors="Tiki")}
{elseif $prefs.auth_method eq 'saml' && $showloginboxes neq 'y'}
<b><a class="linkmodule" href="tiki-login.php?auth=saml">{tr}
{if $prefs.saml_option_login_link_text eq ''}
Log in through SAML2 IdP
{else}
{$prefs.saml_option_login_link_text}
{/if}
{/tr}</a></b>
{if $prefs.saml_options_skip_admin eq 'y'}
<br /><a class="linkmodule" href="tiki-login_scr.php?user=admin">{tr}Log in as admin{/tr}</a>
{/if}
{else}
{CODE}
I set the importance to a higher value, because it is the user login that gets affected... Also, it affects ALL languages, including English...

{syntax type="tiki" editor="plain"}
When the TOTP 2FA feature is activated, in the user settings UI, there are explanation strings that reference specifically (and sometimes only) Google Authenticator.

For example, when it first presents you with the QR code it mentions FreeOTP (which is kind of a dead project?) and Google Authenticator. Then, once you have fully enabled the feature in your personal user settings, it says:

"Two-factor authentication is a security measure that requires an extra code when you log in. When enabled, Tiki will require a code from your mobile phone during login. This code is created by the Google Authenticator®."

It is probably not desirable to push users towards the Google solution (and "the Google Authenticator®" sounds really weird, especially without " application" after it). The text strings throughout Tiki's UI for the TOTP 2FA feature could maybe be more generic, and say "authenticator app", maybe accompanied with a "(learn more)" link to https://en.wikipedia.org/wiki/Comparison_of_OTP_applications ?

I have set the difficulty level to "easy" because finding and changing the problematic strings is probably just a matter of doing -+git grep Google Authenticator+-, so there wouldn't be a ton of digging involved.

{syntax type="tiki" editor="plain"}
At tiki-user_preferences.php#contentmytiki_user_preference-4, Security user should setup 2FA authentication. This is not a simple thing and there should be a tooltip to link with Tiki documentation: https://doc.tiki.org/Two-factor-authentication

/lib/core/Tracker/Field/Computed.php says "This feature is still in place for backward compatibility. While it has no known flaws, it could be used as a vector for a malicious attack. A webservice field or custom JavaScript is recommended instead of this field.". Well, I know a flaw :-)

Look at lines 46 and 53:
{CODE(Colors="Tiki")}
'dec_point' => [
'name' => tr('Decimal separator when displaying data'),
'description' => tr('Single character. Use "c" for comma, "d" for dot or "s" for space. The valid decimal separator when inserting numbers may depend on the site language and web browser. See the documentation for more details.'),
'filter' => 'text',
'default' => '.',
'legacy_index' => 2,
],
'thousands' => [
'name' => tr('Thousand separator when displaying data'),
'description' => tr('Single character: use "c" for comma, "d" for dot or "s" for space. When inserting data, no thousands separator is needed.'),
'filter' => 'text',
'default' => ',',
'legacy_index' => 3,
],
{CODE}

Well, use c for comma or d for dot or s for space. Well. But the defaults are "." and "," :-) Whoever wrote the description did not write the defaults :-)

The action log in itself is localized via tra(), but the filter settings are not.

When you utilize Tiki's action log, you must first set which actions to record and which to review. Because the list is quite long (although some actions are inexplicably missing, like 'remove' on articles) you can filter the view.

Let's make it a use case: You want to record & review all creations and all deletions.

So you set the filter to type="All" and action="create". Then you check all checkmarks and press Ok to save.

Then you set filters to type="All" and action="remove". Then you check all checkmarks here, too and press Ok to save.

This should be it.

When you now set filters again to type="All" and action="create" you'll see that all your checkmarks have magically disappeared.

Analysis shows that when to check checkmarks on all elements on the current view, upon saving ALL those currently not viewed get saved als "unchecked", which is wrong... Those ''must'' remain unchanged!

There is only one way to deal with all elements, and that is the unfiltered list. That gets saved faithfully. This bug renders the filtered view useless for all purposes except for viewing...

{syntax type="tiki" editor="plain"}
{img fileId="3252" thumb="box"}

Following the doc at https://doc.tiki.org/PluginActivityStream I set activity stream and login as admin to create my first rules.
At tiki-admin.php?page=community#contentadmin_community-2 I enabled Custom activities and apply.
I was expecting something to be visible, a button to add or create my first rule but the screen stays put.
I retried again and activate everything but nothing else was displayed.

I re-look at the video to understand that at the top of the page (not visible when you are looking at the Activity Stream options) they were a link, that was always there "Activity Rules" that goes to an external page, https://next.tiki.org/tiki-managestream-list

This implementation is different from most of what we find in Tiki Administration and really not user friendly for a new admin or someone discovering the feature. While it is ok to have on the top it should be also visible near the direct related option "Custom activities" checkbox as soon as you enable it.

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

Another thing that would be nice is to be informed of the existence and eventually the number of rules that have been created.

For example, and to make it small, near the Activity Rules link a badge with the number of exiting custom activity rules. (0 for none is good to indicate no rule have been made yet)

There are several cases an Admin want to use the login module but need to add some informations.
To solve this it is possible to use the module in a page or in another module.
This is not very intuitive and require editing work.

Adding a "free text" field will make much easier to add login or registration information (or whatever want the admin/editor).

Add the new preview tab to other text areas, as seen in {gitlab id=4dc05f6d}

When creating a wiki link ~np~((foo)))~/np~, Tiki uses the target pages's ''description'' as the the link's TITLE attribute. It would be nice for external links to also have a TITLE attribute. Tiki could use the link's description, or a generic text. For example:

~np~[http://foo.com|my link]~/np~ would become:
<a href="http://foo.com" title="External link: my link">.....

and

~np~[http://foo.com]~/np~ would become:
<a href="http://foo.com" title="External link">.....

Try the url : https://tiki.org/files/
It will display a WSoD instead of redirect or even the "route does not exist" page.

{syntax type="tiki" editor="plain"}
In the early days when Tiki Wiki was primarily a Wiki tool, keeping the **wikiactions** page actions button constantly visible at the top of Wiki pages made sense.

However, now this button often obstructs the user experience, drawing attention away from content with its contrasting color, even when only one or two actions are available.

While outlining the button (as discussed in the Matrix chat) would be a quick improvement.

I also propose we also enhance the admin settings at `tiki-admin.php?page=wiki#contentadmin_wiki-1`. Adding a __group selector__ under "Wiki top line location" would allow admins to choose which user groups see the page_actions button.

I would like to suggest additional data types with built-in syntax checks that could make life easier for people dealing with user's input into forms:

* Telephone numbers. Basically those should be strings, but with the syntax check that allow only for numbers, spaces, braces () and ONE plus sign (for international numbers, but this must be at the very beginning). Also thinkable would be some special characters, letters, sometimes needed on PBX systems: number sign (#) and asterisk (*) and P for pause, F for hook flash, E for earth.
But __''please''__ do not make strict checking for a 3-3-4 digit scheme, because this only exists in the US and Canada...
* Zip codes. These should be configurable for the country, as US Zip codes vastly differ from those in Europe (in Germany they are 5 digit numbers only!).
* IBAN international bank account numbers. Those consist of two letters (for the country) and two check digits, then 18 digits for the number. Check digits could also be checked, so typos by the user can be detected (and rejected) upon entry, eliminatin frustrating SEPA withdrawals... And it would be ''swell'' if IBAN output could be formatted into 4-4-4-4-4-2 digit scheme with separating spaces!
* BIC Bank interchange codes, these are 11 digit strings
* Debatable: Credit card numbers. Those are actually not allowed in databases containg personal data (PCI, see my feature request for a second DB for those). CC card numbers have a 4-4-4-4 digit numerical scheme, and 2-2 for expiration.
* Not necessary, because outright a compliance problem is the CVC or CVC2, the Card Validation Code (the digits printed, but not embossed, on the back of credit cards so they do not imprint). Those must never be stored anywhere. Not in databases, not on paper, nowhere. They can only be used for online verification and even must not be cached (direct violation of your contract with your card processor).

Could a system be implemented so that an admin could control the order that forums are listed within a section (like the way numbers are assigned in the featured links app)?

Also, a system to control the order that sections are listed (same as above)

Lastly, a setting to set the default order to be used when clicking on the menu item


Currently sections are listed alphabetically, and by default forums are listed based on last edit date.

You can click on the forum table headers to change the sort order in a number of different ways.

There isn't currently a way to select a sort method that I could find

On a Tiki23 I go to -+tiki-admingroups.php?group=''Agroup''#contenttabs_admingroups-3+- to display the members of "Agroup".
On the row of each user I have a wrench that opens an action menu.
I click on "Remove from group".
It displays a confirmation and validation modal with a password field and a submit (confirm) button.
BUT because the action menu stays open I can't see and click on the submit button.

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

{syntax type="tiki" editor="plain"}
https://ibb.co/tTWCXJmM

When an admin perform a search the results found on the admin page will have the class "highlight" added.
This class is adding a bright red background and border.

{img fileId="1756" thumb="box"}
That's wrong language.
Red is for danger, critical, etc.

Should be more informative and less aggressive.

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

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

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

At tiki-admin.php?page=login , Username, when I enable "Use email as username" some username settings are now hidden (meaning not in use) but they are still applied.

Minimum length
Maximum length
(And may be "Force lowercase")

I created an instance to test and reproduce.
You need to "really" register a user, not using the admin user to create new users.

How to reproduce :
# Go to Admin, Control Panels and switch to "Advanced" (to see advanced preferences)
# Go to log-in : tiki-admin.php?page=login, Registration & Log in
# Enable : Users can register
# Disable : Validate new user registrations by email (we don't want to validate email)
# Go to : Username and set "Maximum length" to 6
# Apply (save)
# Use a different browser (check you are not logged), go to the Tiki and register a new user
# Try to input more than 6 characters for the username, you will see this error:
+ {img fileId="1689" thumb="box"}
# Go back to your previous browser (logged as admin), log-in : tiki-admin.php?page=login, Username
# Enable "Use email as username" option
+ The parameters Minimum length, Maximum length, (And may be "Force lowercase") will be hidden has not relevant anymore.
# Go back to your different browser (check you are not logged)
# Create a new user with an email for login (obviously longer than 6 characters).
+ You won't see an error on focus
# Submit your registration and you will see the error:
+ {img fileId="1690" thumb="box"}

The difference of treatment in the process make me think there is some wrong additional condition that should be cancelled if "Use email as username" is enable.

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.

At tiki-adminusers.php (Admin users) there is a popover on the username that display the user information.
This popover should never overlap the username link.

While this work fine with the "usual" information it doesn't work when "user tracker" is used to store user informations (https://doc.tiki.org/User-Tracker) and have sections (tabs used).

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