Category: Feature request

Tiki is mainly about Wiki page and Tracker (Tiki can do many things, but let's not debate too much about this) ?

User data safety is critical, therefore we have an auto-save feature for Wiki page editing to protect as much as possible the user content editing.
I would like to see the same feature for tracker items.

Some mechanism that "auto-saves" the tracker editing content at regular intervals.
''Sometimes it take a lot of time to complete items. (lots of fields, text-area, etc)''

Some things to think about:
* Tracker editing (modal/regular) and inline tracker editing
* Indexation of the fields content (auto-saved or not ?)
* ...

This is not as easy as the Wiki page auto-save feature, but is valuable as a lot of data and content are now added using trackers.

When you create trackers with lots of entries (like cataloging newspaper articles) you will soon find that Tiki's sorting options are far (!) too limited. There is just one sorting option. A second is implied, but undocumented (either it's creation date or it is ID, could not find out).

It would be a significant improvement (and VERY easy to create in SQL) if a second and third sort option could be integrated just like the first one: Select field, select order.

These should be hierarchical, so all elements should first be sorted by option 1, and within all results sorting should be by option 2.

So for the newspaper archive example: First sort by category/department/column (alphabetically ascending), and within that by page number (numerically ascending), and on page number by title (alphabetically ascending). Just like Excel does.

These must be three separate options with both field and order selection, do not make it a multiselect, because you might want to have differing sort orders for separate fields...

When using a tracker to collect emails, it's very important that there be no typo.

Problem: Someone could assign a tracker item to me, but how will I know unless I watch the whole tracker and check for my name in all the watches?

When I pick a login/username as "Assigned To", this person would need to receive a notification. Next to the username drop-down, there could be a checkbox "send a notification email to this person"


This is not so important, but a similar idea:
If it was the group which was picked, it could send an email to all members of the group.

todo
1) simple implementation: additional parameter to user field when defining the field: send to the specified user whenever the tracker changes
2) more difficult: this additional paramater can be 'always send email' or 'send email if the tracker modifior checks a box"

In a form, I give options. But sometimes, I would like to pre-select one of those options.

The list of options is separated by commas. Ex.:
1 low,2,3,4,5,6,7,8,9 high

Maybe adding stars around the default value?
1 low,2,3,4,*5*,6,7,8,9 high

Will this conflict with the new multilingual trackers?

Here is a trackerlist report example:

{CODE()} {TRACKERLIST(trackerId=>11,fields=>194:202:197:205, status=>c, sort_mode=>f_194_asc, showinitials=>n, max=>400, showlinks=>n, filterfield=>218, exactvalue=>y)}{TRACKERLIST}
{CODE}


Now, what if I want to filter by all trackers items which have a value higher than x in field 218?

{img src=show_image.php?id=10 }

{img fileId="396"}

{syntax type="tiki" editor="plain"}
So when I see that someone reported a bug, I can quickly see their profile. (ex.: to send a private message)

The new plugin manager in 3.0 is much more intuitive. It helps uses build plugins with a javascript plugin, documents each syntax, show mandatory fields in bold and offers a global link to the documentation.

This is precisely what we would need for the trackers field type helper.

{img src=images/code.png}%%% {CODE(wrap=>1)}
(06:21:21) marclaport1: Is it possible to filter by two items in trackerlist 1.9.x? http://dev.tikiwiki.org/AllBugs <- I would like to have a filter for all "1.9.x" and "bugs" and Open (o)
(06:33:12) sylvieg: marclaport: I know it is possible in the code filterfield can be an array ... but I have no idea what form should be the param
(06:43:56) marclaport1: sylvieg: how about something like this: {TRACKERLIST(trackerId=>5,fields=>59:41:56:26:43:47:31:32, max=>-1, filterfield=>43,filtervalue=>56,filterfield2=>47,filtervalue2=>63,showstatus=>y,status=>o,showlinks=>y)}{TRACKERLIST}
(06:48:37) sylvieg: marclaport: I do not think it will work - it will overwrite http://us2.php.net/manual/en/function.extract.php
(06:49:23) sylvieg: I suppose you need a bit of code with filter=>1:2

{CODE}

Here, I can filter by several criteria:
http://sourceforge.net/tracker/?atid=506846&group_id=64258&func=browse

{syntax type="tiki" editor="plain"}
In the Tiki article at the we have "View Articles"
Clicking on it shows a liste of all the articles.

It is translated in french for "Afficher les articles".
This text is not very good for french (I won't argue for english... but I have doubt).

It would be much clearer and simpler for the users point of view to use "Voir tous les articles" ou "Liste de tous les articles".

Presently, it appears everyone who has the permission to write has the permission to translate.

But you may wish to have a website where some people are writers in their own language, and some are translators of things written by others.

On a later stage of development, you may want to allow me to translate into German and not into Farsi.

I found out that the Security Ticket string (Security ticket timed out) from tiki-confirm.js are not translated and not even added to lang/xx/language.js

I understand I can add them manually but isn't bad for consistency in general.
Couldn't we have those string added in the lang/xx/language.js file like it is done for the php translation ?

A nice feature would be to be able to trigger a group transition inside a tracker plugin. (Not only in the memberlist plugin)

My idea is to use it ([https://dev.tiki.org/tiki-view_tracker_item.php?itemId=5948|In conjunction with this request]) to make a workflow of accepting a user based on a group tracker the user has filled to join a group. (An application form, in other words)

Thanks Tikiers

We should brainstorm on this.

There are two mysqldump commands in the Tiki ecosystem:
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trim/scripts/tiki/backup_database.php
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/lib/core/Tiki/Command/BackupDBCommand.php

On a very large site, it can take quite some time from the start of the backup to the end. What happens if some data changes during this time? Could there be data inconsistency? Should we do anything to improve what we have?

__Use case 1- mirror a site__
Be able to provide on same server (different URL) or different server a fresh identical copy of Tiki with all data, including files that are not in DB.

a) Could be to offer a backup site on a different server in case main server is down. This backup site could be in the customer's office, so avoid any cloud lock-in: "You have a fully working instance with all data (less than x hours old) and all the FLOSS code on a computer you physically control" And this sticker can go on the box :-)
https://www.stickermule.com/marketplace/3442-there-is-no-cloud

b) Could be part of a dev/staging/prod routine. Ex. push data from prod to staging and/or dev to 'reset' and now we start developing again.
http://12factor.net/dev-prod-parity

c) Could conceivably be used to have several copies of a site and load balance via DNS but there would likely be better ways to achieve this... (ex. MariaDB Galera Cluster)

d) demos (OpenSourceCMS type demo to test/develop and show off profiles)

Perhaps:
make clone : a one-time copy
make mirror: setup automated recurring copy

This script should have access to ((doc:system configuration)) and to run a ((doc:profile)). An example is $site_closed eq 'y' and $site_closed_msg="This is a copy of XYZ..."

__ Use case 2- pre-dogfood (test upgrade)__
Like:
* https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/update.dogfoodserver.sh
* https://tiki.org/Pre-Dogfood+Server

That script works but it's a manual configuration every time. TRIM can backup, deploy and upgrade so why not combine? :-)

a) Check at any time how an upgrade would impact.
Could be to the tip of same branch or to the tip of a future branch or trunk.

b) Could be part of a dev/staging/prod routine

And adding a conflict alert with this would be really nifty:
https://dev.tiki.org/Check+if+the+update+would+cause+conflicts

Especially combined to the automated updates:
https://doc.tiki.org/TRIM#To_setup_automated_updates

Perhaps:
make cloneandupdate (test minor update)
make cloneandupgrade (test minor upgrade)

This script should have access to ((doc:system configuration)) and to run a ((doc:profile)). An example is $site_closed eq 'y' and $site_closed_msg="This is a copy of XYZ..."

PECL's ssh2 extension is poorly maintained, hard to install and unreliable even when it has been successfully installed. Testament to just how difficult to install are all the comments located on the third website that comes up when you do a search for "php ssh" on Google (without the double quotes):

http://kevin.vanzonneveld.net/techblog/article/make_ssh_connections_with_php/

Testament to it's unreliability even after it has been successfully installed is this:


http://www.frostjedi.com/phpbb/viewtopic.php?f=46&t=13223

In light of this, I think TRIM ought to use phpseclib (http://phpseclib.sourceforge.net/). It would save everyone a lot of heartache, from the end users, who wouldn't need to ask for support, to the developers, who wouldn't have to spend as much time providing support for the deficiencies in PECL's ssh2 extension.

TRIM: allow editing instance information. BEfore that, allow a way to view the contents of an instance, since we may have duplicates, or several accesses to the same server, or a site migrated to a new server, etc. and it's difficult to know what to delete (if any), or edit, if possible, to keep the backups consistant and everything tidy.

Doing this manually is error-prone and time consuming.

make compare should compare two sites and report at least:

* Differences in PHP version
** Seeing a diff of tiki-check.php output would be fantastic as well to see anything risky if the two Tikis are on different servers.
* Differences in the data
** in database (presumably text diff of mysqldump)
** files on disk outside web area)
* Differences in the code base

So one could iteratively manually cherry-pick merge stuff from dev/staging to production, and re-run diff until there is nothing else one cares to keep. And then, use the "copy prod to dev" script.

This is useful for ((Configuration Management for Tiki Projects))

See also: ((Divergent Preferences in Staging Development Production))

How about a true staging capability for TikiWiki?

That would include that all content can be scheduled. In essence, whether we are talking a wiki page, an article, etc, everything would have an validity interval attached. __INSIDE__ that interval, edits can be made and versions are kept, but each of the entities (like a wiki page) would have siblings that are valid for a specific timeframe.

I know that would mean some work, but it would make using Tiki for business websites so much more convenient.

In {gitlab id=06432228} 2FA arrived in Tiki for ((doc:Tiki21)) but there are a couple of improvements that would be nice to have for 21.0 (:mrgreen:)

* When i enabled it on [https://example.com/tiki-user_preferences.php#contentmytiki_user_preference-3|my user preferences] and then revealed the QR code (which i think it should show automatically) there's no input to enter a code to confirm it's working, which most sites using 2FA let you do.
*-- Then when i logged out and then went to log back in, i think that login form should have the 2FA input on it, rather than link to a new form (please)-- There is a param on the login box module called show_two_factor_auth - set it to "y" to enable, thanks!
* Also a question: Is it compatible with ((doc:InterTiki))? If so i'll enable it on [https://tiki.org] for extra dogfood! ?

Mainly thanks!

if some person goes on a vandalism spree it would be great to have one button to undo all their edits

We need the footer at the bottom of the new Admin Unified Backend dashboard.

There are over 2000 prefs. Searching is critical.

When the menu is open, we have a nice search. Quick Access to that search should be always visible. Maybe a search-all-over-admin-panel action button in the top left?
{img type="src" src="tiki-download_item_attachment.php?attId=769"}