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

{syntax type="tiki" editor="plain"}
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

This tracker item could not be found

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

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.

To be reproduced, see:
http://xavi-9794-5464.show.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345

And see the same page as user:
u: user1
p: user1
which has been granted local permission to view and edit that page, and global permission to edit structures. If you attempt to go to edit the structure,
http://xavi-9794-5464.show.tikiwiki.org/tiki-edit_structure.php?page=D1+Cover&page_ref_id=1

you get:
{QUOTE()}
Error: You do not have permission to use this feature: tiki_p_view
{QUOTE}

Potential Workaround:
Comment out the check for the permission to display any part of the edit strcutures interface. Line 22 from tiki-edit_structure.php should become:
{CODE()}
//$access->check_permission('tiki_p_view');
{CODE}

And line 123 from templates/tiki-edit_structure.tpl should change from:
{CODE()}
{if $editable == 'y'}
{CODE}
to
{CODE()}
{if $editable == 'y' && $tiki_p_edit == 'y'}
{CODE}

Should that be enough?

I couldn't test properly due to the interference of this other bug which prevents assigning object permissions:
https://dev.tiki.org/item5916

{syntax type="tiki" editor="plain"}
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.

{syntax type="tiki" editor="plain"}
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).

For some reason, permissions related to structures are not shown any more, even if you are in the homepage of a structure attempting to set permissions for the whole structure tree, etc. Global permissions show them, but this section is not shown when you are in an object such as the homepage of a structure

That worked in 12.x while showing the permissions under the wiki section.
In theory Tiki 15.x comes with a section of permissions of its own for structures, but for some reason, they are not shown, not even selecting all features (including wiki structures and the hidden featuers) to be shown.

To be reproduced, see:
http://xavi-9794-5464.show.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345
----
Issue still there! {sign user="xavi" datetime="2016-09-26T21:55:41+00:00"}

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