Category: Feature request

Hi,

There are issues with filtering on 'Date and Time picker' in TableSorter and PivotTable. I spoke with another team member who said they were "deep issues". I have confidence they will get solved some day, but date sorting, - by month and year, at least - is a basic necessity today.

I created a very simple workaround that is bullet-proof, which works across the board where applied. I added two dropdowns with:

1) year, i.e. '2019, 2018', etc.

2) month, i.e. '01-January, 02-February, etc.'

So now the user has two extra fields to click on (:sad:) (in addition to the 'Date and Time picker' field, as the day is important also) but, also have a TableSorter that works 100% (:biggrin:)

The 'Wish' would be to add separate fields ('months', 'year') in which:

month - has an option to have the current calendar month (based on the time and date settings off the users Tiki configuration) be the default option (yes/no)

date - same thing, option to have current year as default.

While some would argue, why not 'quarterly' or some other options, realistically, monthly or annualy is how the vast majority people view reports.

I strongly suspect this would be super easy and quick to accomplish as 90% of the code is already available.

br,
Mike

The current breadcrumbs feature is not useful, but could/should be redone to improve site navigation and organization. It would be great if there was a trail like

''===Site index=== > ===Feature top page=== > ===Feature subsection(s)=== > Current page''

in every feature/section. Forums already have something like this, but would have the site index added at the beginning. Galleries would display the full trail to the current gallery or file. In the wiki section, ideally the structure breadcrumbs would be incorporated.

I know for basic refreash you can use some java script but I was thinking it could be nice for less technical people to add a plugin that refreashs a wikipage that maybe holding lots of telemetry that changes every few seconds.

{syntax type="tiki" editor="plain"}
I'm requesting that Tiki consider adding the modulus or abs function to complement the existing functions in Mathematical Calculation Tracker Field.

Reason:
I think it would help keep calculations tidy as complex calculations start spanning multiple pages.

Similar Uses:
There is a similar function in Excel spreadsheets and perhaps this function could find its way into Tiki Sheets too.

Some documents will have too much content to be fetching from the server multiples times, so I have documents spread across a few pages. It would be nice it you could link the pages so their section numbering is contigious across all the pages as listed below:
Page 1
1.1 Section
1.2 Section
Page 2
2.1 Section
2.1 Section
Page 3
3.1 Section
3.2 Section

I am replacing a site with Tiki Wiki, on which there is a chat feature too. The problem with Tiki Wiki is that the chat's content MUST be cleared at times, when some conversations should be censored or "erased from history".

The feature should not take long and should only be a button next to the user input box, available only to allowed users.

The feature would simply remove any existence of the chat's content with no history whatsoever.

It would be nice:

*to be able to see what is changed from the default value
*to be able to reset preferences to the default

All this, on a panel by panel

{syntax type="tiki" editor="plain"}
Sometimes, it's nice to start over...

https://doc.tiki.org/Score-Details
https://doc.tiki.org/Score

I would like to have someone develop a resource checkout system. This could be for a small library of books, videos, etc. or other resource that people can check out (company van, etc.).

Admin Side:
* Category admin
* Resource admin
* Users admin
* Inventory status (what is checked out, what is in stock etc.)
* Users who currently have the item
* Checkout length admin (custom settings by item, or blanket timeframe, or no checkout length)

User Side:
* List of items available (categorized by type: videos, books, tapes, etc.)
* List of items you are on the waiting list for
* Your position in the list (You are 3rd in line for this item)

Automatic Pieces:
* User notification of an item coming due / past due
* User notification that the item they were waiting for has been checked back in.


This might also be able to be expanded to serve as a rental pool with just a little extra work.

Related:
((Marketplace))
((Shopping Cart))

Fresh install of Branch-1-9 daily build.
The help system (the system that turns the feature descriptions into live links that point to the docs) is not enabled by default.

Not Enabled on a fresh install of Sa Jun 16 15:42:39 CEST 2007

I visit a page and it says I must login. Since I have no account, I register.

At the end of the registration process, I should be sent back to the page I was trying to access.

Please see: ((Update notifier))

Review all mods and decide what should be added to BRANCH-1-10
http://mods.tikiwiki.org/

Please see: ((To mods or not to mods))

criteria:
*license
*size
*security
*potential popularity of feature
*non-reliance on 3rd party code


Plugins that will now be in core (and removed from mods):

*include ok in 2.0, should be removed from mods
*[http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=perm|perm]
*group (ok) should be removed from mods: wikiplugin_group.php
*[http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=files|wikiplugin_files.php]
*wikiplugin_listpages.php ok?, just remove from mods?
*[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1550|wikiplugin_mouseover.php needs to be fixed, then moved]
*wikiplugin_trackeritemfield.php __done in 2.0__

Reason:
*Great plugins
*Mods installer doesn't work for everyone and there is no documentation for manual install

^
Let's coordinate here: ((Monitoring revamp))
^

wiki page names, wiki page descriptions, etc should not only be indexed but the weight should be higher than text in the the wiki page.

Same logic should apply to all features.

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

userslib.php is actually a mess where AuthPAM, PEAR and CAS have been pasted inside, my idea is to rewrite userslib.php with the idea of "modular authenticators" that is, having a directory like lib/userslib/ put there authlib_cas.php, authlib_pear.php, authlib_pam.php and tikiauth.php (for the builtin tiki's authentication).

The goal is that a user can create a new authlib_*.php file for his own purposes (actually I need one for Active Directory via php-ldap and another for our customers database) without the need of touching userslib.php at all, so upgrading would be much easier, and writting your own authenticator would be really much easier than now.

I'm currently working on that on BRANCH-1-9 as that's the one I use at the office but userslib.php from 1.9 to HEAD is untouched so no issues come with that.

My plan is to initially split userslib.php into cas, pear, pam and the builtin modules (a lot of work there!) then rewrite the Login section of the admin panel so it adapts to it's new nature.

The ways to preserve environment I've tought are: being able to enable/disable any module at any time, having only the current 3 enabled by default, and set what would be the new "authenticators_order" preference to meet the current possible situations also retaining preferences.

What I still don't know how to handle is:
* How an authenticator can create/delete it's preferences from tiki_preferences when enabled/disabled (is there any tikilib function to create/delete preferences?)

Comments are welcome!

(NOTE: I'm not sure that this tracker is the place for that.. I saw it's a TODO... am I right?)

Copied some suggestion I just throwed on irc..., after fighting each time on some of my production sites to manually send messages to many users which are kind of lost some times at the beggining of their participation in a tiki-site-powered community.

{QUOTE()}
(11:37:39) xavi: I was just wondering about a new and easy improvement of the registration process of new users to a community sit eusing tiki
(11:38:07) xavi: just through allowing an admin to add acustomized welcome message to new users successfully registered to the site...
(11:38:29) xavi: ... with the text and links he might need to tell to new users....
(11:38:52) xavi: ...in a similar way to what mailman does for the welcome message to new users...
(11:39:48) xavi: ...I imagine a simple text area, like site identity does, where the admin can write any simple text (with or without wiki markup? like the newsletter feature does/allows)...
(11:40:45) xavi: ...so that the admin can set that message easily (without manualy searching for the appropiate template to hack through ftp)...
(11:42:48) xavi: ..and the the new user, can review the infos and tips that he/she needs to know on that site: "now you can: # watch that forum where that important thing is discussed.... #join that newsletter/blog/articlefeature to be up to date about news from that community, #review and/or subscribe to that tracker..., ...
(11:45:22) xavi: oh well, I can't code php+mysql myself (yet, at least ;-) ), but I guess that this shouldn't be that difficult nor time consuming to an experienced coder, provided that that person agrees on that this feature is "low hanging fruit" to improve the experience of newcomers to a community, through improving the communication while the first steps of that person in the community site...
{QUOTE}

This could also be important for ((Workspaces)), and ((Organic Groups)). So that, not just to register (join the registered group), but as a customized message per group, so that, when joining a new group (at registration time, or later on through the subscribe groups plugin), you get the specific message with hints, links and remindings of things adapted for that group.

I have completed an enhanced robots.txt file.

Initial Website XML Maps I was making were returning Just under 500 results. The Sitemap now returns 45 results, one of which is an error, that I have filed a separate bug report for. No pages are duplicated, all pages with relevant content are crawled.

Of note is that I have re-enabled the file gallery being crawled. It was returning large number of files and was disabled to prevent pressure on the web server. Results can now be indexed without the massive duplication that existed before.

There is a section in the file that can be commented out to prevent duplicated pages when SEF URL's is enabled. Applied automatically, it will prevent the entire website from being crawled.

Of importance is also that I have only tested this for the feature set that I am using. It WILL create a better crawling and therefor better Search Engine ranking with other features, but may not take it as far as one could be achieved.

Using this robots.txt file not only decreases server load, but also leads to better search engine rankings.

The robots.txt in the current distro (1.9.x Sirius) contains

Disallow: tiki-print.php

Should it not also contain

Disallow: tiki-print_article.php
Disallow: tiki-print_blog_post.php
Disallow: tiki-print_multi_pages.php
Disallow: tiki-print_pages.php

{include page=Roles and Permissions}

Recently, this was addressed:
[item6423|Rollback should indicate who did the rollback]

Let's go one step further and let the rollbacker indicate a comment

I did a rollback here:
https://dev.tiki.org/tiki-pagehistory.php?page=Where+to+commit
but there is no indication who did the rollback.

Suggestion: change to:

rollback to version 239 by marclaporte

Various *.tikiwiki.org sites are managed by different volunteers on various hosts. That is good.

Each domain should be systematically copied over to someone else.

Something like:
||domain|managed by|backed up by
fr.tikiwiki.org|mose|marclaporte
themes.tikiwiki.org|marclaporte|luci||


Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=482

phpBB is a popular open source forum software.
Sometimes, a forum is not enough.
So, the data must be migrated from phpBB to Tiki forums...

If you want to help:
Please post links to similar scripts.
ex.: phpbb to invision board, etc
If/when we do a script, we should do for all major forums.
---
__From kerrnel22 on 11/20/07:__

I have almost completed an integrated TikiWiki forum migration tool for 1.9.8.x and 1.10. Initial release will be to migrate only Tiki forums from one Tiki install to another. However, hooks are in place, and the intention is there, to work on extending the migration tool to importing of phpBB2 (or any other forum software) into Tiki. If you would like more information, email tiki.kerrnel@kerris.com. I expect a general release of the forum migration tool (for Tiki forums only) into cvs of both branches for beta testing by December 1/07. If all goes well, I'll have something released for phpBB2 migration prior to Dec 31.

UPDATE: It's not a regression, sorry for the noise (I was confused). {sign user="xavi" datetime="2013-11-18T13:09:45+00:00"}

Usability improvement: nl1 missing in route.php for newsletter1