Category: WYSIWYCA (What You See is What You Can Access)

To reproduce:
* As a user with non admin rights insert a tracker item to dev.tw.o/tracker5
* edit it again, and change something (add some text to a text areas, etc.) And save
* you are not able to edit that item any more because the "Submitted by" field has lost the record.
* edit that item as a user with admin rights, adn manually provide again the username of the poster.
* the poster can edit it one more time. But after that, he loses the ability again.

...

Example:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2885
---
testing this bug
---
2nd edit

Using 1.10cvs from mid June 2007.

This problem is on at: http://moviments.net/intercanvis

User tracker is on, it's created and working (at registration time everything is ok and working, user sets new data for the user tracker info before ending registration, etc.). Well, at least for Registered users.

This morning I went (as a user with admin privileges) to User Preferences screen > Personal information > Your personal tracker information: "View extra information" (link to [http://www.moviments.net/intercanvis/tiki-view_tracker_item.php?view=+user] ),

but at that link I get this message:

^
-=ERROR=-
No tracker indicated
Go back
...
^
This user belongs to Admins, Editors and Registered groups, but has no one defined as default.
When defined a default group (Registered, the only one with user tracker defined), the link worked.

Contributors

Contributors

Contributors

Categories are amazing for a large site. It makes it easier to manage. Next step is to add an option in search which can be filtered by category.

Using Tiki 5.0: anonymous shouldn't see "watch" icons when browsing category tree.
And they can.
Reproduced here, for instance:
http://intercanvis.net/tiki-browse_categories.php

Bugs & Wish list

Logged in, go to:
http://profiles.tiki.org/tiki-pagehistory.php?page=Tiki+Transforming

You will see a bunch of action (Source, Permissions, History, Export, etc). These actions should be WYSIWYCA

Nowadays, Tracker item rating cannot be seen nor selected if using either ((doc:PluginTracker)) or ((doc:PluginTrackerList)). However, it can be seen (for anons) and voted for registered again, after some recent fixes by Sylvie! (thanks Sylvie :-)

I tested that here in dev.tw.o (for instance):

http://dev.tikiwiki.org/Calendar

(not showing ratings even if they exist; check [tracker5])


2007-08-13 ML: But this will conflict with wiki page cache. (because value of my last vote is shown, and likely different than yours).

2007-08-13 Xavi: If cache is the problem for this feature request, why not forcing/advising the user to avoid using cache (at least in this page) if he/she wants this tracker field correctly show on the page? (in case this feature is considered interesting enough). I leave to consideration by coders... It was just a suggestion which I would find useful.

2007-12-09 ML: Fixed in BRANCH-1-9 by Kerrnel22. You need to add tracker field ID to trackerlist plugin.

__Wiki page cache with trackerlist ratings needs to be tested to see what the real issues (if any)__

In Tiki 1.9.8.3, even if the feature is off, you can see references to trackback pings in tiki-view_blog.php , tiki-view_blog_post.php, tiki-edit_blog.php and tiki-blog_post.php

Proper feature checks for {$feature_blogposts_pings}, {$feature_trackbackpings} and if the feature is activated per blog should be done.

for users with tiki_p_wiki_view_comments perm only, it displays the ~np~[comment]~/np~ link on the wiki page bar even when no comments there yet to read, so clicking it does literally nothing...

Can someone give more details on this one?

I believe the problem occurs when someone goes to edit a page then uses the browser buttons, links or types a new URL without clicking either the svae or cancel buttons. -- mdavey

A related issue is that the lock is checked /before/ all the permissions checks have been done. The result is that one can try to edit a page as anonymous, get an error warning, login, try again only to be told that 'Anonymous' is editing the page. -- mdavey

obs: waiting for cvs to unlock to commit

Spreadsheets can be created directly through wiki SHEET plugin directly within wiki pages. this allows managing big tables visually, as well as having the data ready for producing graphs, etc. (see documentation for tikisheets at doc.tw.o, if needed)

However, when you create a sheet through a call to the SHEET plugin from the wiki page itself, there are 3 issues which need to be fixed:
# you need to know the id you want to assign it to,
# after that, tiki-sheets.php doesn't list it (even if the sheet is really created, and you can import data to it, and show it at the wiki pages, etc.).
# the sheet is not shown with the right css

Even if we have wysiwyg option available, I still think that is worth improving tiki sheets usability to be used directly from wiki pages, once those 3 previous issues are fixed.
---
Updated on Feb. 2, 2011, using trunk (7svn)
# Steps to reproduce the first issue
## Edit a wiki page
## Use the plugin helper to create a new sheet in that page. And since it's a new sheet, it doesn't have a sheetId yet, so that you leave all fields empty in the plugin helper for the pluginsheet
++ this will add this type of code in your wiki page:
++ {CODE()}{sheet}{CODE}
## Save the wiki page
++ you will see an empty sheet shown in place at that wiki page, with the button at the bottom to allow the user to "edit it" (so far, so good)
## Once you click in the edit sheet button, you end up in some url like this one:
++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=&parse=edit
++ which produces a WSOD (blank page).
*** In my case, I guess that this url should have been:
+++ http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit
+++ since I had only one sheet previously created, with sheetId 1, so that the next one should be 2. However, this new url is still producing WSOD for me. (tiki caches cleared, just in case, repeated this step, and same WSOD)

The expected behavior is that the user is the user would be editing a blank new sheet with the url:
http://localhost/tiki7trunk/tiki-view_sheets.php?sheetId=2&parse=edit

and when the user saves that sheet, the new sheetId 2 exists, and the user is either sent back to the wiki page where he clicked at the button "edit sheet" (preferable option) or either sent to the corresponding tiki view sheet 2.

Contributors

Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

Editing a simple wiki page, converted into wysiwyg, added new content, saved page, and nothing of the new content is saved (old content is shown at save time and when visiting the page again)

Contributors

To reproduce, go to:
http://tikiwiki.org/tiki-browse_gallery.php?galleryId=18

and, as an anonymous user, click on "list gallery", you will be sent here:
http://tikiwiki.org/tiki-list_gallery.php?galleryId=18
"Permission denied you cannot access this gallery"


Should tiki-list_gallery.php use the same perms as tiki-browse_gallery.php? Right now, it seems to be only for admins.

Mmmm, file gallery contents cannot be viewed if anonymous and language selected is catalan. Example:

[http://gclub.ub.es/file6]

Change language to english or any other, and the contents will be shown.

I'm not sure but I would say that this didn't happen before I updated to 1.9.8beta (yesterday)

----
May be related to that older bug report?:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1204&trackerId=5|Listing a file gal. in CATALAN returns smarty error for admins, and blank page for reg. users]

When Intertiki is on, mod-login_box.tpl should show some info on the login box reporting where to register in order to log into that site. Example: edu.tw.o., with tw.o registration.
I've done this by hand:

^Intertiki is enabled. Log in with your account at <a href="http://tikiwiki.org">http://tikiwiki.org</a>. <br><b>New?</b>: <a href="http://tikiwiki.org/tiki-register.php">register at tw.o</a> and come back to log in here.
^
{CODE(wrap=>1)}
Intertiki is enabled. Log in with your account at <a href="http://tikiwiki.org">http://tikiwiki.org</a>. <br><b>New?</b>: <a href="http://tikiwiki.org/tiki-register.php">register at tw.o</a> and come back to log in here.
{CODE}

But this could be added more general on tiki, so that it checks whether intertiki feature is on, and get's the name of the intertiki server from some value at your tiki isntallation, and then, the message is customized on the login box.

Contributors

Blog post edit page (tiki-blog_post.php) has a "Mark entry as private" check box, to restrict viewing to the author. But it doesn't work; any user can read the post.



Needs to be fixed or the option removed from tiki-blog_post.php in time for 1.10.0

Since some weeks ago, afaik (April 2008, or so), menus and menu options cannot be seen for anonymous on several sites that I admin, including edu.tikiwiki.org, if you select some themes. Example: moreneat.css

On others, like http://moviments.net/ilp (using nornia.css), the menu on a module assigned to anonymous and registered, was shown when you logged in. Right now I've just assigned thatmodule to admins only, and used menupage module, which works fine. But I can re-set the previous config. is somebody wants to reproduce the missworking.

The module freetags_morelikethis shows links a user has no permission to view.

I have to introduce a knowledge management system in our company and am convinced that TikiWiki is the solution to go.

The problem is:
- lots of data is classified (categorized)
- Tags are required to build a network of the knowledge
- the users will not accept a system that leads often to "permission denied"

Without this module being WYSIWYCA I cannot suggest TikiWiki to the management.

obs: waiting for cvs to unlock to commit

Bugs & Wish list

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

Our community needs some forums for the administrators only so that we can pass messages back and forth. However, there's no way to make any of this private. Any registered user can read and post what need to be private forums. In many cases you don't even have to be registered to read.

In the early days of TikiWiki, we used a bunch of modules (last_modified_wiki_pages, last_articles, Last this, Last that, etc.) to show recent changes to visitors. We ended up with many modules and it was cluttered.

All this became a lot better once the "Since your last visit" module came around to adding all the features. As a bonus, it checks permissions and shows the information since the user's last login. Very sweet.

Now, I am hoping to get to the same result for the many edit/input boxes.

In version 3.0, the quick_edit module checks (with Ajax) for names of existing wiki pages to edit. This avoids duplication. Great stuff. Wikipedia does something similar when you are searching for a page name.


I almost always have the search box on.

However, I also add "search page name" because the general search engine may not return the page I am looking for as the search result.

Here is an idea:

A new module which combines three modules:
search_wiki_page
search_new
quick_edit

See top right of http://moinmo.in/ for an example.

The action buttons are grayed out until text is entered in the text box. -> Very nice


Button should be WYSIWYCA


See top-right search box at:
http://www.ohloh.net/projects/tikiwiki
http://www.wikicreole.org/



__Alternatively, we could combine search page name and search text, and in the search results, we would first show pages names, and then, search text. This involves more work, but could be better for the end user UI.__

^I think the existing layout for the search top right in TW is fundamentally good. A text box, then a drop-down then a button. Why because the drop down is more future proof than any of the layouts from the other sites you reference.

If we make the contents of the drop down easy to customise or at the very least document how to add to it. For example the CRM function could add items to the drop down for "Contacts" and "Accounts", webmail could add "Mail Messages" and so on.

I do agree the wikipage create/edit module should be included in the top right search function.

I think this is an example of where considering the future openness of the solution would be very important - MatWho^

{THUMB(id=98)}{THUMB}

permissions "minor" seems useless on doc.tw.o: registered can't use it even if granted to them
Check it live on: http://doc.tikiwiki.org
Login as admin to check that tiki_p_minor is granted to registered. Logout and login again as plain registered user, edit a page, and you don't see the "minor" button.

Registered users need it since it is a part of the interface needed for best interaction with new translation features on 1.10 (minor changes are not counted as new content to a page is being translated; if no minor, then a minor change to an outdated page reports to the up-to-date pages that new content has been added on other pages, and thus, lots of noise is introduced in the community)

Anonymous can view this gallery:
http://www.marclaporte.com/gallery1
And there is a list to the galleries:
Put I can't list the available galleries (available to anonymous)
http://www.marclaporte.com/tiki-galleries.php


There is a related problem with tiki-list_gallery.php where a :

if ($tiki_p_admin_galleries != 'y')

which prevents all individual image gallery permission checks

All plugins are on by default. I may or may not want that.

I think we should have an admin panel which lists the plugins which are installed on the server. The admin can then activate as needed.




Related:
WYSIWYCA for module administration
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1294

Anonymous users can see can view polls even though they don't have tiki_p_vote_poll

These files need to be checked:
tiki-old_polls.php
tiki-poll_results.php
tiki-poll_form.php

Setting that anon can vote in polls needs to be cheked too.
tiki-admin.php?page=polls

Sorry not to have a clearer bug report. Short version is that permissions for polls don't work as expected in 1.9.0

Please also see tracker #278

Three issues with recurrence rules in 3.0 (tested in 3.0beta1, at the http://tikiwiki.org/TikiLiveCD 0.5a)

# When you hit preview event (before adding the new event to the calendar), the recurrence rule data is lost.
# -- A recurrence rule conflicts with something else. I get "~~red:Events cannot end before they start~~", but the settings are not to produce this warning/error message. The event canot be posted to the calendar. See image attached to this bug report.--
# If admin has not set the default calendar to be viewed by default (I didn't even know about that new setting in 3.0), events are not shown in the calendar for each user until that single user clicks on "Visible Calendars", and select the calendar (even if only one!), in order to view the events he/she has just added. Another user has to do the same process.
---
updated May 4th 2009: the second bug report from the list of three can't be reproduced anymore, at least with tiki3rc1.
The third, seems fixed in a quick trial I?ve just made (I read days ago that nyloth fixed that).

The first one about the preview is still applicable.

If you save a page in WYSIWYG, Edit Section buttons disappear. (However, if just before saving, you Switch Editor to wiki, the Edit Section buttons will (re-)appear (:wink:))

Note also separate bug #3764, i.e. the Switch Editor button does not appear if your edit is invoked by a Edit Section button. This makes the first bug very discouraging for new contributors.

This bug is a big issue for sites wishing to encourage collaborative editing, especially with longer pages:
*Having Edit Section buttons at each heading cries out 'Edit me! Edit me!'. If they disappear, it is much scarier for a beginner to edit a page.
*If someone bravely uses an Edit Section button only to find that it has disappeared as a result of their work, they may think they no longer have edit rights. They will think the site is stupid, and be greatly discouraged re further editing.

section edit icons in non-editable menupage (from module) are shown when page in central column is editable.
(Ajax enabled, in case it matters)

The links in section edit icons open the central column page for editting, not the menupage one, but anyway, confusion is added to users... (plus icons non-WYSIWYCA on the menu page)

It should be easily reproducible on dev.tw.o.

Using Tiki 4.1.

New users are linking to:

tiki-assignuser.php?assign_user=


It should be:

tiki-user_information.php?view_user=

for users that don't have tiki_p_admin_users

Every time a new object gets created (wiki page, blog entry etc) the item recieves only global permissions.

It would help a lot if the admin could define 'standard permissions' for each group for specific features.
(needs to be integrated with improvements to "permissions by category" introduced in 1.9 - which provides a coherent approach for "object" based permissions to compliment user based perms.)

To keep wiki pages inside the group, the admin would assign the read right only to that group, and a member of that group posting a new item would not have to worry about security as much.

Am not sure what to do when user is member of multiple groups... maybe she can select in a drop-down which is the one that wins, or maybe the admin determins that when creating the user?

Reccomendation: Inherit permissions. (particularly for wiki)
The default behavior for a new object should be to inherit permissions from the page it was created from (global if none). Particularly in a wiki, this would facilitate the use of "private areas" - key feature for tikiwiki as groupware so committees. groups, etc. can operate in privacy, if so desired. Whoever create the page should be able to disable this inheriting, but it should be on by default. Admins can then create private wiki spaces by customizing perms on one page (the group home page).

Should not show IP, source, history, etc. if the features are off.

Users have a link (list trackers) to tiki-list_trackers.php on tiki-view_tracker_item.php and tiki-view_tracker.php

However, if some of the trackers are restricted, users get an error message instead of getting the list of trackers to which they have access.

tiki-mobile.php should appear in the menu when activated

BUG: It is possible to surf blogs in mobile mode even when deactivated.

WYSIWYCA: tiki-list_articles.php?mode=mobile and link to articles in tiki-mobile.php should only show when it user can see articles. Make sure to check topic permissions too.

Using Structures to assemble Wiki pages into a book is a very powerful way to manage sets of pages in a holistic manner.

A common usage requirement however is to be able to restrict access to some selected pages within a Structure, which works fine from an access control point of view, BUT when the toc function is used ALL the pages will be listed within the Structure no matter what Category permissions the individual user has. This means that users have visibility of some pages that they cannot access - which may be very undesirable!! and conflicts with the WYSIWYCA principle.

It would be extremely useful to be able to filter the resultant list from the toc function, to just the pages/links that the individual user's categorisation permission allow them to see. In this way the categorised pages would not be visible at all in the same way as they are treated in many other functions e.g. List pages etc.

Still does this in 3.0b4

FIXED

On these two pages:
tiki-view_tracker_item.php
tiki-view_tracker.php

Reminder: a user could have permissions to view a specific tracker without having general tracker permission.

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

A previously reported bug with searching Freetags (#2235), where there was a WYSIWYCA problem has been fixed and this bug item is closed.

But there is still a small glitch when you search categorised content with the number of items 'count' when the listing of the items goes over several pages.

What happens is that the number of items that are 'found' is only decreased from the total by the number of items in the current page listing that cannot be viewed because of categorisation (ie WYSIWYCA).

For example if the listing per page is set to 25 items and there are 55 total items but 6 are excluded for WYSIWYCA reasons (4 excluded in the first 25, and 2 in the second 25) then the first listing page only shows 21 items and says there are 51 in total; the second page shows 23 items and says there are 53 in total and the 3rd page shows 5 items and says there are 55 in total.

So whilst WYSIWYCA integrity is correctly preserved, the number count varying every time you scroll through the pages is obviously very confusing.


Aug 15 - closed this item as its so old and may no longer be an issue

When using articles on a tiki 5 site, using a thenews.css-based theme style, we don't see the horizontal menu at the top bar.
On all the other tiki features, that menu is shown as expected.
You can reproduce that here:
http://intercanvis.net

versus


http://intercanvis.net/articles

Ref. email to Security Team.

When I click a user, I am offered to send him a message. But then I get:

User XYZ can not receive messages
ERROR: No valid users to send the message

1: WYSIWYCA: I should not be offered to send a message if the user has disabled that. (frustrating to write such a message for nothing)

2: tiki-user_preferences.php: "Allow messages from other users" default should be yes

3: tiki-user_preferences.php: "Send me an email for messages with priority equal or greater than:" default should be "3"

tiki-admin.php?page=login
3- Users accept internal messages by default: default should be yes -> $allowmsg_by_default

4- Users can opt-out internal messages: default should be yes -> $allowmsg_is_optional


All these should be the default settings (most logical) if a Tiki site admin choose to activate inter user messages.

Related:
Easier Inter-user message management for Tiki admins:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=959

Also related:
Should sender email be disclosed when receiver gets notification via email? goals: balance privacy & facilitate communication/collaboration

Started in 3.0, needs to be used in tiki-admingroups.php and propagated to various places where permissions are set.


Also on wish list: A way to put more emphasis on more important permissions.

Either basic vs advanced or an ordinal column (top put more important stuff at the top)

So for a wiki page, view, edit and history should be at the top or in basic while tiki_p_use_as_template and tiki_p_export_wiki should be in advanced

Wouldn't it be great if a wiki link (the standard [] syntax) would check whether the current user has rights to the page that it links to? THat way we could turn off the hyperlink if the user cannot open the page anyway...THat would add some processing overhead, but I am sure that would be manageable.

Don't know where to begin, though, I do not really understand the wiki processing in Tiki...

If I add a poll in a module, a registered user can see it even though he can't vote.

It is currently possible to see links to tracker items we are not supposed to see. (clicking gives error message)

Contributors