Category: Feature request

''Reviewed with Tiki25''

--If the auto-assign is set to "Creator" and the admin edit an existing item with a null username (creator deleted, error with duplicate feature, etc), the admin username will be assigned and saved. This can happen even if admin doesn't see the field (if he use a modal to modify some preferences or part of the item).--
''Not able to reproduce anymore, may have been fixed''


If the admin duplicate an item that has a another user selected in a user selector field, the new item (the clone) will be saved with the admin for user.

{FADE(label="Instance")}
__Tiki show trunk and Tiki show 24 are not working as expected__ but I could reproduce the bug on a Tiki24 instance:
http://bsfez-11581-7751.show2.tiki.org/tiki-view_tracker.php?trackerId=1

If you want to reproduce you can log as admin/12345 go to the tracker a duplicate an item from a different user using:
http://bsfez-11581-7751.show2.tiki.org/tiki-tracker-clone_item?trackerId=1&itemId=1&modal=1
{FADE}
{img fileId="2021" thumb="box"}

auto-change in status of items after a time frame (specified in the tracker definition) since tracker item creation of last modification date. I.e. After a month, change status from open to pending or closed.

It would be nice to add autocomplete for "Find" text boxes for the seach module, header search and advanced seach features.

many x.tw.o sites would benefit from that, for instance...

(I add this request here after Jonnyb explicitly asked me to suggest him places where atuocomplete would be adequate (:biggrin:)
)

Since the use of Bootstrap in Tiki (13.x+), wide tables (like many of the ones we use in dev.t.o to display bugs and their associated variables) display a bunch of columns hidden, and the scrollbar is only shown at the bottom of the whole table.

New users might not notice that there are columns on the right hand side of the table, designed to be shown (like in our case, the column "Comments", which indicates which bugs have been commented, by whom and when, to facilitate info to the viewer about bugs that received feedback and more opinions/replies might be expected, etc).
Example (from https://dev.tiki.org/Tiki14+Blockers on a wide screen):
{img fileId="985" thumb="y" rel="box[g]"}


I was searching for something like what you can doo with doodle on wide tables, but couldn't find any jquery plugin for that.
|| ::Default view on wide table (doodle.com ):: | ::Expanded view after clicking at the shrinked columns (doodle.com)::
{img fileId="983" thumb="y" rel="box[g]"} | {img fileId="984" thumb="y" rel="box[g]"} ||

The floss solutions that we might explore to integrate might be (after 30' of searching around):
# Footable jquery plugin: (MIT licensed)
+ http://fooplugins.com/footable-demos/
# Table column toggle, from jquery mobile (compatible with using Bootstrap?)
+ http://demos.jquerymobile.com/1.3.0-beta.1/docs/tables/table-column-toggle.html

Try the demos, and see
Alternatively, some sort of custom trick could be desinged using colResizable jQuery Plugin? (MIT licensed)
http://www.bacubacu.com/colresizable/

If equally complex to implement, I would cast my vote for Footable jquery plugin, for what I've seen in their website as end user.

Is it possible to automate the creation of a structure(s) eg( run every night as a cronjob). I really like the keyword concept list and I think this could be deployed as a feature for sites that are drowning in wikipage content and maintaining menus is just too trouble sum.
Is the keyword page auto generated? If you could set a category to include all pages in that category in the auto-maintained structure.

Dear all,

I'm currently working with RR plugins in [https://wikispiral.org/tiki-index.php?page=Statistics|statistics pages] and very regularly changing those, upgrading the formulas / contents. This makes me validate plugins really really often (say, 5 times per 10 min), and even if the admin plugin validation page is useful, it still slows my work down a great deal, especially when I have to edit 5-6 times a plugin in order to correct its outputs.

Discussing with Xavi he pointed me out that autovalidation is a security problem, as some plugins can inject malicious code. Of this I'm plainly conscient, but it would still be a good option for some usercases to have an autovalidate option, reserved for admins or other special groups. The top option would be to have it only for some chosen plugins.

... I guess that CMS admins aren't there to inject malicious code ;), and honestly, I NEVER read the plugin validation text when I have been writing it (plugin HTML, plugin redirect, plugin RR)... Just validating it, and testing it before putting it on our main server, when its arguments might harm something.

An other option to my usercase would be to have plugin aliases without plugin validation reserved to admins.

Either case, this option might really help !

Joël

Cutting and pasting text often involves text which has paragraphs which begin with indented lines. These could be recognized by the editors and converted into paragraphs.

If text area feature "paragraph deindent" is turned on, a line which begins with two or more spaces should be converted into the start of a paragraph. In the normal editor, this text would be moved to the start of the line and a single blank line would appear as a paragraph separator. Note that multiple blank lines before the paragraph should be compressed to a single blank line. Text with indented paragraphs often does not have a blank line between paragraphs, so the code needs to ensure that a paragraph marker exists.

It would be nice to generate periodical stats reports in order to track for example the learning curve

This tracker item could not be found

Usability issue, but not so much a bug as feature design:

If the tag cloud is large in tiki-browse_freetags.php, search results are not immediately apparent on the screen. The user has to scroll down past the cloud to see the results, which is not necessarily obvious to new and/or less savvy users.

Ideally, the beginning of the search results should be displayed near the top of the page, but with a portion of the tag cloud still visible for further search filtering. The tag cloud could automatically collapse, with a large obvious control for expanding it again, or it could be positioned side-by-side with the results. Those are the only two solutions coming to mind.

Facts:
It's a manual action to set the default group of a user.
It's a manual action to set the correct category of an item when created
When a user sets the wrong (or none) category of a new item, it won't have access (depending on permission settings) or everyone has access.

Idea:
Create an option in the User Settings control panel, to enable automatically the default group when a user is only part of 1 user group (besides the registered and anonymous).

Explanation:
When the user creates an new item and is only part of one usergroup which has a default category set, it will get automatically the correct category assigned.

As I understand the feature Auto TOC, once enabled at a system level it automatically applies to ALL pages, but can be disabled on any individual page.

On our site, only a small minority of pages benefit from having a table of contents and we've been making use of the maketoc plugin to achieve that for many years across multiple versions of TW on those few pages as required. On our site we would need to edit several thousand pages to disable Auto TOC on a page by page basis as currently implemented..

Whilst we appreciate the maketoc plugin has its issues, we read with great concern on page Endangered Features [https://dev.tiki.org/Endangered-features] that consideration is being given to deprecate the maketoc plugin in favour of autotoc.

Before such a change is make, we would wish that a new option be added that allows Auto TOC to be enabled but by default it DISABLES the appearance of a toc on every page. Those few pages which would then benefit from a toc would be able to enable it. This would essentially reverse the current situation where it can be disabled in some pages.

Thank you

We have a few boutons, menus and menu-items that are displayed in Tiki while there is nothing doable.

For example at : https://tiki.org/Donation

Some are just overloading the screen.
Some have a very little interest (informative)
Some have an informative value (but a button or an item menu is not the right way)

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

--

Another example is the structure menu displaying __only__ an item for the page I'm on and clicking on it just doesn't do anything but reloading the page. (check as anonymous)

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

I'd like to see some sort of an "autosave". That way when you're engaged in editing a really lengthy page, it will save itself periodically. For those of us that have flaky internet connections, this would be a huge boon. My edits wouldn't necessarily be lost if my internet connection goes pouf for a few minutes.

In a tracker item, we often refer to wiki pages. From those wiki pages, we should be able to see the trackers in the backlinks.

Related:
Tracker plugin to get title and make link to tracker item
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1768

With this second thing done, we could have backlinks among tracker items.


This will be useful for a ((Mindmap))

CVS Head (code name Tiki 1.10) has some goodies.

((tw:ReleaseProcess110))


Many of which we could backport to 1.9.x without much risk.

ex/:

#Multiple wiki pages can be added to or removed from multiple categories at the same time (terence) __done__
#Batch wiki page renaming (terence) - __that doesn't make much sense to me and I can't find it in HEAD... perhaps you mean remove?__
#New permission tiki_p_view_wiki_history to control access to wiki page histories (terence) __done__
#More intelligent rendering of the wiki page bar so unnecessary tab buttons are not displayed (terence) - __should be done__
#IP addresses can be hidden in wiki history (sylvie) - __done__


Terence has indicated he won't have time to do this this week-end. We are looking for volunteers.

Suggested on IRC:
(4:39:16 PM) mose: maybe what is missing in banners feature is a way to point to a custom tpl


This would give more flexibility. It would be easy to add Javascript, or very special banners or using variables (language, etc)

If a wiki page, we could easily delegate management and maintain edit history.

When doing administration in the wiki, for instance, in configuring menus, if you want to change permissions, you have to edit each item one at a time.

This is a great feature for image gallery. Would be really nice for file gallery too.

{syntax type="tiki" editor="plain"}
__When you create a zip which contains subdirs the system seems to work but nothing is done.__
tikiwiki accepts only a zip file with one level to load a lonely galery.
~~#FF0000:__This can be, should be enhanced__~~

!!This is the bug : it must not don nothing without an error message.


!!The enhanced functionalities :
Now what is the most important problem. When you want to upload many files they are generally into a structure of directories and subdirs with some levels.
This subdirs structure fits with a meaning, groups of file, with same properties and generally the groups that you want to retrieve into the gallery structure (galleries hierarchy).
Generally the files systems don't support libel, comments etc... that be easily communicated, which informations we can hold with the tikiwiki file gallery.

The consequency of these premises is that the best way to load such a structure is that the zip subdir structure should be imported as a gallery structure with the attached files.
After the galery manager can enhance the information (files names, sub-galeries names, comments, properties, rights etc...)
!!
Further the problem of upgrading a voluminous file galery :
1- security and reliability : such load could not be done only into an empty galery without sub ones neither files
2- the system could memorize the subdir names and accept zip upgrades if the structure fits. First same dependencies, accept new subdir and new files, and following the update options of files with same name accept the upgrade keeping associated informations.

{syntax type="tiki" editor="plain"}
When the user navigates to a page in the "Global Settings" section of the left column of the Unified Admin Backend layout, that section of the menu stays open and the current name of the active page is highlighted. But when the user navigates to a page in the "Manage" section, the section closes and the current page isn't highlighted. This isn't good UX practice and should be improved, if possible.

Content templates very usefully allow complex/rich formats to be pre-established for Wiki pages etc - but if there are a number of users with full 'editor' permissions it would be very useful to be able to put individual Content templates under a 'change control' process where only one individual (and the admin) can change/update it, ===and=== to be able to segment the access to a large number of content templates by an individual Category.

Being able to 'lock' a template in the same way as a Wiki page etc is assumed to be a simple way of achieving the 'lock' request but there may be better ways of achieving the effect.

Adding a Category function may have some more 'interesting' consequences since some thought should be given as to whether the categorisation is inherited by the wiki page/newsletter or whether the template, whilst only being available to a user with the right category permissions, should then just be pasted into the edit screen and the resultant page categorised as required.

update June 2013 - still a very useful Feature Request !

From several discussions;

The learning curve of Wiki page editing, which pretty a basic need, is longer than a lot (if not most) other web application. Things require knowledge and too many clicks to be found and understandable.

Improving the way a wiki page is edited by default is mainly a design UX/UI aspect as all the code is here already.

For example and comparing to Confluence that, from users point require 15mn to have someone working;

* The editing space by default is all full-screen so you have focus on tool you are using right now and not everything your Tiki has
+ ~~#F00:and not confined in a tiny space with what’s left from a screen with menus, preview, header, footer etc~~
* The toolbar by default is a simple as possible (one line) with very clear options for not-techy first time user better comprehension
+ ~~#F00:and not configured by and for admins / techies that don’t want to customise their toolbar~~
* The "main" plugins (they call it macro) are available under a dropdown
+ ~~#F00:and not with the help menu, tab plugin, search it in a small space~~
* You can see/search all the plugin in a large space using "common" terms and big icons
+ ~~#F00:The plugin/macro name is reduced to what is does as short as possible and not a weird name someone gave to its plugin or a long list of words attached to say what it does in a tight space with small text and small icons~~

I think we should have a look at the way it is done and we could improve pretty quickly the way it work.

__Screenshot__
Full screen simple editing by default (the macro/plugin access is under the "plus" button, a dropdown for the common one and direct access to all the others);
{img fileId="1212" thumb="box"}
{img fileId="1213" thumb="box"}

The plugin/macro access is elegant and easy to read
{img fileId="1214" thumb="box"}

We are working on some pages, their names being regularly changed, thus their links.

It might be great if it would be possible to have an easy access to pages via their page_ref_id. I can list the page_ref_id in tiki's listpages, but when I use it to build a (more permanent) link, this doesn't work.

For instance it might be, in /tiki-listpages.php, when you use the option show page ID, to have links to wikipages by clicking on their page_ref_id (currently it's the same link as for the page name).

Also, when I do it manually editing the link, like this:
[https://wikispiral.org/tiki-index.php?page_ref_id=155] (the page 155 exists), it gives me it's 404ing.

When I put the page with an alias in a structure, then appears the page ref id, and the number here is different that the one in listpages ???

Is there something I missed ?

Currently, when one attaches a first file to a wiki page, the attach a file tab turns into a tab that says how many attachments there already are on the page. Clicking on this button does two things:
# it allows you to see the existing attachments and
# it exposes a control that lets you add attachments.
The problem with this button is that it does not offer the affordance of attaching a file. A naive user who looks at this button will not understand that it is the button that one uses to attach a file.