Category: Admin Interface (UI)

{syntax type="tiki" editor="plain"}
'Activity Rules', with the URL /tiki-managestream-list is an admin page but doesn't have the standard admin interface, side menu, etc. Also, it has no information on its purpose and no links to documentation (https://doc.tiki.org/PluginActivityStream apparently).

Probably when these details are addressed, the Activity Stream feature should be tested to check if it still works ok, etc.

{syntax type="tiki" editor="plain"}
The "Toggle sections" icon on tiki-objectpermissions.php, which is used to show or hide the feature section columns, isn't working in master currently. I checked in my local master and at https://trunkthemes.tiki.org/tiki-objectpermissions.php. Clicking the icon just causes a spinning loading icon.

When I try to use the "Add or remove from a group" item in the right-hand spanner in the User Management admin interface:
{img type="src" src="https://pmpc-dev.alsawiki.org/tiki-download_file.php?display&fileId=22"}

I get a totally broken layout. And it does not permit adding the user in a group:
{img type="src" src="https://pmpc-dev.alsawiki.org/tiki-download_file.php?display&fileId=21"}

The "More" button of the wiki page-bar has a ul with several items. These should be links visually, not buttons (with backgrounds and borders). It seems the button element gets the button btn-default class by default and adding btn-link in an instance doesn't "undo" the btn-default styling. "Permissions" only is a plain link. This looks strange in a dropdown/dropup. CSS could be used to force the btn-link styling after the fact, but I wanted to report this first in case there's a more direct way (in Smarty possibly) to prevent btn-default appearance in dropdowns/dropups to begin with.

It may not be evident in every theme - I didn't check. But it can be seen in Green Valley, at least.

{syntax type="tiki" editor="plain"}
First, the simple problem: the module visibility preference "Display on device" doesn't seem to work. I tested setting a module to "Desktop" only and "Print" only and it still displayed on my laptop.

Second, I think the thinking behind this is faulty. I don't understand why a site administrator would want a module to only display to people using a desktop PC and not to laptop users. I'm joking there because I assume the thinking wasn't really about the device but about the display resolution. was that "desktop" means larger displays and laptop means displays smaller than larger ones, or some breakdown like that. But this doesn't really work. My laptop's recommended resolution is 2560 x 1440, which is more than a lot of desktop displays. Similarly there is a lot of overlap between Mobile (phones) and Tablet resolutions. And again, there is no logic, as far as I know, to differentiate between these in regard to module display except on the basis of screen size/resolution.

Maybe user agent strings could be used to control module display, as listed on https://deviceatlas.com/blog/list-of-user-agent-strings for example, but even here there is no distinction between desktop and laptop, and I don't know what the rationale would be for controlling this way other than related to display size.

I don't know what the method was for the Tiki site to identify what type of device was being used but I suggest the module option be changed to explicitly target screen sizes, which would use the standard practice of media queries and would also make sense from the admin point of view. Actually this would just put a gui on top of the Bootstrap display classes (https://getbootstrap.com/docs/5.3/utilities/display/#hiding-elements, https://getbootstrap.com/docs/5.3/utilities/display/#display-in-print), so should be an easy fix. Instead of listing Mobile, Tablet, Laptop, Desktop, and Print, the dropdown could list "Hidden on all, Hidden only on xs, Hidden only on sm, Hidden only on md, Hidden only on lg, Hidden only on xl, Hidden only on xxl, Visible on all, Visible only on xs, Visible only on sm, Visible only on md, Visible only on lg, Visible only on xl, and Visible only on xxl".

This is a longer list but corresponds to reality. A help block can give info about what the sizes mean. Similarly, there are Bootstrap classes for print display that can be incorporated into this. (In that connection, maybe there is no need for the Tiki-specific "display_on_print" class that seems to be redundant because of these Bootstrap classes.)

I suggest fixing this quickly or removing it and starting fresh because IMO it could give to new Tiki site admins the impression that we don't know what we're doing.

The text 'Apply Profile "Simple Wiki Attributes" To Add FutureLink Questions' displays under the wiki page-bar and "Create PastLink" appears in the upper left corner of the screen, but there's explanation of this and no clear way to turn this feature off. I can't find any information or controls for FutureUI in the admin pages. I'm reporting this as a bug until the control is clarified.

About the "button" itself, it displays as plain text (needs class="btn" at least to display as a (long) button) and seems intrusive to me, like advertising. For a better display, I suggest having a short button label and putting this longer text into a tooltip (Purpose: "Inject FutureLink UI components into Wiki editing screens. Managed page's saved attributes per FutureLink UI interaction. Generates and presents FutureLink text string to user.") Not sure about this purpose but it definitely needs to be optional and have documentation.

The option
''Send an email to the user in order to allow him to validate his account. ''
in /tiki-adminusers.php ''Add New User'' tab
is only available if in /tiki-admin.php?page=login
''Users can register'' is ticked
Then and only then the hidden option becomes visible:
''Validate new user registrations by email''

By tickinig it the option
''Send an email to the user in order to allow him to validate his account. ''
in ''Add New User'' tab bcomes availabale.
This option should be available independend if or not the option ''Users can register'' is selected.

The ticking of a hidden configuration shouldn't be relevant for any functionality.

Hi there,
I've been starting to use [https://doc.tiki.org/Search+and+replace|Search and replace] tool. Great piece of tool!

I've spotted a bug there when trying to change:
* from ~np~{IMG(src="img/flags/United_Kingdom.gif",title="en anglais")}{IMG}~/np~
* to ~np~{en}~/np~

This bug makes that I end up with a ''half-process done'' since the replacement job is finishing with:
* ~np~{en}"img/flags/United_Kingdom.gif",title="en anglais")}{IMG}~/np~

It does look that the function ''replace'' doesn't handle having a __"__ in the ''what to replace''.

Sometimes, we want people to participate to one wiki page, to access their user tracker to update personal information or access a ((workspace))

Right now, we need to

#create a user
#create a group
#assign user to the group
#give permissions to group ( in general or for a specific item)
#inform this person, typically by email, on how to access this page


Instead, I would want to
#add an email
#pick the permissions this person has
#any limitations (works x times, or for x days/weeks)
#an optional message

And the system should send a 1-click login email (an email with a link in it which is unique / very difficult to guess).

Whoever clicks that link
*Would be authenticated with the appropriate permissions and according to the limitations.


Related:
Expiry date for group membership
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1071

Somewhat related:
Send welcome email (by admin to new user or user that has not connected in a while)
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1016

Also, there is a DB error on a fresh install of 10.2 I can't test in show.tiki.org to see if it's fixed in 10.4 --because 10.4 is not available on show.tiki.org-- 10.4 is now available {sign user="marclaporte" datetime="2013-08-14T23:29:31+00:00"}

{img fileId="340"}

---

In latest 11.x: "Version 0.0 is still supported. However, a major upgrade to 9.0 is available."
{img fileId="359"}

On another site:
{img fileId="371"}

On another site:
{CODE()}A new version of Tiki, , is available. You are currently running SVN pre 8.4. Please visit tiki.org/Download.{CODE}

On another sites:
"A new version of Tiki, , is available. You are currently running SVN proposals pre 6.6. Please visit tiki.org/Download." Seen on http://info.tiki.org Last update from SVN (SVN proposals pre 6.6): Friday, January 13, 2012 11:52:30 GMT-5 - REV 39480 Theme: Fivealive - Akebi

On another site:
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2013-02-26,Tue&sel=150#l146]

I would like a way to invite people to come to a Tiki site after I have added their login. (different of the use where people self-register)

Right now, I simulate a lost password message (which I customize).

Maybe this could become a new feature available to admins when

1- after a successful user creation at tiki-adminusers.php
2- when administering a user account
3- from : tiki-adminusers.php with the batch command to send to many new users.

The system would send an email with a one-click login and be sent to the user tracker
tiki-view_tracker_item.php?view=+user

Person who triggers this email alert should be in BCC. (to have a trace). Even better would be to have this logged somewhere but this could be for phase 2.

We could have a new mail template in templates/mail/welcome_message.tpl or in a wiki page (better!)


What do you think?

See the associated show.t.o instance.

I created a site using trunk (future 14.x), applied a profile which created a long tracker (160+ fields), with long field names, etc.
When I tried to export a single file from the tracker, I get in a Tiki 12.x installation:
^
Request-URI Too Large

The requested URL's length exceeds the capacity limit for this server.
^

And if I try to do the same with trunk(Tiki14), I get the screen converted into a semi-transparent blackish window, as if something was to be shown, but the user can't see anything happening. Just no message, no tracker definition exported, etc.

See it reproduced here:
# Log in here: http://xavi-9794-5536.show.tikiwiki.org
** u: admin
** p: 12345
# Go to tracker fields:
+ http://xavi-9794-5536.show.tikiwiki.org/tiki-admin_tracker_fields.php?trackerId=1
# Select one (for instance, id 5, which is short and has no commas in the name, etc).
# Go down to the dropdown field at the bottom, and select "Export selected", and click at "Go".
** No field definition is exported.

This used to work in Tiki 8.x at least, when the feature was coded, and it currently still works in Tiki 9.x (9.9svn)

Feature Connect: 'Fill form' button does nothing

In a few sites we usually get spam registrations, polluting the user registration tracker, by humans (they type properly the passcode).

Every now and then I connect to the site to remove the users registrations (this removes also their user tracker items), and I would like to collect those ip's at the same time to be sent to the banning feature.

This type of feature already works nicely for comments: you can enable comment moderation, review many comments at once, select many through their checkboxes, and click at "ban and delete" type of option at the bottom.
This collects the ip's of those comments, and sends them for you to the banning feature, allowing you to ban all those ip's with just a few clicks.

We need this also for the fake registrations from human-spammers getting in.

Since june 2014 or so I see every now and then on a few 12.x production sites error pages indicating that no route was found.

The urls that produce this false message are valid urls (such as tiki-admin.php?page=look&cookietab=2), and the solution is just to reload the same page, and it always work at the second time.

I'm sorry I didn't understand better what is causing this issue, or how to reproduce it more consistently.
Maybe all cases are with users with admin rights? But I don't know for sure.

It is a bit worrying to be affected from this issue every now and then in production sites with our LTS version. I hope some dev can get better ideas on where to look at in order to get it solved...

Send email to let user validate account doesn't send email if user previously created.

Use case: a user register to a tiki site with a non-working email (defective address or server rejecting emails from that server to that email domain, etc).

Admin changes email for that user (after admin magically finds out in some cases what happened and what is another email for that user), and clicks at the checkbox:

"__Send an email to the user in order to allow him to validate his account__" (in tiki-adminusers.php?user=N)

Use doesn't get any email. Once the tiki site was configured to save mail info in tiki logs, you noticed that tiki logs didn't record any info of any email sent by that action.
You log out, and go as anon to: __tiki-remind_password.php__ to type the username and click at click at "__Request Password Reset__".
This does effectively send the email, so that it confirms that there is no problem with the server setup sending emails, but with tiki failing to send that email when "''Send an email to the user in order to allow him to validate his account''" was checkd, ~~red:__if the user already existed in the users list__~~.

When as admin you create a new user account and in the same action you select ''Send an email to the user in order to allow him to validate his account'', then the email is sent effectively.


To reprroduce:
# Go here: http://xavi-9794-5213.show.tikiwiki.org/tiki-adminusers.php?user=2
# login as
**u: admin
**p: 12345
# change that email for an email of your own, and tick at the checkbox: __Send an email to the user in order to allow him to validate his account__
# Check tiki logs (tiki-syslog.php), and you will see no record of the email expected to be sent
# Check you email account, and same, no email
# CReate a new account with an email of yours, while at the same time you tick at the box __Send an email to the user in order to allow him to validate his account__.
** You 'll see the record at the tiki logs tiki-syslog.php
** you'll receive the email with the link to validate your account

13.x: applying a profile from Profiles Wizard doesn't send the user to the "Step2" indicated in the url (some steps anchors gone?)

I don't know when this stopped working, but for sure this worked in previous versions (6.x, probably, when I last tried years ago)

I attempted to add the new argument 'shownbitems' (set to 'y') to the plugin alias "wishes" in dev.t.o, but it doesn't get stored. When I reload the page after I hit save, the new argument is not there int the list.

To reproduce:
* Come here as admin: http://dev.tiki.org/tiki-admin.php?page=textarea
* Click on "wishes"
* Click on the plus green icon, next to "Simple Plugin Arguments". A new empty field will be shown at the bottom of that section.
* Add the argument pair (shownbitems y) to its corresponding fields of name and value, and hit at save at the bottom
* This new argument is not shown. And after clearing tiki caches, the wishes plugin doesn't show the number of items yet.

13.x: no pagination on admin groups.

Easily reproduced on t.o: http://tiki.org/tiki-admingroups.php

Go there and search for group TwCommunity, which is below the first 50 groups. It took a while to figure out that there was a hidden setting in that page to change the number of results shown below. And I wanted to see whether there were other groups beelow TwCommunity (which I didn't know their names beforehand, so using the "find box" didn't help.). And clicking at "All" didn't show more than the 50 results predefined either.

13.x: User Tracker can't be chosen in the interface to edit groups
Tried with Registered, following the instructions of the profile "User & Registration Tracker".

This profile instructions In 12.x still work like a charm, as usual. But in 13.x, there is no option to show the field to choose the "User tracker"

13.x: User Tracker can't be chosen in the interface to edit groups
Tried with Registered, following the instructions of the profile "User & Registration Tracker".

This profile instructions In 12.x still work like a charm, as usual. But in 13.x, there is no option to show the field to choose the "User tracker"

See it reproduced here:
http://xavi-9794-5307.show.tikiwiki.org/tiki-admingroups.php?group=Registered

u: admin
p: 12345

Fixing r58885 in branches/15.x/templates/tracker_filter.tpl ([[FIX]Fix serurl links for tracker status in the filter bar.) I noticed that in 15.x there is no visual indication of which tracker item status filters are applied at any given time Some circle, of background, underline or something?

In addition, when you print in paper in Black and White, you have no clue which status correspond to each item. I solved this issue in the past by means of slightly modifying the gif image to indicate an "x" for closeed and a minus sign "-" for pending. HOw can this be done in the Bootstrap era?

See it reproduced here:
http://xavi-9794-5984.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=op
u: admin
p: 12345

I tried to change the password of my user with admin perms, and I couldn't.
I was using this type of url:
tiki-adminusers.php?numrows=25&sort_mode=login_asc&user=2

This system error message was shown:

{CODE()}
System error.
El siguiente mensaje de error fue devuelto:

Unknown column 'password' in 'field list'
The query was:

update `users_users` set `hash`=? ,`password`=? ,`pass_confirm`=?, `provpass`=? where binary `login`=?
Values:

$1$U7wIlongstringhhere5utVMvA1
14numbershere85
UserName
The built query was likely:

update `users_users` set `hash`='$1$U7wIlongstringhhere5utVMvA1' ,`password`='' ,`pass_confirm`='14numbershere85', `provpass`='' where binary `login`='UserName'
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}

Please, whoever introduced the UI change that did hide the preference filters, please, please, please, expose them back to new tiki admins, since there are tons of support requests in many tiki sites out there about new site admins (even experienced php developers) not finding the preferences that they are looking for in the Control Panels, also following the documentation pages in doc.t.o about them, etc.

This is also affecting people creating show.t.o instances to report bugs and not finding the preferences, etc.

I tried myself but it was beyond myskills when I had a quick look at that, and I was fearing to break some tpl/css, so I'd rather leave ir for an aexperienced UI developers, or even better, to whoever introduced this usability regression (back in Tik1i3 or 14 days, probably?)

Thanks

So I could show quick_edit module to users with tiki_p_edit

Related:
[wish1783|Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc)]