Category: Usability

This feature isn't internationalized.

The usage of quicktags is hardcoded in the PHP, like

$quicktags = $quicktagslib->list_quicktags(0,-1,'taglabel_desc','','trackers');

for the trackers. The french translation e.g. reads

Catégorie : wiki, formulaires, etc.

So a french user would enter "formulaires", but never see his Quicktags in the Trackers feature.

Galaxia supports assigning a name to a process instance, and stores this value in the galaxia_instances table in the name field. This can be assigned through the API using the setName() method of the Instance class. (It is also assigned from the Javascript popup window which opens when you select a Start activity from the User Activities page)

However, there are many places (for example, User Instances, and Monitor Workitems) where this value is not displayed, only a bare (and meaningless, from a user's perspective) process ID number.

This is a clear usability obstacle.

I added a note [https://doc.tiki.org/User-Tracker#Assign_the_tracker_to_the_group_Registered_|here on doc] after having to debug the code on an 18.x site because we couldn't get a user tracker and group choice to work together on registration at the same time.

It wouldn't be hard to check the inherited groups on the group choice until we find the one with the tracker set, in this case Registered.

Meanwhile at least there is a workaround.

{syntax type="tiki" editor="plain"}
In barebones profile and in featured profiles, there is intro text about 1st login being necessary with u: admin p: admin (good)

However, this message stays and needs to be deleted by admin (bad)

Perhaps we should have a module with is only visible if admin password has not yet been set.

{syntax type="tiki" editor="plain"}
This feature arrived in {mr id=5960} but wan't made optional sadly, i might get round to it one day, so this is just a reminder really

I've made a page to display the ((Bug report evolution|Bug report evolution)) over time in dev.t.o, thanks to PluginPivotTable and dereived attributes of the dates, etc.

Charts are displayed, But the chart width seems to be hardcoded to 600px or similar, even if the PivotTable plugin params said width=100% initially, and I forced them to width=1000px, but no change. And in real world scenarios, with long dataset (like in the tiki community with the bug tracker :-) visualization is too concetrated.(and I did not find an easy way to make a quarter aggregation of items, but that's another topic)

Searching a bit, this seems to be an issue already identified in other implementations of pivottable.js in other softwares:
https://github.com/nicolaskruchten/pivottable/issues/848

An easy solution/workaround might involve maping param rendererOptions inside pivottable .tpl (to set plotly width and height) to to the width and height indicated in the pivottable tiki plugin params.
See:
https://pivottable.js.org/examples/scatter.html
{CODE()}
...
rendererOptions: { plotly: {width: 600, height: 600} }
...
{CODE}

Probably below this chunk of code in wikiplugin_pivottable.tpl (lines 411-51) in trunk:
{CODE()}
...
{{if $pivottable.heatmapParams}}
rendererOptions: {
heatmap: {
colorScaleGenerator: function(values) {
return Plotly.d3.scale.linear()
.domain({{$pivottable.heatmapParams.domain|json_encode}})
.range({{$pivottable.heatmapParams.colors|json_encode}});
}
}
},
{{/if}}
...
{CODE}

Make PluginChart optionally reuse some other lib already in Tiki to make js-based charts (raphaeljs, chartjs, d3.js, etc)

By default PluginChart was able to produce these charts:
https://doc.tiki.org/Spreadsheet+Graphics+and+Charts#Select_the_Graphic_Type_and_Output_Format

But it would make total sense to have the option to produce js-based or svg-based charts, like the ones currently produced by the Spreadsheet js feature ( , reuing raphael.js lib), or the ones in theory available in the ((doc:PluginChartJS)) plugin and lib.

Strategic feature to get Spreadsheets and charts out of them in the game again.

There is another request to have the png & jpg versions of the charts produced again (they are currently not shown), since this implies an easy solution for charts in PDF reports working automagically without requiring complex solutions to get js-based charts incluided in PDF reports.
This request, though, is to have an some optional parameter added to get the chart produced with some JS lib already in Tiki like the ones cited above. And we will see elsewhere how to ensure that they can be included in the printed PDF, etc.

We now need to fiddle in the templates to remove the print icon. In many cases, a print option is not useful.

Need both a tiki_p style permission and a feature_print style feature for this. Need to document the actual names we used, too.

One tiki-wide setting to deactivate all printable pages all links to these pages (with the little printer icon).

This will also be useful for http://mobile.tikiwiki.org/ Let's try to do before 1.9.1

obs: waiting for cvs to unlock to commit

Please see:
http://themes.tikiwiki.org/tiki-forums_rss.php?ver=2

The logo should be the site logo, if available.
Make sure of i18n
Make more generic. ie : no "Tiki RSS feed for forums". It should be just RSS for forums.

Test in various browsers. Especially IE6, IE7, and FF2

Before Composer (until Tiki10), if you try to run Tiki with a too old version of PHP, you get a clear warning. Now, with Composer, it's not so clear (you get the version warning of Composer instead of Tiki)

Note that the command line version of PHP may be different than the web version.
Command-Line PHP version: PHP 5.3 is needed Composer.
Web version of PHP: Tiki12 needs 5.3, Tiki13 will need 5.5

So perhaps for Tiki 13, it will be OK to have PHP 5.3 requirement on CLI, but 5.5 in web?

So for now, let's add a PHP CLI version check on sh setup.sh before running Composer.

Please see:
http://tiki.org/tiki-view_forum_thread.php?comments_parentId=48901

and add in the menu like the other features.

[15:41]<ohertel> marc, what's tiki mobile? :)
[15:42]<damian> the HAWHAW interface
[15:42]<damian> for WAP, PDA, and VoiceTiki browsing
[15:42]<marclaporte> de.tikiwiki.org/tiki-mobile.php
[15:43]<marclaporte> you have this on without you knowing
[15:43] *** marclaporte sets topic for #tikiwiki : http://dev.tikiwiki.org/tracker5 For the next 1-2 hours, please keep all discussions focused on 1.9.0
[15:43]<ohertel> ah that one. :)
[15:43]<ohertel> marclaporte: so what you want for it? perms?
[15:44]<marclaporte> naw, just on / off
[15:44]<marclaporte> from main admin panel
[15:44]<ohertel> is only 1 entry in the prefs table
[15:44]<ohertel> no biggie
[15:44]<marclaporte> perfect!
[15:44]<ohertel> so it needs no read db change
[15:45]<ohertel> just a feature_mobile = y/n :)
[15:45] *** ohertel doing update and starting debugger.
[15:45]<marclaporte> in theory default should be on be y by default to respect 3 rules, but since it isvery specialized, you can put n by default. Your choice!
[15:46]<damian> respect the rules.
[15:46]<damian> it causes less hassle for everyone that way
[15:46]<cpw> I'm going to submit what I have for my Japanese translations then
[15:46]<ohertel> we switch it off and write that to the release notes.

When going to Admin mods (tiki-mods.php) on a new install, make it report the directory name when the mods directory hasn't been created or lacks correct permissions.

The error reported asks to run ./setup.sh but is not specific about the directory affected here. This would be helpful to manually fix the individual directory instead of running ./setup.sh (which may not be possible in some situations like FTP installs).

{syntax type="tiki" editor="plain"}
Comments to tracker items can be very a useful way to gather ideas, code snippets, links, etc. from the community regarding an a problem or an idea.

It would therefore seem to be natural to include tracker comments in search - otherwise there is a risk of losing valuable community contributions in a black hole of tracker comments.

Tracker comments should of course be included in "Entire Site", and maybe even have their own search category.

When you check both:

Tracker items allow attachments?
and display attachments in listing?

Then the dl-column (I guess it counts downloads) is being shown by default.

The wiki parser inserts &lt;br /&gt; tags for each newline in the source text.
This produces a lot of vertical spacing in the rendered text, and is impossible to remove before, e.g. terms in definition lists, headings etc., whose wiki source text must start in the first column. Using the &lt;br /&gt; tag between paragraphs of text is also logically incorrect; &lt;p&gt;...&lt;/p&gt; should be used for that.
Suggested solutions:
#Let 1 newline produce no HTML tags in output,
+Let 2 newlines produce a new paragraph (&lt;p&gt;) in output
+Devise new wiki syntax to let authors manually insert vertical spacing
#Let n newlines produce n-1 &lt;br /&gt; tags in output.
The latter solution seems simple, but does strictly speaking not produce the logically correct HTML output where paragraphs are delimited by &lt;p&gt;...&lt;/p&gt; tags.
NOTE: This is ''not'' a CSS styling problem!

Everytime I use the maketoc inside a wiki page on a fresh tikiwiki 3.2 install the whole page content is duplicated every time I hit "save". Even if I delete all the content but one version and hit save the whole PREVIOUS page is duplicated again. Like I hit save: two times the page content. I delete all but one time the content, I hit save: three times the page content. I delete all but one time ... save ... four times the page content.
Only removing the maketoc makes it possible to get rid of the problem.
That was done with Opera browser on a page with 4 h1 headings but I doubt it is a browser problem. :)

This tracker item could not be found

See ((doc:maketoc))

On a wiki page, the "translate" and "manage translation" links under the little globe appear if 1. The person has permission to edit that page, but at the same time have no permissions to create new pages or edit other pages.

The links do not appear if the person does not have write access to the wiki page.


What should happen:

The "translate" and "manage translations" buttons should only appear if the user has permissions to create a translation, rather than edit the specific page they are on.

The issue I have come across is that the nav buttons are appearing when the page can not be edited, but the opposite problem is also likely (although I have not tested it) that a translation could be desired, on a page thats write permissions have been suspended.

This issue has also caused several translation & error pages to become crawled by bots and indexed in search engines. I will be proposing some new robots.txt rules to help prevent this in another ticket (to keep it all together with other suggestions)

Hope this is of interest for someone to tackle.

{flash type="url" movie="display662" width="657" height="508"}

In an updated Tiki25 using ElasticSearch I have a customSearch that displays orders.
When I receive a payment I use a button to create a payment item (in a different tracker) and set a relation between the 2 items (order <-> payment).

On Tiki25 the operation is completed and the initial item (the order item) is at the same place in my customSearch results.

---

On the same Tiki (same database and same server) using Tiki26 and Manticore I have a different behavior.

After saving the payment item and going back to the results page the initial order item it is related to is gone.😳
I refreshed the index but still couldn't find it.

In the trackers payments and orders I can see the items exist so the operation was completed.
However the placement of the item I just related another item to has been changed in the customSearch results.

This item (order item) has been moved to the end of the results list after I related to this item another item from a different tracker.

It shouldn't, I have a sort filter here based on order item date `{sort mode="tracker_field_productsboughtDate_ndesc"}`.

{mediaplayer src="display2103"}

This manual time / date selection (code below) should be optional off

__Sorry, code plugin doesn't work so below looks weird...__

{CODE()}
<input type="text" name="start_freeform" value="{$start_freeform}">
<a {popup text="{tr}Format: mm/dd/yyyy hh:mm<br />...}{/tr} {tr}See strtotime php function{/tr}"}><img src="img/icons/help.gif" border="0" height="16" width="16" alt='{tr}help{/tr}'></a>
{tr}or{/tr}

<input type="text" name="end_freeform" value="{$end_freeform}">
<a {popup text="{tr}Format: mm/dd/yyy hh:mm<br />...}{/tr} {tr}See strtotime php function{/tr}"}><img src="img/icons/help.gif" border="0" height="16" width="16" alt='{tr}help{/tr}'></a>
{tr}or{/tr}
{CODE}

A Map is created to display tracker items using "Location" type.
But the map will never display those items.

Using this syntax to display map with tracker item to display:

{CODE(theme="default")}{MAP(scope="Center" controls="controls,search_location,scale,navigation,levels,layers," center="-32.64608860015869,14.315483732934796,2" popupstyle="dialogue" tooltips="y")}
{searchlayer tracker_field_residence="y"}
{MAP}{CODE}

Please see show instance.

Maps are displayed in front of the Draw editor, making it difficult to use.

{flash type="url" movie="display637" width="645" height="787"}

When you are on a page of a wiki structure, you can click on the print icon, but you will only print that single page.

The icon and option to "__print this page and all the subpages__" (= in the the sub-structure) right from there (without going through all the clicks at "Wiki > multiprint > select structure > print") would be very welcome, since the base feature to rpint the full structure exists.

From the home of the structure, it would print the full structure (as it can be done with one click from a structure within a Workspace through ((doc:AulaWiki)) mod, or through many clicks as usual, as explained above).

If the user is on a subpage of the structure, that button would print that page and all subpages from the same structure.

Does it make sense?