Category: Feature request

It is not possible to create or name a page "Sandbox".
If I do there is an error:

{REMARKSBOX(type="errors" title="Error")}The Sandbox is disabled{REMARKSBOX}

https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396
offers a canonical of
https://tiki.org/forumthread50396

Good.

Now, it also has two links:
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396&display=print
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396&display=print_all

The print versions should have the canonical as well.

Please see:
http://www.seomoz.org/blog/canonical-url-tag-the-most-important-advancement-in-seo-practices-since-sitemaps

tiki-print.php -> tiki-index.php

In trackers, if you find a tracker item following a search, you have some parameters in the URL for item 6 of 70. The canonical format should be just the tracker item.

In blogs,
tiki-send_blog_post.php?postId=xyz
and
tiki-print_blog_post.php?postId=6079
should be:
tiki-view_blog_post.php?postId=xyz

Among several, there is one very big limitation of the shopping cart:

It cannot handle currencies! I wonder why no one saw this before (and I have to add, when debugging the translation of Tiki, it did not occur to me either). Cart must store the currency linked to all products. The currency of the user must be user-selectable (Of course, at the admin's discretion, the set of available currencies must be limited). We need to modify the data structure. The currency MUST become a separate field, and with that the price becomes strictly numeric (It could and should be discussed if we make that integer in the small currency units, but display it with the decimal comman/point inserted) and the currency should be strictly the three-letter ISO code, but a representation of that could be selectable (€ for EUR for instance).

If user currency and currency of any stock item differ, currencies must be converted. Currency conversion isn't easy. The first and easiest solution is having fixed conversion rates. These MUST be prominently and transparently displayed to the user, as they become part of the contract between the user and the admin/owner of the Tiki. Also, some sort of fee for currency conversion must be selectable by the admin (0 of course being the default), and it, too, must be prominently and transparently displayed.

When fixed rates have been established, the next level of comfort might be automatically set/updated rates. For that, we would have to find a reliable provider. Also, since all providers might for some reasons fail to supply data at any given time in the future, a default minimum and maximum rate must be selectable by the admin.

At first, I thought this could have been overlooked because of a domination by the US, but then it crossed my mind that even Americans have the need for currency conversion, because they got US and Canadian dollars, and when they sell internationally, also Australian and New Zealand dollars...

In Europe it is much more complex. Most countries have the Euro, but not all. Great Britain does not, but now it's not even part of the EU anymore. In the German speaking countries we have Euros (Germany, Austria) and Swiss Francs. Even though Switzerland is also no member of the EU, the fact that a large portion of Switzerland speaks German leads to Swiss users using German Tikis, and vice versa.

When assigning a catogory with restricted permission, the permission usually override the global permissons.

When assigning a category to an individual image, the visibility is however not restricted.

I would like to use tiki as a Document Managment Solution (apart from other things I use it for). To do this I would like to assign one or (typical) more categories to one file within a file gallery. Using categories inside a file gallery would make it much easieren to manage huge numbers of files.

At tiki-admin_categories.php?parentId=2&cookietab=3#content_admin_categories1-5, Add objects, you have a selector field that display all the pages available for categorization (the pages that are not in this category). It show only 5 pages and it make the user action quite uncomfortable.

https://ibb.co/yWDWL67

It should be possible to expand this selector and display more pages.

I have a file gallery with many files.
If I assign the parent file gallery to a category, only this object will be assigned to the category and, if I want the assignment to be recursive, I have to assign one by one the files.
This is bad UX and in case of many files very hard to achieve without errors.

We should have a way to assign a file gallery and all the files within to a category.

See: https://tiki.org/forumthread79150-Is-there-a-way-to-categorize-all-the-children-of-a-file-gallery

Bloggers often have blogs that are about ''them'', rather than about a topic. But within their blog, individual posts should be categorized by topic(s). I.e., it's the post, not the blog, that's the right unit of categorization.
I have seen a RFE for this on tikiwiki.org, where there's an interesting page on Tiki Blog suggestions of vintage about 2004. See [http://tikiwiki.org/tiki-index.php?page=BlogIdeasPaulap]. Possibly we should make a pass over this page and either add these suggestions as tracker items or identify them as out-of-date.

There is currently no history of changes to categories.

Since permissions can now be restricted by categories, it is more & more important to know when an object is changed from one category to another.

Therefore, we need this info to be logged in tiki-syslog.php and to be added to the watch item feature.

Reminder: categories can be assigned in tiki-admin_categories.php but also when editing a wiki page.

I would like to take work from my users (so basically myself) and categorize automagically.

I am thinking of some kind of

Type: Category
Options: parentId, 1

where 1 would mean to automatically check all check-boxes.
Then I'd make the field invisible and mandatory(is that needed any more) and voila - no one realized you got some more metadata.. ;)

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.

The very useful wiki plugin catorphans only works with wiki pages.

The documentation suggests it is sort of set up to deal with different types of uncategorised objects by setting the objects=> parameter to various values ie wiki|article|blog|faq|fgal|forum|igal|newsletter|poll|quizz|survey|tracker.

But looking at the plugin code, the code comments make it clear that the development is not yet complete and only the 'wiki' object has been coded.

The documentation has been updated to make this clear - but extending this plugin to the other features would be very useful now that Categorisation is the major permission/access control mechanism in Tiki

Tracker 1
X text field
Y text field

Tracker 2
Y text field
Z text field

Tracker 3
R item link to 1,X
S dyn item list of 1,Y by linking R=X
T dyn item list of 2,Z by linking S=Y <-- this one does not work

Our org is trying to create a tracker for short term employment vacancies. In the tracker we have a date field called "deadline" where we want an applicant to respond to the vacancy before that date. What we would like is for the vacancy (tracker item) to change status to "close" after that date automatically.

I have found in [http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1694] that [http://dev.tikiwiki.org/tiki-user_information.php?userId=21|sylvie] made a comment:
""
- must be finished before can be a date field. what happens to the item after? (I have on my list 'an item change status after n days')
which sounds roughly the same as what I am trying to accomplish.
""
Can someone elaborate or let me know if it is possible to automate the closing of items?

Thanks,
Tim

Feature suggestion: add a permission to "change group viewpoint"

This would allow a member of many groups to see a drop-down of his groups.
Choosing another group would allow only to see what members of this group can see.

So admins would be able to check that their users's groups permissions have been set up properly.

I have a site where saving (or cancelling editing) a wiki page wasn't working, you just get the same tiki-editpage.php back... After a lot of searching i found it was due to a php.ini setting called -+max_input_vars+- which defaults to 1000. And this site now has 1016 categories! (:eek:)

My proposal is to make a better category picker which can use a hidden input to contain a comma separated list of the category id's selected as on single input, instead of having 1016 individual checkboxes on the form.

So let's find a nice, hierarchical picker to do this, maybe a Vue JS one? Or maybe this should be an extension of -+object_selector_multi+-

Right now, there's no way to resend either the email to the admin to validate a user or resend the email to the user to validate their email address. If either of those emails fail to happen or they get sent to "spam", the user cannot log in.

possibilities:
http://phpmailer.codeworxtech.com/
http://www.swiftmailer.org/
http://framework.zend.com/manual/en/zend.mail.html


Related:
SMTP Configuration from inside Admin Interface
http://dev.tikiwiki.org/wish1711

Tiki smileys are so 90s... It look very bad.

:)
;)
(:santa:)
(:twisted:)

Really ?

--drsassafras begin--
This seems related to : https://dev.tiki.org/item6191 and https://dev.tiki.org/item6189

I looked into the issue not so long ago. Almost all browsers now support emoji. Desktop and mobile. If we enable the saving of emoji in our database, they will all show nicely, and will always be kept up to date with the OS/Browser.

A little emoji selector could be made for users who dont have a emoji keyboard set up, and the existing similes used here could be integrated.

Although, it might be easier to replace the emoticons with new ones in the mean time.
--drsassafras end--

It is currently not possible to change the owner of an image gallery.

Since this user has special rights, it should be possible to change it.

Since wiki page names should avoid special characters, we'll need to think about maybe using character substitutions in page names (a instead of à, _ instead of ') and use the description field for the exact format.

Please coordinate here: ((Character substitutions))

*.Tiki.org sites have a large number of external links. It would be nice to have a tool to check all the links and to report on status. Possibly this could be related to the cacheing feature.

See: ((Link Checker))

Please see:
http://en.opquast.com/bonnes-pratiques/

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.