Category: Feature request

{syntax type="tiki" editor="plain"}
when selecting a parent gallery on a deep gallery structure it would be nice if
# galleries not which are not a direct child of the root gallery are marked with "..." at the beginning
# galleries are marked with the (ID) at the end.

there are scenarios where the two displayed levels in the selection box are ambiguous.

For example, on a wiki page like:
tiki-index.php?page.php?page=genericwikitemplatepage&itemId=50

I could see the values of various tracker fields for itemId 50. Ideally, I could use various wiki formatting for this data.


{img src=images/code.png}%%% {CODE()}
Here is field #417 for trackeritemid #50
{TRACKERITEM(field=>417)}{TRACKERITEM}

__Here is field #460 for trackeritemid #50__
{TRACKERITEM(field=>460)}{TRACKERITEM}

^
Here is field #72 for trackeritemid #50__
{TRACKERITEM(field=>72)}{TRACKERITEM}
^

{CODE}

Active Directory doesn't allow for anonymous searches of its structure. Instead, an username and password for an account with search access must be given when connecting.

The payment feature should call PayPal in the language of the user. Currently, it only calls the English interface. While inside PayPal, users can switch language, but not in the part that is on Tiki. This starts with the "Pay now" button, which is unnecessarily English only.

{CODE(Colors="Tiki")}
<br><input type="image" style="display:block; margin-left: 15px" name="submit" src="https://www.paypal.com/en_US/i/btn/btn_paynow_LG.gif" alt="PayPal" title="{tr}Pay with Paypal{/tr}">
{CODE}

Obviously PayPal supports ISO country codes for that, so this call for the PayPal button should IMHO be pumped through tra(), so it can be localized, but also the country code user pref could be used here, so the button appears in the user's language and not in the site language.

Has anyone written a module to integrate PayPal's ecommerce capabilities into TikiWIki?

Should be done through a module and several plugins (ADD_TO_CART, SHOWCARTCONTENTS, CHECKOUT etc)...

Oh, on that one, I would love to have a plugin that invalidates the cache to make sure that inside a cached website there are pages that are always rendered fresh...


Related:
*[wish1808|Shopping Cart / ecommerce / online orders]
*((shopping cart))

As a wiki page has the option to be exported as PDF, in the same manner it would be useful to get the option for articles.

first of all excuse me for accidentaly logging with this account

version v1.9.0 -Sirius
I am working on setting up a tikiwiki in bulgarian language for internal usage.
I have made partial translation of the language to bulgaian (keeping the UTF-8 encoding)
The main encoding used in BG is windows-1251 (it sucks and is tottaly incompatible i know)
I have a very simple page which is in cyrilic (bulgarian) in the DB it is stored as UTF-8.
When trying to generate PDF the process passes just fine. The only problem is that all non english text is seen as question marks.

I have tried changing te WinAnsiEncoding to builtin in class.pdf.php, but that doesn't help. If you need i will provide a samples from WinAnsiEncoding and builtin

All suggestion's appreciated

__This feature request was accidently submitted twice.__
__Please use only [item6469]__

See here:

https://dev.tiki.org/Newsletter#Roadmap

__Per user/group newsletter administration__ based on category permission or on object permission.
* It should (shall) be possible for specified groups to provide an own group-newsletter created by a superuser, which then could (shall) be administrated by one or more specified group members / group admins whilst the newsletter admin of one group cannot (shall not) administrate or alter the newsletter(s) of another group.
* This could be accomplished by adding to the code the opportunity to categorise newsletters and to add certain admin-permissions like tiki_p_batch_subscribe_email, tiki_p_send_newsletters, tiki_p_subscribe_email, tiki_p_subscribe_newsletters, tiki_p_view_newsletter, tiki_p_list_newsletters to the category permissions (not tiki_p_admin_newsletters)
* There should be a distinction between tiki_p_admin_newsletters which includes the permission to create a new newsletter and the now not (yet) existing tiki_p_admin_newsletter which would limit admin permissions to the specific newsletter.

See here:

https://dev.tiki.org/Newsletter#Roadmap

__Per user/group newsletter administration__ based on category permission or on object permission.
* It should (shall) be possible for specified groups to provide an own group-newsletter created by a superuser, which then could (shall) be administrated by one or more specified group members / group admins whilst the newsletter admin of one group cannot (shall not) administrate or alter the newsletter(s) of another group.
* This could be accomplished by adding to the code the opportunity to categorise newsletters and to add certain admin-permissions like tiki_p_batch_subscribe_email, tiki_p_send_newsletters, tiki_p_subscribe_email, tiki_p_subscribe_newsletters, tiki_p_view_newsletter, tiki_p_list_newsletters to the category permissions (not tiki_p_admin_newsletters)
* There should be a distinction between tiki_p_admin_newsletters which includes the permission to create a new newsletter and the now not (yet) existing tiki_p_admin_newsletter which would limit admin permissions to the specific newsletter.

Use case:

We want users to update their profiles every once in a while.

So the system should be reminding users to click on tiki-view_tracker_item.php?view=+user and update their user profile.

Eventually, an email reminder could be cool as well.

Like this site:
http://agilewebsolutions.com/downloads


When you scroll down, the menu stays. The same idea could be done for a menu on the bottom of the page.

There is no permission to set the behavior, that registered users can create surveys theirself.
This would be nice to give some groups also the right to create and manage their own surveys, not just by the global permission...

There are case admin / webmaster / editor of a website need to communicate to all its users or group no matter what preferences they set for communication.

That was the idea that lied under the "Broadcasting" feature.
Actually by default users are not accepting messages and this is simply killing this feature. While there are questions about this default setting (should it be enable or disable by default) one thing is sure when you want to contact ALL you need to be able to contact ALL with regards of other preferences.

As this is a sensible setting (we don’t want people having access to spam) it would make sense to have a permission for it so Admins decide if and who has the ability to force a message to reach everyone (internal Tiki).

A check box with a warning (are you sure you want to...) added to the permission is what we need.

Thanks Jonny for volunteering. ;-)

To allow groups to see a picture or a video stored as a file in Tiki it is necessary to enable "Can download files (tiki_p_download_files)".
On the technical point of view, allowing to download a file store in a file gallery allow to view this file content on a page if the file is a media.

But this is quite confusing for common mortal and new admins. Many time I saw people stuck with this.

For example, an admin want to __display__ a image from the file gallery, to __make visible it__ to his Anonymous visitor. He need to enable "Can __download__ files (tiki_p_download_files)".

Re-wording the name of the permission to "Can download or view files content (tiki_p_download_files)" look still too technical in my point of view.
... Adding a clone of this permission (same of the same) with a different label "Can view media (images, video, Audio, diagram, etc.) (tiki_p_download_files)"

Someone clever should suggest the good way to do it. ;-)

Would make things easier to manage permissions.

A first not yet integrated, but usable feature preview for the "Areas" feature

I wish a perspective session (when switched into a perspective) didn't expire so soon. I need to re-activate the perspective view several times a day when logged in onto a site (avan.tech). I dunno the precise time set to expire the session for perspectives but it would be nice to keep it at least for one day but optionally to have it configurable (like we have for the remember me session for example). Presumably it is a cookie which expires too soon and returns user to the default perspective.

Thanks!

http://suite.tiki.org/Tiki+Suite is a perspective of http://tiki.org/

In mobile mode of http://suite.tiki.org/, we get "Too many redirects" or "This webpage has a redirect loop". You can also get this by going into mobile mode from suite.tiki.org

{flash type="url" movie="display665" width="1071" height="549"}

Thanks to Simon Boulet for reporting

Just find out that File Gallery doesn't support Photo EXIF Orientation.
see a sample image of below, it should be in landscape, but shown as portrait.

{img fileId="705" thumb="y" rel="box[g]"}

I believe more and more users will start to upload photo directly to Tiki sites using mobile, the orientation handling is important.

Please help to enhance and include it in future releases.

My workplace as well as others I suppose blocks any url with "pics" in it. I have tried to change it myself to ïmg2" and found a few references in .php, .css and .js files but couldn't find many of them even searching the MySQL database.

Please consider changing the name of the pics directory to something else that wouldn't likely get blocked by corporate proxies.

Thanks!

A request about the Bug Tracker / Wishlist itself - but maybe it already exists but I did not find it -

can someone create a Pivot Table to analyze the types of bugs so we can quickly see the percentages of each?
Should help better understand where efforts need be directed, for a coherent approach to improving overall quality.

This might help create at least a type of 'passive' Quality Assurance effort (vs. putting out fires) which Tiki very much needs.
Maybe a 1st step towards some type of ISO standard https://www.iso.org/ics/35.020/x/ though many, not sure which ones are most/least relevant (road map would need to be created).

Thanks,
Mike

Pivottable allows to use activitystream as source data.

This offers the field modification date (day)
Pivottable usually wants to aggregate data for charts or tables to be meaningful, and that requires the aggregation of single data points overt common time frames: weeks, months, etc

It would be very useful if there was some way to let the user display activity stream data over weeks, months, etc.

With tracker data, you can do a workaround with a mathematical calculation field and using the Calculation syntax to get the week or month from a date field, etc. But with activity stream, I don't get how to achieve that.

This is going to be very useful for Tiki site admins to find insights on how their users are makeing use of their tiki sites over time.

Reproduced here:
http://xavi-9794-6803.show2.tikiwiki.org/tiki-index.php?page=Profile_Activity_Stream
u: admin
p: 12345

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

If Trackers had the "tracker template" feature, it would allow for better pre-made extended features for Tiki at install time.
In tw.o forums, some people requested like: address books (imagine with the same basic fields as Mozilla Thunderbird & Evolution, etc. address books, ... Export from you local program (through csv), and import to your address book in Tiki (through csv).

The same for "Offers & Demands (linked or linkable)", that many people/communities would like to use like "out of the box" feature. I do have that kind of trackers made (basic, but working for production already: http://valldelcorb.org/trackers - http://valldelcorb.org/Comparteix (1.9.x) or http://intercanvis.net (1.10.x) using tracker plugins in a general Wiki page).

Since duplicate tracker is already coded in 1.10, and templates concept already exists in Tiki, Tracker templates would be a nice MUST in the MID and LONG run.

Tracker templates should be selectable at install time (in the new installer devs. are thinking/designing -> ((Install)) ), or at a later stage through Mods, maybe?