Category: 22.x

or it's a group/permission issue.

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

Correction - comments are visible, so 'turned on' (enabled), just permissions for posting (tiki_p_post_comment) may have been changed in the upgrade to Tiki22.

From my understanding, the time (or several times) recorded inside the tracker field duration are some kind of "independent" entity inside a tracker item.

IMO, we should have option(s) to "lock" the time recorded to avoid further changes after an action is done.

IE: If I record the work time of someone and if at some point it is approved or validated it should locked and only an Admin (or a user with permission) would be able to change it or unlock the entry.

by extension may be something simple can be done as a start with the tracker item status.
If open (or open and pending) it can be changed else immutable.
If the item is close durations recorded can’t be changed.

I test the field duration on nextdev and suggest some improvements.

I wonder if end-users (not Tiki/Techie) won’t be confused by so many modals, buttons and with many click before starting a simple timer (not happy UX). From the item creation to the timer running it is 4 to 6 six click/selection not to mention other fields that may be in the trackeritem.

Actually to user the timer function you have to give a title, a descriptopn and you have more options. That’s is good if you have ONE item and you will attach to it SEVERAL durations. While you are limiting yourself with the information you can attach with a duration.

It make more sense to me to create ONE item per duration and use the item fields to attach what you need with it. (label, description, date, reason, category, etc). Then using trackers or list plugins you can do whatever you want and use whatever you want. In that case the user can see a simpler version of the timer with a start/stop/pause (reset?) buttons only.

We could have an in the tracker field options an option to have only ONE duration recordable per item simplifying everything. So both case are covered.

I test the field duration on nextdev and suggest some improvements.

It is really nice and complete however came to me 2 fears when it will be under the hand of end of users (not a Tiki/Techie user).

User will forget it.
Imagine having it running on a mobile device for a training sessions or as employee workclock. People will forget it is running quite easily.

In the tracker field options I suggest we add (simple) alerts parameters:
* enable alert (this duration is running)
* every 15mn, 30mn, hours, 5hours, days... (more seems to me too much, but...)

I suggest also we add a limit (after what we stop the timer)
* After [ ''value'' ] [mn,hours,days] stop the timer (a notification will be displayed)
* Send a mail notification
** to the admin
** to the user/owner of the item
** to this mailbox [''value'' ]

As pointed out by Brendan/drsassafras ([https://tiki.org/forumthread69192-CSS-Compatibility-Issues?topics_offset=14]), the CSS files in trunk are missing vendor prefixes that Bootstrap 4 bootstrap.css normally has. This is because the Autoprefixer script isn't being used in Tiki's current stylesheets workflow. For better browser compatibility (so we aren't supporting only the latest browser versions), it would be good to integrate an Autoprefixer script in our workflow.

I found this script, which could be helpful: https://github.com/vladkens/autoprefixer-php . Or maybe there's another solution that works for the devs who compile SCSS to CSS.

Update: I added Release Blocker category to put this on the front burner. The solution doesn't have to be the script I found, but some solution is needed for Tiki 19 to have maximum browser support.

Update 3/16/2020: This isn't fixed in my local installation; I'd like us to have another look at it. {sign user="chibaguy" datetime="2020-03-16T06:54:46+00:00"}

Update 9/22/2020: This seems to be less an issue as legacy Edge and IE browser usage declines. I can't test IE10 and other instances of vendor prefixes aren't critical. I'm removing the blocker category and changing the status to pending for now, and will check again when we update to Bootstrap 5. {sign user="chibaguy" datetime="2020-09-21T16:21:02+00:00"}

Make it possible to find users by their real name on add_friend (in social service controller)

In the wiki syntax the following code
{CODE()}
# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
* Is it important to solve this
* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations
{CODE}

Will produce this (the not expected result):
# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
* Is it important to solve this
* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations

This is bad as it is breaking the page format and the heading numbering system.
To prevent this I have to add indent for each block between a line feed (+) and so this code:

{CODE()}
# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
+When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
+* Is it important to solve this
+* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
+* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations
{CODE}

Will produce this (the wanted result):

# Status on ((TikiFest Virtual 2021 Summer Workshops)) - May shift to longer second hour topic
# [https://tiki.org/forumthread77173-Translation-for-tiki-site-close-page-tiki-error_simple-php|Tiki simple-error (site closed)] translation dilemma
+When closing a Tiki website we gave the option for the admin to edit the message. It sound like a good thing BUT on the other hand translation of the rest of the page may be impossible and if the admin of a french Tiki insert a french message the final screen for the end-user will look badly done. (half english and half french)
+* Is it important to solve this
+* Is it possible to avoid english/hardcoded strings (so the Admin wrote everything he want)
+* ...
# Is there a delay between what we see at Gitlab and the reality see: https://tiki.org/forumthread77159-How-reliable-is-gitlab-informations
That is pretty dumb in 2021 and as long as I’m between 2 heading Tiki should understand it has to indent the text accordingly.

===WAS: Alias Donation not working on t.o===
On Google I was looking for "Tiki Wiki Donation".
I get a result and this is the link:
~pp~https://tiki.org/tiki-index.php?page=Donation&structure=Donation~/pp~

But it goes to a non existing page that need to be created.

If I go at https://tiki.org/Contribute-to-Tiki I see this page as a "Donation" alias.
Something is not working as expected. (removing &structure=Donation doesn’t help).

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

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

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

---

===Update: 2021-05-19===
Now on Google when you look for "Tiki Wiki Donation", the output is:
* https://tiki.org/sheet15 : a public sheet that display 2011 donations (===anonymous can see !===)
* https://tikiwiki.org/sheet15?parse=edit : an error page (Permission denied: feature_sheet)
Not really an improvement of the situation... ?

Note: Googling "Tiki Donation" output is:
* https://tiki.org/Contribute-to-Tiki
* https://tiki.org/sheet15 : a public sheet that display 2011 donations (===anonymous can see !===)
* https://tikiwiki.org/sheet15?parse=edit : an error page (Permission denied: feature_sheet)
There too it is not really optimal

{syntax type="tiki" editor="plain"}
It would be really useful to be able to override the smarty templates used for email notifications (currently in -+templates/mail+- and -+templates/activity+-)

Probably a new pref -+mail_template_wiki_pages+- to look for pages "named exactly like the template files" (maybe starting with -+mail_+-?) with the correct -+tiki_p_use_as_template+- permission and if found, use that as a tplwiki resource instead of the tpl file.

Hopefully to be backported to 21.x when tested.

Profile ((pr:Groupmail)) keeps a log of email messages in a tracker.
Mail content seems to show in a textarea field. However the content in there shows html tags, with escaped < and > characters, etc.

What about making Cypht mail reader as an option on text area tracker field?

See current syntax shown:
{img fileId="1484" thumb="box"}

Currently, when you write __a new__ article at tiki.org and then click the preview button, the page refreshes with all the form empty, so all the inputs and edits are lost. (Seems like I reported this earlier, but the bug list search also didn't work when I tried to find it, so I'm not sure.)

Hello everyone. Right now i am experiencing an issue while trying to upload a file using the the {FILES} plugin.

__What i did__
# I created a page and added the {FILES} plugin inside of it.

{CODE(wrap="1" theme="default")} {files galleryId="9" sort="name_desc" showtitle="n" showicon="y" showname="y" showfilename="n" showdescription="y" showmodified="n" showmodtimedate="n" showthumb="n" showupload="y" showaction="y" showid="n" showcreated="y"}{CODE}

# Then i added a simple .txt file by clicking the "browse.. " button.

# By click the "Upload" button i receive a blank page with url -+/tiki-upload_file.php+-


__tiki-syslog.php output__
# For my upload attempt i get this message
-+Request to /tiki-ajax_services.php failed CSRF check. Ticket does not match or is missing.+-

# When i try to enter into tiki-syslog.php i receive this log message
-+Request to /tiki-syslog.php failed CSRF check. Requesting site could not be identified because HTTP_ORIGIN and HTTP_REFERER were empty.+-

To be honest i don't know if those 2 messages are connected somehow

__Server Info__
* Release: Debian GNU/Linux 10 (buster)
* Database Version: 10.3.23-MariaDB-0+deb10u1
* PHP version: 7.3.19-1
*upload_max_filesize : 64M
*upload_tmp_dir: Unknown

At dev on the buttons the light red is the main "call for action", "default action", primary background color button. The dark red is the secondary background color button.

When I edit/create an event in the calendar on dev.t.o at the bottom, this is what I see:
{img fileId="1497" thumb="box"}

Due to the placement buttons and the fact that there is 2 default action (primary color) the preview button seems to be the "default" one. That’s wrong UX.
"Save" should be the first (start - left direction) and only primary, "Preview" and "Copy to a new events" should come after with both secondary colors.

This is the same (worst) when editing a page at t.o (cancel doesn’t look like a "cancel" button, it is secondary):
{img fileId="1499" thumb="box"}

When I edit a tracker item this is what I have:
{img fileId="1498" thumb="box"}

The order is good but "Rename" and "Write together" have wrong colors. They should use the secondary color. (also the Lock button not shown here is primary color).

We should carefully design our buttons for a better UX.
Those elements a critical for new user approaching Tiki and partly explain why people feel uncomfortable and confused with Tiki.

Saying that Tiki is too big and there is too many options is just another way to say that the interface is too confusing. ?

https://uxplanet.org/focusing-on-buttons-e31d575953bd
https://courseux.com/best-practices-for-buttons-the-user-experience-of-colors/

The wikiplugin buttons labels are not translated.
This force users to add more code to manage it.
* Use the HTML wikiplugin and use duplicate set of buttons for each language.
* Use the LANG wikiplugin with duplicates set of buttons per language.

Not very elegant...

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}

When I create an event, it shows up everywhere except the Calendar view (it's on the list view, and "upcoming events").

I tried unzipping tiki-pkg-fullcalendarscheduler-5.5.0.zip into public_html/vendor_custom/tiki-pkg-fullcalendarscheduler, but it didn't make a difference.

I also cannot find "Format to use for tracker field keys" in the Admin -> Search panel.

I was not able to reproduce this on show2. It seems to work fine there. The only difference I noticed, is that on my installation, no default calendar existed, and I had to create one before any calendar appeared.

You can use a category module or a plugin List in a Tiki menu to display a list of items (link to a category page) for each sub category.

For exemple:
{CODE()}
{module module="categories" nobox="y" decoration="0" type="trackerItem" selflink="y" hideEmpty="y" onlyChildren="y" categId="23"}
{CODE}

{CODE()}
{LIST(searchable_only="0")}
{list max="500"}
{filter deepcategories="1"}
{filter type=category}
{LIST}
{CODE}

However this adds a bunch of empty link that push down the menu items:
{img fileId="1495" thumb="box"}

It also add an empty span for each items after the first child:
{img fileId="1496" thumb="box"}

Instance created here : http://bsfez-11581-7674.show2.tikiwiki.org

Category transitions can only be defined from ONE category to ANOTHER category. It is just as valid to have a transition from NO category to A category. This is not possible at the moment.

Example: Defining a workflow for wiki pages via category transitions. Once a wiki page is in one of the workflow categories, transitions can be triggered via the category transition module. But it is not possible to use the same module to insert a wiki page into the workflow. One has to select one of the workflow-categories from the categories tab while editing the page. This is bad UX as it doesn't make sense to the end user why there are two different ways of interacting with the workflow, especially since the workflow categories should ideally not be selectable from the categories tab at all.

Additionally it would also make sense to be able to remove a wiki page from the workflow, i.e. defining a transition that removes the FROM category without adding another category.

If you go to "tiki-adminusers.php" and using the action menu {icon name="wrench"} try to assign a user to a group you will have the following error:

Error
Cannot add user xxxx@tiki.org to nonexistent group
This message will move to the top of the page after a few seconds.

If you do it from the the user record "tiki-adminusers.php?offset=0&numrows=25&sort_mode=login_asc&user=34" and use the button "Assign user to group" it will work.

{img fileId="1542" thumb="box"}{img fileId="1543" thumb="box"}{img fileId="1544" thumb="box"}

If you enable "Offer to save passwords" and save your Tiki login and password on [https://wikisuite.chat], each time you reload a page with converse.js in a popup e.g. on [https://wikisuite.chat/About] or [https://wikisuite.chat/P%C3%A0d%C3%A9] Chrome pops up a blocking dialog saying "Sign in as (your username)" and then scrolls you to the bottom of the page, which is really quite annoying. It seems fine on the home page where converse.js is embedded in the page.

It also doesn't seem to happen on [https://conversejs.org] after the first page load, so seems to be specific to the Tiki implementation.

See first the box saying "Even better" below.

"__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--)

This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"}


I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs.

This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs.
Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc.
{BOX()}
__Even better__
Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably:
# A new general preference should be added for this new behavior to be enabled
# when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively.
# when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session.
# If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page.
# therefore, save the edition in place by user A (the one that started editing the page first)
# reopen that page for edition for user A with te url adapted to the togetherjs session, and
# send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition).
# if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode.
{BOX}

---
This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}:
* user is sent automagically to open the session without "Warn on edit conflict"
* ... __BUT the together session fails to display the other users being there editing the page concurrently__:
** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-.

To reproduce the updated problem info:
Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature):
http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage
user1:
u: admin
p: 12345

user2:
u: user
p: 54321

# Click on button of the side module "Co-Write with TogetherJS"
# Edit homepage as user1 (admin) in browser engine1 (e.g. firefox)
# Edit homepage as user2 (user in browser engine2 (e.g. chromium)
** accept the popup asking to join session

problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc.

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

Cliking on marker of any geolocated wiki page on a map produces no popup box anymore (it shows "loading...")
Other geolocated items work as expected regarding this feature, afaik
Reproduced with "GeoCMS Maps_18" profile o 18.x, 20.x, 21.x and trunk. as of today {sign user="xavi" datetime="2020-02-22T13:18:46+00:00"}
See it reproduced here:
http://xavi-9794-7275.show2.tikiwiki.org/tiki-index.php?page=Map-of-Wiki-pages
u: admin
p: 12345
(using trunk)

Otherwise it prevents the page to be scrolled or doing anything one would expect to normally do. Reproducible while editing the tracker items here on dev.tiki.org too.

I just edited a trackerItem in the wishlist and save + comment.
Just after submitting I had a quick warning about "Comment are not allowed..."

Still the comment was posted.

https://dev.tiki.org/item7557-Itemlink-Trying-to-access-array-offset-on-value-of-type-null-notice

((doc:Admin Wizard|Configuration wizard)) doesn't seem to save changed prefs. I've been recently warned about a new tiki admin unable to enable structures, that he needed for a knowledge base with tiki.

He was using the configuration wizard, going to wiki, tick "Structures", click at "Save and Continue", but when going back through the button "Back", or going to the control panel Wiki and review structures there, they where not enabled indeed.

I was able to reproduce this bug in recents (git based) Tiki 22, Tiki 23 and Tiki master. However, the feature seems to work as expected in Tiki 21 LTS.

It has been reproduced in branch master in a show instance:
Log in as admin here:
http://xavi-9794-7941.show2.tikiwiki.org/
u: admin
p: 12345

Visit:
http://xavi-9794-7941.show2.tikiwiki.org/tiki-wizard_admin.php?&stepNr=8&url=tiki-index.php

Click at "Structures" to (attempt to) enable teh feature.
Click as "Save and continue"
Click at "Back", you will that the structures feature is not enabled indeed yet.

You can confirm so visiting the Wiki control panel, at the section about Structures, here:
http://xavi-9794-7941.show2.tikiwiki.org/tiki-admin.php?page=wiki#contentadmin_wiki-2