Category: 4.x

Permissions on individual wiki pages are great.

But what if you want to change the perms


__Related__
{WISH(id="2151")}{WISH}

{syntax type="tiki" editor="plain"}
I have "Method to Open Directory Links" set to __inline frame__
This is not working. Instead, I get the behavior of __Replace Current Window__
Check for yourself at
SpecialParent.com

Productization: Create admin preference to enable/disable minify
https://bugzilla.mozilla.org/show_bug.cgi?id=502092

Implement Admin panel/setting to flush/rebuild Minify cache
https://bugzilla.mozilla.org/show_bug.cgi?id=497703

[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=minify&product=support.mozilla.com&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=|All "minify" related]

This cache should also be deletable


http://code.google.com/p/minify/

When editing a wiki page, clicking on any of the toolbar icons:

{img id=102}

causes page to refresh.

Tested with FireFox 3.5 (linux) and IE 6.

If the page is edited using the edit icon (which loads the editor using Ajax), then the feature does work.

This feature works on previous version of tiki (3.x) with the same browsers.

Tiki cache was ceared. No difference.

On at least two sites, running respectively 3.x and 4.x:

- jiamcatt.ourwiki.net (3.x)
- terminology.tikiwiki.org (4.x)

I noticed that if I change a wiki page and save it as a minor edit, email notifications are still being sent.

I think that this only happens when the user is part of a group for which a Group Watch has been set. When I tested on the 3.x site, that's the conclusion I had come to (this AM, UK time). But this PM (UK time), I tested on the 4.x site, and it seems that the minor edit is causing notification even if a user-defiined watch (i.e. as opposed to a group watch) is set.

BTW: This bug caused a minor incident on the JIAMCATT site. Someone did about 30 minor edits to a page that was being monitored by a large number of people, because he was a newbie and was trying to master the syntax for referencing a section inside a page. As a result, 30 notifications got sent to a hundred people, and some of them got pretty pissed off, and almost walked out on the site. One person asked to be "taken off this infernal web site".

So, if the bug can be fixed quickly, I can go back to this community and tell them that something was done to prevent that sort of problem in the future, which might diffuse the crisis.

While digging through some html I found the following:

{CODE()}<div class="rbox-data"">{CODE}

the line in remarksbox.tpl is:

{CODE()}<div class="rbox-data{$remarksbox_highlight}"{if !empty($remarksbox_width)} style="width:{$remarksbox_width}{/if}">{CODE}

When the second if statement evaluates to false an extra double-quote is still output.

When editing a new File Gallery or modifying an existing Gallery, no Parent-Gallery Selection box is shown. Thus you can neither create new File Galleries nor move existing File Galleries to other parents. (See {img id=109})

Contrary to TikiWiki documentation (and contrary to TikiWiki common sense) it is NOT possible in a 3.0 wiki (specifically http://jiamcatt.ourwiki.net) to assign any permissions to Newsletters. This means that NO ONE, other than Admins can even see the list of Newsletters, to say nothing of viewing past newsletters (the archives). This is unacceptable – and contrary to TikiWiki documentation.

JIAMCATT is the community of IT-oriented managers of language (translation and interpretation) services of major International organizations and European multilateral bodies. After a slow start about a year ago this community has now agreed to try to use a TikiWiki-based system. Within the past month (since several of the TikiWiki team participated in the JIAMCATT annual meeting in Ottawa, Canada early May 2009) close to 200 users have joined up.
One key aspect of the work of JIAMCATT are Working Groups. One of these has just started work. It’s tools include wiki pages in the two working languages (En + Fr), a discussion forum (consisting already of 13 topics), and – last but NOT least – a Newsletter to keep everyone abreast of developments. This feature, it now turns out doesn’t work in a very bad way: NO ONE, other than Admins can even see the list of Newsletters, to say nothing of viewing past newsletters (the archives). This is unacceptable – and contrary to TikiWiki documentation.

I expect this should be a simple fix for a TikiWiki insider (the feature existed at the time the documentation was written); albeit impossible for someone not intimate with the insides of this system.

Screen shots are attached. The first – now shows as the last – called “ButtonsAvail-inJiamcatt-ourwiki-net-Newsletter-admin.gif” shows the buttons seen by an Admin user when trying to do “Admin Newsletters”. The second, called “MissingButton-from-doc-tikiwiki-org.gif” shows the buttons in doc.tikiwiki.org in the http://doc.tikiwiki.org/Newsletters section in the http://doc.tikiwiki.org/tiki-index.php?page=Newsletter+Admin&bl=y page, under the segment titled “Changing Existing Newsletters”. The third screen shows you what a non-Admin user who should have access to view newsletters and archives of this Working Group, sees (file: “Empty list of newsletters for (nonAdmin) WG members.gif”).

Unless someone can provide a fix quickly, this group will abandon TikiWiki as its working tool.

omstefanov

{syntax type="tiki" editor="plain"}
I started today collaborating with translation into Portuguese language.
My first edition the page [http://doc.tikiwiki.org/tiki-editpage.php?page=Usando%20Páginas%20Wiki|Using Wiki Page (pt)]

the moment I clicked SAVE, I got an error page.
I created a PDF document from it.
As this is my first Bug report I hope I will be able to send the PDF attached to this Bug Report.

Current mod GMAP does not work in 4.2.

Not sure about other versions

My wiki (http://wiki.alphasoftware.com/, on version 4.2) intermittently fails to respond to mouse clicks for module box and menu expand/contract toggles, tab buttons for administration interfaces, the button to toggle between WYSIWYG and Normal editing, and other buttons that invoke JavaScript Ajax actions.

Changing random administrative settings or themes sometimes changes this behavior, but it still seems to come back.

I think it might be a bug, but I might also have some inconsistent settings.

I am willing to upgrade to the trunk build if these are bugs that have already been fixed.

module calendar is only showing one letter for the week days. However, some languages (such as Catalan, at least) have all week days starting with the same letter, which produces a useless letter on the top (if you take into account whtat it might be showing sunday in the first place instead of monday, which is the first day in the whole spain, Andorra and other Catalan speaking countrees.

example of useless calendar week days:
http://moviments.net

or maybe just add a popup (overlib?) tip with the full name of the week day when the mouse pointer is over the letter?

I have set feature_comment_moderation=y, so new comments are invisible until approval, but they are shown as new comments on the since_last_visit_new module. So if user clicks on this link they come to the page where the comment was made (currently only tested with blog comment, but should be the same with other comments), and don't see this new comment.
I've no idea if this also affects coming version 4, only working with v3.2

{syntax type="tiki" editor="plain"}
In trunk, I noticed around r22263 so was some time shortly before this revison that modules in trunk don't have the module-flip icon. I don't think there's been a change in module.tpl, so somewhere else the function to enable it has changed, apparently.

Tiki 1.9.8 ships with 94 modules. (excellent)


Need a "module manager"

Module should come with a screenshot or preview.

A page listing all modules with descriptions and parameters- grouped by feature.


currently, the "user modules" and "assigned modules" titles are very non-intuitive. Should say "custom modules" and "active modules"




However, all modules are listed at all times. Module listing should check for features which are activated. It would be easier on new Tiki admins. For example, if articles are deactivated, don't show me last_articles in tiki-admin_modules.php



Admin modules does not display titles of available modules or provide easy method for selecting unused modules, such as with a listbox. The missing information is not available unless a Tiki admin has system admin permissions.



Also, all possible parameters for the current module should be listed (or picked from a drop-down)
See:
[http://doc.tikiwiki.org/Module]



Related:
Plugins admin interface
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=502

In the calendar, you can schedule a recurring event to happen weekly. In my particular use case we use TikiWiki for, among other things, tracking who in my department is carrying the 24/7 pager so everyone knows. There are between 5 and 7 of us depending on turnover, and we take turns holding the pager for one week at a time each.

With current functionality we must manually enter the pager schedule and re-do it should anyone quit or get hired. It would save us a lot of time if we could just say person A gets pager every 6 weeks, followed by person B, C, D, etc.

{syntax type="tiki" editor="plain"}
Multiple problems exist with TikiWiki tiki-js.js and tiki-jquery.js scripts in relation to editing wiki pages with the Wiki editor. The problems vary by IE version:

* IE requires the 'label' property to be set in 'Option' objects
* IE editing requires use of textRanges

When a structure is printed using multiple print, then the page aliases are ignored.
The TOC shows numbering and aliases correctly.
But the page within the print output shows numbering and page name instead of alias.

This is not only inconsistent, but a major problem:

All pages in TikiWiki must have a unique name. So, in case you need to create similar structures multiple times, you'd need to define some prefix for the page names to keep them unique.
This results in rather ugly page names.

Example:
A section "Client Overview" is mandatory in the structure.

The structure is created for some module "Module A" and some module "Module B".
You'd now prefix the pages, resulting in page names "ModA_client_overview" and "ModB_client_overview". That works okay, no problem, you can simple create aliases "Client Overview" for the pages.

The TOC then prints "1.1 Client Overview". That's correct.

But why does "1.1 ModA_client_overview" appear in the printout of the page instead?!

Say I am on dev.tw.o and I want to follow-up with a user, I end up on his tiki-user_information.php?userId=xxx __here__.

I should have a link to his page on the master.

Or else, users will end up with user-messages on various *.tikiwiki.org sites.

{syntax type="tiki" editor="plain"}
it seems there is a bug in 4.1 not allowing to assign perms per file in file galleries. i can only download the file as anonymous if i assign tiki_p_download_files to the whole file gallery where the file is saved in but not when the file is categorized in category with that permission assigned (which should work)

This tracker item could not be found

Two aspects:

A- Alternate theme for certain browsers:
Ex.: simple theme for IE6 or pocket browsers.

B- Showfor plugin, as developed for Support.mozilla.com


Should the plugin be called SHOWFOR? (if so, it's should be quite generic).

*printer
*various browsers
*mobile versions
*users, groups, perms, upon feature check
*etc

Even if the generic plugin is not called browser, SUMO can continue to use SHOWFOR (And avoid needing to edit all the content) thanks to ((doc:plugin Alias))

See: ((Alternate content by media))

Many banner advertisers use a javascript for banner adverting. Currently, there is no way to add a JS-based banner.

*polls (Could be with trackers)
**need a way to insure people vote only once (more of a voting system than polls).
***Possibly with unique URL sent by email
***Not sure, but probably that votes need to be anonymous (We know who voted but not for whom)
**Need a way to remind people that haven't voted.
***CRM style wiki & tracker merge
****Do a query on trackers (ex. people that haven't voted)
****Cross with a wiki page to create a form letter "Dear XYZ, according to our records, you have not voted. Please click here to vote.


__Related__
{wish id=2388}

{syntax type="tiki" editor="plain"}
~~#f00:__Update, DEC 30 2009 - __~~

(1) Shadowbox/Colorbox is working in Wiki pages
(path error 1st time around - my fault)

(2) Shadowbox/Colorbox still ~~#f00:__NOT__ working ~~in File Galleries.

(3) Slideshow works in File Galleries __ONLY if using Mozilla Firefox or IE 8, if IE 8 not running in compatibility mode__ (I.E. 6,7 fail to display the slideshow)

---------------------
Neither the slideshow nor the new colorbox (shadowbox replacement?) features seem to work in Tiki 4.0. Both slideshow and shadowbox have checkboxes in the Admin panels. Are there any other supporting features that need to be enabled.

Note: The thubmnail generator seems to work much better for the file gallery in 4.0 than in 3.x or 2.x.