Loading...
 

Category: Permission

Permission
Show subcategories objects

Name Type
_categorized-Permissions cannot be assigned when upgrading from 1.9 to 1.10 - cache problem
After upgrading from 1.9 to 1.10 the permissions

"tiki_p_view_categorized" and "tiki_p_edit_categorized"

on the page

tiki-categpermissions.php?categId=

will not appear in the dropdown just below "Assign permissions".

Consequently, it is not possible to assign this permissions,

This problem disappears after emptying ./temp/cache/ directory.
tracker item
"Allow others to post to this blog" should be possible to omit as an option when creating blogs
I use TikiWiki as a platform for teaching at the college level, and one of the main things I do is require that students create and maintain their own blogs -- each student has one blog and should post only to that blog. My suggestion is that although I understand why there's an initial option to "allow others to post to this blog" in the blog create dialogue box, it would be a good idea to leave this option's availability and visibility up to the administrator -- in my situation, this option, if accidentally checked by students, creates confusion at posting time. I don't want students to see this come up as an option when they create their personal blog.
tracker item
(calendar) permission display wonky
Permissions are displayed incorrectly on the
"Assign Permissions to this Object" page of
tiki-objectpermissions.php for a Calendar (other object types not tested)

If there is more than one group assigned then the boxes show the correct permissions

If there is only one group assigned no permissions show

If a 2nd or subs group is added then the boxes show the correct permissions


tracker item
1-click access to be able to do certain actions (view a page, edit a page, edit user tracker, etc)
Sometimes, we want people to participate to one wiki page, to access their user tracker to update personal information or access a ((workspace))

Right now, we need to

#create a user
#create a group
#assign user to the group
#give permissions to group ( in general or for a specific item)
#inform this person, typically by email, on how to access this page


Instead, I would want to
#add an email
#pick the permissions this person has
#any limitations (works x times, or for x days/weeks)
#an optional message

And the system should send a 1-click login email (an email with a link in it which is unique / very difficult to guess).

Whoever clicks that link
*Would be authenticated with the appropriate permissions and according to the limitations.


Related:
Expiry date for group membership
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1071

Somewhat related:
Send welcome email (by admin to new user or user that has not connected in a while)
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1016
tracker item
1.10: possibly confusion in category vs. object permissions behavior
I wonder if this is a bug, or just some conflict of configuration, since the recent changes on category permissions.

This site: http://uniwiki.sima.ourproject.org is using a 1.10 from december 2007 (after some recent changes whre introduced in categories: see [http://doc.tikiwiki.org/Tikiwiki+1.10] )

I realized right now that my students (registered users with a couple of extra persmissions) could edit the Tiki sheets on that site (exemple: http://uniwiki.sima.ourproject.org/sheet14 ; private site: Sylvie has an account as admin on that site, and also to login through ssh to the server, if needed to test on site)

However, registered users didn't have any special perm. related to sheets, but the gneral perm to see categorized objects was given to registered.
No local perms to that sheet (or most others), but even so, students could edit them.

I had to add local perms to each sheet to avoid letting them edit the sheets.
I thought that without the global perm to edit sheets assigned to registered, it would have been enough to protext those sheets. Maybe this is some conlfict with the new perms. "tiki_p_edit_categorized"?.
tracker item
Caldrac
Contributors
tracker item
Anonymous users can create page without permissions after broken sql page shown
An anonymous user without edit permissions can edit create a new page.

To Repeat:
1. Be logged into a user with no edit permisssions
2. Find a red ? link to an uncreated page.
3. Click the link
4. Note you don't have permission to edit/create the page.

5. Log out
6. Click the red ? link as Anonymous
7. Note you can edit the new page
8. Save the page - Note the error:

An error occured in a database query!

Context:
File tiki-editpage.php
Url tiki-editpage.php
Query:
insert into `tiki_user_watches`(`user`,`event`,`object`,`email`,`type`,`title`,`url`) values(?,?,?,?,?,?,?)
Values:
0 NULL
1 wiki_page_changed
2 LinkToLocPageFigs
3 NULL
4 wiki page
5 LinkToLocPageFigs
6 tiki-index.php?page=LinkToLocPageFigs
Message:
Column 'user' cannot be null
Built query was probably:
insert into `tiki_user_watches`(`user`,`event`,`object`,`email`,`type`,`title`,`url`) values(NULL,'wiki_page_changed','LinkToLocPageFigs',NULL,'wiki page','LinkToLocPageFigs','tiki-index.php?page=LinkToLocPageFigs')


9. Take note that though the error happened, the page was created.
tracker item
Users able to post to all blogs - confirming and extending previously reported bug by others
On clean installs (empty databases) of TW 1.10 and 1.9.11 (also tested and confirmed on the clean 1.9.11 install on opensourcecms.com).
After users (perms tiki_p_create_blogs and tiki_p_blog_post enabled)create a blog they can proceed to post to any other user's blog. More precisely, on the post blog page, a user can select all blogs from the "Blog" field
tracker item
jonnybradley
Contributors
tracker item
Modules use should be restrictable with standard permissions
So I could show quick_edit module to users with tiki_p_edit

Related:
[wish1783|Menu & modules contextual to category of currently show item (wiki page, article, tracker, etc)]
tracker item
group category permissions
for example:
5 users in group home
6 pages in category home

I want all public can view these 6 pages in home category, but only these 5 users can edit pages content ( not the objects in the category, it is the content of the page!! ).
I know I can setup the permissions page by page to the home group, but what I am looking for is category to group relationship, not page to group, don't want to do it page by page, or maybe there is one way to do that, but I don't know yet.

Thank you very much.

Have a good day.

Best,
Peter
tracker item
3.x: tiki-assignpermission.php fails when not filtered & default suhosin patch for apache in server
From irc channel, today.
Summary (full log below):

tiki-assignpermission.php in tiki 3.x seems to send the whole bunch of permissions for a group in the POST variable to the server, even if you just assign 1 new perm. And the suhosin patch for apache seems to restrict the size of the POST, so that it gets truncated at some point, before reaching the new permission/s to be assigned

that was for group "admin", which includes (inherits) many many perms from the lower level groups

workaround: filter first for a section (wiki, in my case), so that the list of perms is reduced to a smaller number. Assign the perms related to plugins, and then it works with no problem
Moreover, there seemed to be a problem with mod security (with the standard rules coming to Debian based servers), which was causing error 403 with that tiki-assignpermission.php .... once the sys admin disabled modsecurity for our site, tiki-assignpermissions.php worked as expected with the workaround described above


{CODE(wrap=>1)}
wtf*, there is something weird with tiki-assignpermission.php in tiki 3.3...
... I try to grant the 3 perms related to plugins to the group "Admins" (they have tiki_p_admin also already), and I get: You don't have permission to access /tiki-assignpermission.php on this server. (with a scary apache white page)
I mean a 403 Forbidden page from apache
to me that there is something wrong in the LTS for assigning permissions... [11:31]
xavi aha, after conversation with sys admin in that server, I got the source of the problem, and workaround :-)
tiki-assignpermission.php in tiki 3.x seems to send the whole bunch of permissions for a group in the POST variable to the server, even if you just assign 1 new perm. And the suhosin patch for apache seems to restrict the size of the POST, so that it gets truncated at some point, before reaching the new permission/s to be assigned [12:02]
xavi that was for group "admin", which includes (inherits) many many perms from the lower level groups
ok, workaround: filter first for a section (wiki, in my case), so that the list of perms is reduced to a smaller number. Assign the perms related to plugins, and then it works with no problem
Moreover, there seemed to be a problem with mod security (with the standard rules coming to Debian based servers), which was causing error 403 with that tiki-assignpermission.php .... once the sys admin disabled modsecurity for our site, tiki-assignpermissions.php worked as expected with the workaround described above [12:02]
marclaporte will you report the bug to suhosin? [12:09]
xavi hi marclaporte, it might very well be not a bug, but a conflict between the size of the post that tiki sends, and the size of the variable allowed by default values by suhosin in apache, which (as far as I've been told) it's customizable.... [12:12]
marclaporte ok [12:12]
xavi so the chances that they will not consider it a bug are high (maybe similar for tiki, which wouldn't be considered a bug, but some "bad luck" of using such a long default list of perms) [12:13]
marclaporte so nobody's "fault" but it's doesn't work [12:15]
xavi btw, thanks for message introducing to the author of jquery spreadsheet...
"it doesn't work": well, it does, if you filter the long list of perms for a section first
or if you moun your sys admin to find out how to increase that default size in suhosin [12:15]
{CODE}
tracker item
thess
Contributors
tracker item
Cyril
Contributors
tracker item
Can admin content templates without appropriate permissions
I have a group which does not have permissions to admin content templates in their category or the global permissions (the only permissions applying to the group) yet the group is still able to admin content templates.
tracker item
Filegal File Object permissions - does not exist.
Object permissions do not actually apply to individual files in a filegal. Despite this, we have UI to change said permissions. Trying to apply perms on a file affects the perms on the parent filegal. Very confusing and frustrating usability bug.
tracker item
When upgrading old version of TikiWiki to 7.2, admin login no longer has admin permissions
Hello, former library employee now library volunteer who is helping a library update its tikiwiki 3.x intranet to 7.2 and encountered a strange bug that I am stuck on.

Upgrade seemed to go smooth, with a fresh directory install and pointed to the SQLi backend of the 3.x install in a test environment.

When I went to login with the known local admin account within tikiwiki, it allowed me to login but i could not access any of the admin modules without getting a lack of permissions error. Somehow the admin account is not associated with the admin group, although works fine in the 3.x live install.

Issue is compounded then that I cannot add admin to the admin group, because I cannot get access to the admin modules to do this!

I tried to do my own research on this, and actually did see some IRC logs where someone else had a very similiar issue although I did not see a resolution.

Any ideas how to fix this? Can someone give me some guidance into the tikiwiki sql structure whereby I might be able to change this within the table itself?
tracker item
Add "tiki_p_admin_structures" permission
Can anybody explain me, why there is no permission tiki_p_admin_structures? Users with tiki_p_edit_structures can do everything they want with my structures. But I only want them to add new pages.

Every other feature of TW has two main perms: tiki_p_admin_xyz and tiki_p_edit_xyz. But structures only have tiki_p_edit_structures, which allows users with this right to even delete the structure of our corporate wiki.

Please add this perm! Maybe even for TW 3.0? Thanks in advance.
tracker item
Add green & yellow permission keys on tiki-listpages.php
It will be very useful when TikiWiki is used as a combined portal & Intranet


The key (and link to permissions) is already on tiki-listpages.php (great!)

Now, a green key could indicate this page has special permissions.

And maybe even a third key (say blue) indicates that the item is inheriting permissions via the category.
tracker item
Add group permissions for individual polls
You cant set it that individual polls can be set to viewed by only certain groups.
tracker item
Adding a page to a category breaks permissions
when a wiki-page is added to a category, it's is no longer viewed to anonymous users. (Login screen appears) By removing the page from the category it appears again.
tracker item
Admin – Assign Permissions – ordering table by level does not order correctly (level conf. active)
Assign Permissions with Level Configuration,
thus drop-downs in the table
tiki-assignpermission.php?group=Admins&advanced_features=y
ordering by level does not order correctly.
tracker item
Admin option to force newly created pages to be part of the structure they were created from
Guys, I have to set up a company wiki, which is completely structured from top to bottom. So I noticed a very annoying thing about tiki.

Currently if you want to create a page, that is destined to be part of a structure, you have to create it using the navigation bar and set the option "as child".

But what if a user creates a new page from within a structred wiki page? I.E. If he simply sets up a new link to an non existing site. The new page is created as an orphan which is definitely a "no go" for a completely structured wiki. Pages like this have to be manually assigned to a structure by the admin.

So I request an option, that __forces pages created from within a page in a structure to be automatically part of the same structure__.

I guess even in pages like doc.tw.org this would be very helpful.
tracker item
admin user doesn't have permission to edit structures by default
After a clean install of r15460 w/ a new database, using the default enabled profile, i enabled structures via the wiki admin area.

Even though I was admin, I coulden't create / edit structures until I gave myself permission in the privileges settings.

The admin user should probably have most permissions by default, unless there is a particular reason to exclude a permission.

tracker item
admin user doesn't have permission to edit structures by default
After a clean install of r15460 w/ a new database, using the default enabled profile, i enabled structures via the wiki admin area.

Even though I was admin, I coulden't create / edit structures until I gave myself permission in the privileges settings.

The admin user should probably have most permissions by default, unless there is a particular reason to exclude a permission.

tracker item
admin user loses admin rights after creating a user
tracker item
All upgrade from 3.x to 4.x denies all permissions to admin
Hello,

Relating to id2936 id2950 and another id lost (mine but when the author was not set always into track id data's.

It remains impossible to an admin to changed quite anything depending of admin (can create wiki, articles) but not to end any admin task.

The action as, change a user prefs etc, disconnect admin and send the ERROR Connect page __access not allowed__ so the corresponding sites are dead sites.

An installation of 3.3 or upgrade to 3.6 must be done again from database backup.

The problem is that if users has been connected between the upgrade and the necessity for admin to make some changes (I have made...) I had to manually add articles and wiki pages from sql.

We must admit that upgrade from 3.x to 3.x is impossible in some cases unknown, not yet found

I test today if an upgrade 4.2->4.3 had an effect but none.

trebly
tracker item
Allow admin of Preference Screen options by Administrator
In 3.2, one can create a personal page in MyTiki and use an Avatar (I see from the Community it wasn't always available & I appreciate the feature), but I would like an Administrative feature that could turn these off while still allowing users to access their Preference Screen, especially for changing their password and email address.

User pages and avatars could take up a great deal of space if there are a lot of users. I'd like to turn off the ability of users to have user-pages and avatars. If there's a way to do that now, please let me know, because I've looked everywhere for a way to do that (and there's a note not to edit templates unless you really know what you're doing and I somewhat know, but I'm afraid of creating a problem).
tracker item
Allow users to view RSS module list and add modules without other admin permissions
Access to RSS modules (incoming feeds) is an all-or-nothing option in v2.0, with just one admin permission available. A beneficial feature for our Tiki would be to enable users to view the RSS module list and add new modules, without having other permissions, such as deleting modules.
tracker item
Assign permissions on individual FAQs
One cannot assign permissions on individual FAQs. This prevents from creating FAQ for different level of users.
tracker item
assign_all in tiki-categpermissions.php does not assign to more than one level of children
While updating from 1.9.11 to 2.1, we ran into a bug in tiki-categpermissions.php.

We have a category structure with multiple levels of categories, and assigning to children seemed not to work as intended.

I had a look at the code, and it seems like it only assigns to one level of children, and never checks for more levels of children. I rewrote the code quickly to solve our problem, and attaches the patch I used.

I don't know if this breaks all code guidelines in tw, but it works ;)
tracker item
Better/Easier reporting of item/object permissions which override category and group permissions
It would be useful to extract all permissions of File Galleries or Wiki pages or Forums, etc

This would provide a way for admins to know who actually has access to what.
tracker item
blackroom /tiki-assignpermission.php?group=* rendering problem
Dear community,

Here's a screenshot:
{img src=show_image.php?id=70}
Many blessings.
tracker item
blog doesn't respect feature_tell_a_friend=n
Setting feature_tell_a_friend=n doesn't affect the "Email This Post" functionality for the blog, so visitors is always offered to mail the link for a post. Imho the admin should be able to choose if this is allowed or not.
tracker item
Blog local perms are not deleted if group name contains spaces or special characters
You create a blog, Assing local perms to a group which name contains an space (or special characters such as é, è, ñ, ç, ...). Then when you attempt to delete the local permission, you don't succed. The url is something like:

http://domain/tiki-objectpermissions.php?referer=http%3A%2F%2Fdomain%2Ftiki-edit_blog.php%3FblogId%3D5&action=remove&objectName=BlogNAME

And it produces the error message saying somerthing lie "there is not enough information to show this page".
tracker item
Bugs need permission to be viewed
Even though logged in, clicking on http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2538&trackerId=5&show=view (which came up as a result of a bug search) results in the user being told "Error - Permission denied"

This should probably not be possible.
tracker item
Can't add permissions in 3.2 - carried over from 3.1 + 3.2 upload errors
As the admin I can't add permissions to Registered users or a new user group. In 3.1, I was getting errors when logged in as Registered user that I couldn't upload even though that was available to me (there's an open bug report about this). I don't get that error now and I can upload as a Registered user, but I cannot then go back and see it - no Galleries are visible to me. I can see them as an admin, though, but that is not useful since users need to view galleries also and aren't able to.

Also, I got these errors when I upgraded to 3.2:

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1091

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177

Warning: in_array() [function.in-array]: Wrong datatype for second argument in /tmp/cpanel_phpengine.1254931905.289840z3jsIGfOH on line 1177
tracker item
Categories does not restrict visibility on individual images
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.
tracker item
Categorisation permission issue with Calendars and Trackers
This may be a more general Categorisation issue, but with the Calendar function if a Group is given just view permissions for calendars and calendar events, and an individual calendar is categorised where the Category is defined with this same Group given "view categories" and "view categorised" - then the Group can then add new events and change existing events even though they do not have these base permissions.

This behaviour is similar to that seen with Trackers and posted to the Features/Usability Forum [http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=31343&topics_offset=184&topics_sort_mode=lastPost_desc&forumId=4|here] where a Categorisation overrides a base permission level.

This problem can be avoided by not using Categorisation and instead setting detailed Permissions for the individual Calendar but this is obviously more complex and makes it difficult to impose a systematic security policy across the whole site.

This bug has been tagged against Security since other users may not realise this issue exists and their site security policies may be broken and not realised.

Very old bug now fixed with improved categorisation

tracker item
Category not overriding global permissions
tracker item
Category objects not listed unless user has 'tiki_p_admin_categories' permissions
Category objects not listed unless user has 'tiki_p_admin_categories' permissions when viewing in 'tiki-browse_categories.php.'

If a user has rights to view pages in a category, they should be able to see a complete list of objects within that category. You should not have to give them admin rights in order to see the objects.
tracker item
Category Permissions not taken care properly for showing wiki pages
Please help since we have invested much time and effort in this project, believing Tiki could filter rightly wiki pages based on perms, and since I cannot find a workaround.

When not logged in, Some wiki pages are shown, and Some others Not, while they all have exactly the same set up. They all have been categorized only in "Public Content" category which is set to Show wikis to Anonymous users, while Global perms are set to not show them to anonymous.

At this moment we have two identical wiki pages as setup is concerned:
1) http://mi.solcentral.org/tiki-index.php?page=La+Funci%C3%B3n+Esencial+y+El+Prop%C3%B3sito+de+Vida
which doesn´t show to Anonymous users (and should do it)

and

2) http://mi.solcentral.org/tiki-index.php?page=Sobre+el+Sitio+SolCentral-org
which shows well.
Note that at the botton of this page, in the listing of pages related to the category "Contenido Público" (which is the translation of "Public content"), the page "The Esential Function And Life's Purpose" (wich is the translation of "La Función Esencial y El Propósito de Vida") that is the page 1)... Then if you click on it, it will not show presenting you with the login invitation, allthough is shown in the list as categorized "Public Content".

Other extraneous behavior is that when when you use the Plugin Toc to show the structure, only shows Some wikis on some structures, and on some other structures doesn´t show any wiki.
I have used this:~np~{toc structId="26" order=asc shownum=1 type=fancy }~/np~ in the wiki:
http://mi.solcentral.org/tiki-index.php?page=e-Books%20Index

Actual estate of config is:

For anonymous:

If Perms on wiki: "La Función Esencial y El Propósito de Vida"

La Función Esencial y El Propósito de Vida Anonymous tiki_p_view Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_view_backlink Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_watch_structure Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_wiki_view_attachments Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_wiki_view_comments Categoría: Public Content

Category Perms of "Public Content" are

for anonymous group perms that are ON:

Can view wiki attachments and download (tiki_p_wiki_view_attachments)
Can view page/pages (tiki_p_view)
View page backlinks (tiki_p_view_backlink)

Global Perms are:

on Wiki:

Can view wiki attachments and download (tiki_p_wiki_view_attachments) is ON for Anonymous
Can view page/pages (tiki_p_view) is OFF for Anonymous
View page backlinks (tiki_p_view_backlink) is ON for Anonymous


Fixes tried:

Have tried the opposite: allowing everything to be shown to Anonymous, and then restrict on pages that should be hidden with a "invisible" category with perms tiki_p_view OFF for anonymous group.

And it didn´t work since - again - for Some wikis worked, and for some others not. Even if they are identical.


Using:
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.
tracker item
Category plugin lists objects even without perms
The CATEGORY{} plugin does not check for perms when listing objects, so objects where user has no perms are displayed anyway.

If you click these links you get an error because the pages themselves are protected. However, you should not be able to see the list.
tracker item
category: lost admin rights
My application use category on groups and objects
I tried category transition in tiki4, to be honest without reading anything, the result is catastrophic: I cannot admin all my tiki because i have lost my rights as administrator.
In my SQL database all records in users_grouppermissions table have been deleted
How can I retrieve my rights?
Can I manually write admin rights in my database?
thanks
tracker item
cnd
Contributors
tracker item
Creator can edit option selected in article type not filtered on for edit permission.
Creator can edit option selected in article type not filtered on for edit permission in edit_article and edit_submission. Author's submissions once validated cannot be edited by their authors.
tracker item
database error
An error occured in a database query!

Context:
File tiki-objectpermissions.php
Url tiki-objectpermissions.php
Query:
insert into `users_objectpermissions`(`groupName`, `objectId`, `objectType`, `permName`) values(?, ?, ?, ?)
Values:
0 Registered
1 23bfc265681dcc129a658e8a8552cccff26613d0
2 wiki page
3 tiki_p_view
Message:
Built query was probably:
insert into `users_objectpermissions`(`groupName`, `objectId`, `objectType`, `permName`) values('Registered', '23bfc265681dcc129a658e8a8552cccff26613d0', 'wiki page', 'tiki_p_view')

when trying to assign tiki_p_view to registered group under Perms button.
tracker item
Deprecated notices re xajax when assigning perms
I get several notices like this:

Deprecated: Assigning the return value of new by reference is deprecated in ...\branches\5.x\lib\ajax\xajax\xajax_core\xajaxAIO.inc.php on line 428

when opening the group permissions page (approximately r27704). This is on Windows with PHP 5.3.1.

tracker item
display bug on objectpermissions page
__Steps to reproduce:__
# as an admin on a wiki page follow the __Perms__ link
# go to "Select Groups" → tick "Anonymous" only and [[Select]
# on "Assign Permissions" tick for example the first one: "Can use the page as a tracker template (''tiki_p_use_as_template'')" and [[Assign]

it will save, reload the page but the previously ticked checkbox doesn't display as ticked anymore
tracker item
Do not display [comment] link, when no perm to post comments and no comments posted yet
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...
tracker item
editing category permissions fails for group-names with "~" as namespace separator generated by workspaces
tracker item
Error in permissions of the file galleries and other objects
When I try to set permissions for galleries or other objects manually, I get an error.

See [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=10&topics_sort_mode=lastPost_desc&forumId=4&comments_parentId=22138|Forum Link] for an other post and a screenshot of the error.

tracker item
Errors on top of tiki-objectpermissions.php page
Forum last posts module gives the following Notice errors on top of tiki-objectpermissions.php page and messes up the font size of permissions list.

Notice: Undefined index: forumId in ../proposed/5.x/lib/core/lib/Perms.php on line 185

Notice: Undefined index: forumId in ../proposed/5.x/lib/core/lib/Perms.php on line 229

For every topic created you will get another 2 of those Notices.
When there are 100 forum topics not that hard to get you will need to scroll down 200 lines of notices just to edit a few permissions.

Reproduce:
Turn on feature forum
Asign forum last posts module
Create a forum and a topic


One of the notices i got is fixed in Revision 29138
Notice: Use of undefined constant ttz - assumed 'ttz' in ../proposed/5.x/lib/tikilib.php on line 7682
tracker item
Exclude certain content from search results
This could also be by via category system (with perms)
tracker item
File Galleries not visible to groups without permission "tiki_p_admin_file_galleries"
Users in groups without the "tiki_p_admin_file_galleries" group permission set cannot see any file galleries in the "List Galleries" page, even if "tiki_p_list_file_galleries" (or all file gallery permissions) are switched on for the group and/or the File Gallery.

However, the user can still access the gallery directly if they know the exact URL, eg:
http://site.com/wiki/tiki-list_file_gallery.php?galleryId=2

The "List Galleries" page loads, but the list of galleries shows only "No records found". If "tiki_p_admin_file_galleries" is enabled, all permitted galleries appear in the list.

tracker item
File Galleries visible to groups without permission
A user can choose the "Upload File" tab in a file gallery, which displays a page with a drop-down list of galleries. This drop-down lists galleries that the user does not have permission to view.
tracker item
Forbidden content in comments shows up in search results
tracker item
forum moderator seems to have tiki_p_admin_forum permission=y for tiki-view_forum.php
although they have tiki_p_admin_forum permission=__n__ (on v3.2).
My forum mods gets on tiki-view_forum.php?forumId=<int> the "Edit forum" button, which should be visible to forum admin only.
If they click on the button they get the error messages about missing permissions, so there is no serious problem with it, but it's confusing to see this button.

I've looked over templates/tiki-view_forum.tpl but didn't see anything as explanation for this.
(Btw: the if/else clause from line 15 to 19 doesn't make a sense (for me); it makes the same, never mind the case of the if-clause)
tracker item
Forums lists many pages, regardless of categ.perms., and available forums are not listed in 1st pag
Imagine you have 20 forums (>10 is common case in some educational scenarios).

Forums list indicates 2 pages of forums list.
Then you select the 15 first forums to a categ. with restrictive permissions, so that normal users don't have the perm. to see them. The last 5 are supposed to be seen by users.
The first 15 are in a section called "Salut i Medi Ambient" (without quotes), and the last 5 are in a section called "Salut i Medi Ambient 2005-06"
Those last 5 are not listed in the first page of the forum list, which appears to be empty, and the users see as if there were no forums (they are in the second page of the forums list).

This should be modified so that the available forums to a user are listed in the first page of forums list.

Using 1.10cvs.

tracker item
General: Use library functions for permissions and features
I would suggest the creation of two simple tikilib functions: have_permission() and feature_enabled(). These functions need to take the name of a Tiki permission or feature respectively, and should return a boolean if the permission is set, or feature enabled.

These two functions are obviously pretty simple to implement. After their introduction, all Tiki applications should be migrated to use them (a job I would suggest may take until 1.11 or later!).

The benefits of doing this include:

* Less programatic reliance on global variables
* No need to read entire permissions or feature database tables to return each page
* Lower in-memory information required to run the application
* Allows for finer grained permissions and feature control without affecting scalability
* Permissions and features can subsequently be replaced by more sophisticated, scalable, usable or effective solutions later without futher disruption to applications.

The last point is the key here: Whilst there are currently hundreds of permissions and features, there are lacking in places where they should exist. Clearly adding yet more permissions and features isn't really viable.

Also, having a replaceable solution means it would be possible to move to an "entitlements" based solution without breaking the entire system. Entitlements may offer a way to provide extreme customisation abilities, with scalable and flexible permissioning, control of features etc.

The subject of permissions and feature control is obviously broad. This RFE only aims to facilitate the future discussion and adoption of a more generic model for control of the application.
tracker item
Group inheritance of permissions broken
The inheritance of permissions between groups seems to be completely broken in trunk (r33152).

For example, when Registered includes the permissions of Anonymous, granting tiki_p_admin_wiki to Anonymous should allow Registered to admin wiki pages, but that doesn't work. The same thing happens with tiki_p_view and tiki_p_read_comments.

This was discussed in thread http://thread.gmane.org/gmane.comp.cms.tiki.devel/20101

This is a regression from r32118.
tracker item
Group Permission Negation Patch
The following patch adds negated group support to TikiWiki. Using this patch, you can choose to hide modules from users that ''are'' in a given group, by simply specifying the group name as !Group.

The patch is in production use on the [http://www.asperger.asn.au|Asperger Services Australia] website. I'll see if I can come up with some screenshots shortly.
tracker item
How to force the login process
Hi there,
I would like to know if it is possible to force the tikiwiki login process.

I want the login page for the home page, in order to force the users to log in. I have to modify the tiki-index page ?Do you guys have any hint for doing that?

Any help will be much apreciated.
Luca
tracker item
improve doc for tiki devs about the right way to develop permission checks (global, category and local)
tracker item
Incorrect permission verification in tiki-upload_file.php
User is unable to upload file even if the permission tiki_p_upload_files is assign to his group on the file gallery. User gets "Permission denied" when clicking the "Upload file" in the gallery.

tiki-upload_file.php (at line [http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/branches/3.0/tiki-upload_file.php?view=markup#l_160|160]) wrongly assumes request parameter "galleryId" to be an array with a single element when checking for permission. However, it can a string.

For example if a user call ...upload_file.php?galleryId=30, the permission for gallery with id 3 will be considered.
tracker item
Inheritance of filegal permissions for sub-galleries
Sub galleries should, at least optionally, inherit the permissions of their parent (can be overridden of course).

The problem we have here is that if you have a directory for a Project of some sort, and someone creates a subproject gallery, that subgallery is world-viewable, instead of inheriting the Project permissions.

It seems more logical to me to have new children automatically have the permissions of the parentId unless specifically changed.

tracker item
It should be possible to hide the "More" button (especially if it is "empty")
tracker item
tiki_p_remove_files permission not working in file gallery.
===My Setup===
I have file galleries set up with categories, so each category grants permission for a specific group to view and edit file galleries which are categorized to that group. E.g., I have a "group 1" category which grants the group "group 1" permission to access the "group 1" file gallery.

I have a "group administrator" group which has the "tiki_p_remove_files" permission granted in each category. This gives me one group which I can add to a user to give them permission to remove files from whichever file gallery they have permission to view.

Technically, the group admins have permission to remove files from all sections, every category grants them this permission, but because they cannot see the other sections, this is not an issue.

===My Problem===
Even having the "tiki_p_remove_files" permission, group admins are unable to remove files which they did not upload.

I have "tiki_p_remove_files" set for the "group administrator" group in global permissions but the issue still remains.

To do some testing, I granted registered (thus all groups) "tiki_p_remove_files" in the global permissions, and in the category permissions, but section admins (and normal users) were still only able to delete their own uploaded files.

I have a sym link set to my old tiki version, so I can access it via tiki-url/old. I used to this to determine that this is an existing bug, and not a regression. When adding the "/old" to my url, and going back to Tiki6, group admins were still unable to remove these files. The perms are stored in the db, so this would be a valid way to determine this correct?

This makes me think that the bug has been around for a while, as it was present in Tiki6 as well.

I cleared the tiki cache before each testing of permissions, and also cleared my browser cache (just to be sure) multiple times while testing this as well.

It makes it difficult to assign a single user to be a file gallery manager if I cannot give that user the ability to delete other user's files.
tracker item
LDAP Group Synchronisation broken
With revision 31581 the LDAP group synchronisation has been limited to only happen 60 seconds after the login:

http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/trunk/lib/userslib.php?r1=31565&r2=31581&pathrev=31581

So far as I can see this method is only called during the LDAP login procedure, so the if-statement in line 1415 will always be false, thus no synchronisation will happen.

I checked this problem with 7.1, 7.2 and 8.3 and never succeded to get the groups from an AD although the LDAP login worked. After disseminating the code and removing this if-statement the feature works again.

I wonder what the the use of this if-statement was? The commit message refers to webdav changes - how does it affect this?
Can this statement be removed so LDAP group synchronisation works or is there another way to fix this?
tracker item
MEbneter
Contributors
tracker item
notgroups param for modules
Sometimes, you want to show a module just for Registered, but not Admins. So a notgroups param would be nice.

This idea is from Bernard Sfez on the Dev mailing list.
tracker item
Quick Edit (both module & from List Pages) bypasses category permissions when improper case used.
Typing a page into Quick Edit, either in the Quick Edit module (I know it is depreciated but was testing this as well) or from the Create a Wiki Page tab on the List Wiki Pages seems to bypass category permissions and allows editing of pages which should be locked for the user. This happens if the page which is entered does not EXACTLY match the case of the existing page.
For example, in Global Permissions, Registered Users have Edit permissions; a category Alpha has Edit permissions assigned only to group Alpha, Registered Users have no edit permissions on this category. A page called Alpha exists in category Alpha. If a Registered User who is not part of group Alpha tries to create/edit page "Alpha", they receive the proper error about not having permissions to edit the page. Should that same user try to create/edit page "ALPHA", "alpha" or any variation which does not match exactly "Alpha", they will be allowed to edit the existing page "Alpha". This will also work if they enter the URL to edit the page directly with a different case (i.e. "tiki-editpage.php?page=Alpha" will prevent editing whereas "tiki-editpage.php?page=ALPHA" will allow editing).
tracker item
Admin unable to use some File Gallery functions, such as "Create File Gallery" due to conflict with (tiki_p_admin) permission.
I am a new user to tikiwiki and have had a problem using File Gallery on two fresh separate installations of tikiwiki 8.4, and 9.0.

I only had one user set up which was the default admin user, and found that I was unable to use the "Create a File Gallery" function was also unable to "Edit" any file galleries that existed. When I tried either of these functions it would take me to a page that said

Error
You are not logged in. Go to Log in Page

even though I was logged in, if I clicked on "Go to Log in Page" it would take me there and show

Log in
Logged in as: admin

I turned on php error reporting and these are the errors I receive after clicking on save in create a file gallery function.

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/setup/user_prefs.php
Line: 12
Type: Undefined variable: user

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/setup/user_prefs.php
Line: 14
Type: Undefined variable: user

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/setup/user_prefs.php
Line: 15
Type: Undefined variable: user

PHP (5.2.17) NOTICE (E_NOTICE):
File: lib/init/smarty.php
Line: 176
Type: ob_end_clean() [ref.outcontrol]: failed to delete buffer. No buffer to delete.

I do know small amounts of PHP scripting, html coding, and the like, and dove into some of the script, but I do not know where the user variable is supposed to be created to be passed from page to page, or if the cookie is somehow not being verified when trying to pass information from one page to the next.

I also went on tiki's forums and saw that a few others have posted similar experiences, but no working answers were supplied for me.
tracker item
Permission on Newsletters using Group Permissions
Hi,

as written to the dev list, I had the problem to restrict access to some newsletters but not to all. I found a solution, but I am not sure, if this breaks nothing else. Here is the problem:

I want to set up some newsletters: One with access from anybody (anonymous users can subscribe and view the archive) and some others with access only for special groups of users.

On global permission page I set 'tiki_p_list_newsletters' and 'tiki_p_subscribe_email' for anonymous users (this permissions are not available on the object permission page).

On the object permission page for the single newsletter (accessible through /tiki-admin_newsletters.php and the key icon of every newsletter) I activate 'tiki_p_subscribe_newsletters' and 'tiki_p_view_newsletter' for the group of users with permissions on this newsletter.

With this settings I would expect, that an anonymous user browsing page tiki-newsletters.php would see the list of newsletters, in this case showing only the public newsletter. But in this case there is an error (You are not logged in). As a privileged user (allowed to see all newsletters) the page is accessible but empty, not showing any newsletter.
tracker item
Item Link in Tracker Does Not Obey User Permissions
PROBLEM (summary):
A Item Link field appears to be missing a condition to limit the list of items in the dropdown on a tracker form to those that the user has permission to see.

Details:
(Reproduced on demo.tiki.org site. See details below)

Imagine you are using the Tracker functionality NOT for user registration but for allowing users to create a home inventory.

You have 3 trackers created:

*1 a tracker of Location that has fields "Friendly Name" - Text Field, "Relation to Another Location" - Item Link to "Friendly Name" items in Location, and "Specific Location" - Text Area (Note: DO NOT give "Relation to Another Location" Item Link the ability to Add Item..., or you will zap all the memory of your Tikiwiki! )
*2 a tracker of Items that has fields "Friendly Name" - Text Field, "Location of Item" - Item Link to "Friendly Name" items in Location tracker, "Value" - Text Field
*3 a tracker of Inventory that has fields "Item" - Item Link to "Friendly Name" in Items (with an "Add Item..." option) and "Photo" - File

All 3 trackers have a mandatory User field with auto-assign to creator

Registered Users have ONLY the following tracker permissions:
tiki_p_attach_trackers
tiki_p_tracker_view_attachments
tiki_p_comment_tracker_items
tiki_p_tracker_view_comments
tiki_p_create_tracker_items
tiki_p_modify_tracker_items
tiki_p_remove_tracker_items permissions

Data input is carried out via wiki pages with tracker/trackerlist

ALMOST everything is working - 2 users (TEST1 and TEST2) can input data and neither can see the other's inventory. - That's Good.

The PROBLEM is:
The Item Link drop-down shows ALL the items of the tracker from both users.
In other words, when TEST1 is selecting a Item from the Tracker List, TEST2's items show up.

Fortunately, if the Item List is rendered as a link in the trackerlist, TEST1 will get an error when trying to click on TEST2s stuff (presumably, to see the Value field to come over to his house and steal his stuff ;) )

But, the problem is that, with a lot of users, the dropdown list becomes unusably long.

Reproduction on the 10X Demo site:
Log in as TEST1 or TEST2
Password 12345
Go to the Home Inventory Form wiki page
Test1 has: Television in Office in Test1s Home
Test2 has a vase in bedroom of Test2s home
Admin has a Linux computer in the living room ;)

Now, if you go in as, say, Test1, on the Home Investory Form page you will only see Test1s stuff, but in the dropdown box of locations, you'll see Test2's bedroom, Test2s home and Admin's living room.

I had to change (limit) Registered group's access as describe above in the details.
Sorry to anyone out there using it!
tracker item
Unable to set Object level permissions to articles in 10.2
Was using Tiki 6.x, backed up databases, did a fresh install of version 9, then upgraded to version 10.2, moved article database back. When I create an new article, then tried to assign object level permissions. {img fileId="197"}

The assign permissions area needs a feature selected (see {img fileId="196"}. When I go to Select Features, none of the installed features show up. However I can check the box for "Show permissions for disabled features" the missing ones show up but still can't set the article permissions.

Not sure what the issue can be, I verified that Administrators have all the proper access. I can set global permission for the same "missing" features. Not sure what to do at this point.
tracker item
Admin Setting
Features Classification
tracker item
Item/Object perms: copy permissions from another object. (especially for wiki pages and categories)
Tiki perms are very fined-grained: great

But when you need to create a lot of items with individual perms, it can be time consuming and human-error prone.

So copying perms from another page (which we know is OK) will be very helpful.

It will also save tons of time since permissions are not inherited.


__Related__
{WISH(id="2133")}{WISH}
{WISH(id="1820")}{WISH}
{WISH(id="2586")}{WISH}
tracker item
koth
Contributors
tracker item
Labels on permissions on tiki-objectpermissions.php are hard to see
tracker item
Limit number of tracker submissions
tracker item
Link from objectpermissions.php to doc help page has wrong URL / Alias issue
tracker item
Lock feature doesn't work you can always post on a locked thread
The lock feature for thread on the forum doesn't work.
Anybody allows to add a post can still do it on lock thread even if the user has only post authorization.
tracker item
Login with Facebook appears when Social Networks Disabled
tracker item
Permissions for most features can no longer be set
tracker item
LDAP password will not be accepted when using > or < in the password string
tracker item
#649
Contributors
tracker item
Mark blog entry as private doesn't work
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
tracker item
Mass assignment of permissions, especially for wiki pages
Permissions on individual wiki pages are great.

But what if you want to change the perms


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

tracker item
Menu for anonymous user to articles
I have been trying all weekend to get a menu item to be visible and active for an anonymous user.
The uri is elkstudy.com.
There are four items in the menu. Here is the .csv:
"optionId","type","name","url","position","section","perm","groupname","userlevel","remove"
203,"o","Home","tiki-index.php",2,"","","Anonymous",0,"n"
205,"s","About EMG","",3,"","","Anonymous",0,"n"
208,"o","Introduction","tiki-index.php?page=Introduction",4,"","","Anonymous",0,"n"
207,"o","Purpose","tiki-index.php?page=emgPurpose",5,"","","Anonymous",0,"n"
204,"s","FAQs","tiki-list_faqs.php",8,"feature_faqs","tiki_p_view_faqs, tiki_p_suggest_faq,tiki_p_view","Anonymous",0,"n"
206,"s","News","tiki-view_articles.php",10,"feature_articles","tiki_p_read_article, tiki_p_topic_read","Anonymous",0,"n"

I made FAQs work only by pointing to a Wiki page, which is OK.
But I cannot get the item to be visible either for anonymous or registered users (only admin) so that anyone can get to the articles section, which I want to be a news section.
I have looked into a theme problem (same issue with any of a dozen themes) I'm using a variant of absE.
I have tried plain menus {menu id=45} and the three variations on the PHPLayers (fixed, etc.)
I have tried a simple flat arrangement (all section0).
I have tried attaching a public category to all menu items.
I have spend this weekend chasing around for a solution but I haven't found one.
I would prefer to link to the FAQs module instead of building Wiki pages, but I couldn't get that to work either.
Thanks
db


tracker item
Menu management: add a permission: tiki_p_edit_menu
As of now, you need to full admin to edit the menus. Often, we would like to delegate this to somewhere at the editor level.
tracker item
Misleading error message when saving without passing captcha test
I just spent 30 minutes on a wild-goose chase because of this.

On this site:

www.wiki-translation.com

I was trying to set permissions on this page:

http://www.wiki-translation.com/AMTA+2010+Workshop+on+Collaborative+and+Crowdsourced+Translation&objectName=AMTA+2010+Workshop+on+Collaborative+and+Crowdsourced+Translation

so that anonymous users can edit it. I want this to be limited to just that one page. But it didn't seem to work. I was able to edit the page as anon, but when I saved, I would get the following message:

"You are not logged in. Go to Log in Page"


I assumed that it was a bug with the permission override.

But as it turns out, I just was forgetting to enter the Captcha code! But the message was so misleading that it took me 30 mins to figure that out.

In cases where the user forgets to enter the Captcha code, the system really should just prompt the user again for the Captcha (but not display any of the other fields in order not to confuse him).

tracker item
Missing Permissions assignment feature for Newsletters
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
tracker item
Move perm plugin from mods to BRANCH-1-9 and add a way to have not just "if" but "if/else"
Perm plugin is very useful and works well. It is very similar to the group plugin. It weighs just a few k and I see no advantage of putting in mods.
http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=perm

Similar to group plugin, we need "if/else" concept:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=994

So we could do things like this in wiki pages:
if tiki_p_edit "please click here to edit" else "please click here to login"

Also, group plugin is still in mods, but already in main code base so it should be cleaned out of mods.



tracker item
natokpe
tracker item
need "structure" permissions separation to have "edit structure" and "create" structure
tracker item
Need a print permission
It seems that the print and multi-print options are global. I would like to better control which wiki pages can be printed. It would be nice to have a tiki_p_print permission that could be appplied to pages and/or categories and/or structures.

If tiki_p_print = y, then the PRINT button will appear on the wiki page (if the print and/or multiprint options are enabled). Additionally, the page would appear in the list of available pages when using the multiprint option.
tracker item
Need Forums to Display per Group - Nevermind
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.
tracker item
New permission to administer modules (tiki_p_admin_modules)
To let Editors administer part of the site without making them full Admins (tiki_p_admin)
tracker item
Object permissions for menus: not functional
To reproduce:

1- tiki-admin_menus.php

2- click the permission key

ex.:
tiki-objectpermissions.php?objectName=Go Green&objectType=menus&permType=menus&objectId=56

{CODE()}Permissions
No rows found

Warning
You must select at least one feature.{CODE}
tracker item
Object Permissions: message "No permissions were changed" is untrue
tracker item
object/category permission Back btn corrupted
tracker item
Only Admin can view Categorized pages....
Hi,

I have set the following permissions for Anonymous

tiki_p_view
tiki_p_view_categories
tiki_p_view_categorized
etc

and the following category permissions

Anonymous tiki_p_view_categories
Registered tiki_p_admin_categories

Assign permissions automatically: Yes

Despite this neither Anonymous or Registered can view pages that have been categorized, the categories appear empty. Only way I can change this is by changing permissions on each individual page.
I've tried and tested this on 3 different installs, same problem each time. I am quite new to this but have spent many hours on this issue and would appreciate any advice.
I'm sure that there's a way but how?
Cheers

Wiki in question can be viewed at www.paddypaedia.com
tracker item
Optional disabling on javascript stripping protection
Tiki, be default, strips all javascript from all text box entries. This is meant as a security protection.

While most of the time, this is a good thing, sometimes, it is appropriate to use this javascript. For example, an add placed in a dynamic content module.

tracker item
Per user/group newsletter administration (adding category or object permissions)
tracker item
Per user/group newsletter administration (adding category or object permissions)
tracker item
Perm to access closed site seems broken
tracker item
Permission error on feature is broken (translation ?)
tracker item
Permission inheritance (default category) are not checked prior creating a wiki page
tracker item
Permissions : advanced feature: level configuration : it should be impossible to create blank level
In tiki-assignpermission.php, if you create a blank level and then, you have blank levels for some permissions, you will get an error like:


{img src=images/code.png}%%% {CODE()}
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later.


--------------------------------------------------------------------------------

Only one top level element is allowed in an XML document. Error processing resource 'tiki-assignper...

<b>Notice</b>: Undefined index: tiki_p_take_quiz in <b>tiki-...

{CODE}

And you can't via the interface re-assign the level to that permission. You need to clean the mess in phpmyadmin



If you have phpmyadmin, to reset permissions to original state:

1- go here:
http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/db/tiki.sql?revision=1.214.2.215&view=markup&pathrev=BRANCH-1-9

2- find "Table structure for table users_permissions"

and copy/paste that section (just that section) in sql commands

lines 4001 to 4191



reported by johnh on #tikiwiki

Maybe 1.10 is affected as well...
tracker item
Permissions for perspectives are not working
tracker item
Permissions Not Applied Correctly
I have a category "Main" associated with a "Main" structure which I DO NOT want people to be able to comment on. I have another structure "TS" with its own category and I want people in the TS group to be able to comment on TS pages.

Current permission set up: I have global permissions set to grant comment posting and reading to all Registered Members.

I have permissions in the Main category set so that no one has permissions to post and read (registered is unchecked, and no groups are selected), yet everyone can still post and read comments in main.

If I remove global permissions for post and read, then no one can post and read in any category, even if I grant the group those permissions for their category.

I ran this by a member of the IRC and they said it sounded like a bug as well. I do believe that I am using the permissions correctly, and that I should be able to limit this permissions by removing it from the category permissions.
tracker item
Permissions on individual galleries for tiki-galleries.php and tiki-list_gallery.php
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
tracker item
Permissions, File gallery; Clarifying what "Can download files" mean (can view image)
tracker item
permissions, tiki_p_wiki_attach_files
tracker item
Permissions: when assigning permissions to item, an option to start with current general permissions
Would make things easier to manage permissions.
tracker item
php errors aftert upgrade to tiki15: mb_strlen() and trim() expect parameter 1 to be string, array given
tracker item
Poll permission granularity not fine-grained enough
Granularity of permissions is definitely not good enough here.

E.g. you have to give Editors the tiki_p_admin permission for them to be able to do polls! I think Editors are usually in the position to do polls but not to admin the system.
tracker item
Post comment catgory permissions are ignored
Setting post comment category permissions doesn't work
Case:
1) Assign global anonymous allowed to post comments
2) Create a category NoAnonymousComments
3) Set the permissions for this category so only registered users can post comments
4) Create a wiki page "a comment test" and assign it to the category NoAnonymousComments
5) Log out
6) Look at the wiki page "a comment test"
The anomymous user can see and post comments

Seems like category permission to post comments is ignored and only the global setting is applied.
tracker item
Problem enabling poll participation by anonymous users
Anonymous users aren't able to vote in polls even after checking the poll vote option under ~np~groups --> anonymous --> tiki_p_vote_poll~/np~.

confirmed using 1.10cvs from September 9th, 2007
tracker item
Problem with Calendar Perms in v 3.0
Scenario:

#joeuser and janeuser are members of their own groups and a group called "General." All users are members of the General group.
#joeuser and jane user each have their own calendars. There is a General calendar as well.
#Perms are as follows:
**General group gets browse/view/change/add for General calendar, plus browse/view for joeuser's and janeuser's calendar.
**joeuser and janeuser get change/add for their respective calendars.

__Issues:__

#joeuser and janeuser can post to each other's calendars and can edit entries, which they should only be able to do for their own calendars.
#joeuser and janeuser can't delete from any calendars.
#anyone in the General group can edit entries and post to any calendar.

While I don't have a public site for you to duplicate it on, I checked the perms arrangement on one of my 2.x sites and it worked well.

---
2013-12-04 petjal
Tried to test on show. Calendar link threw error:
http://wikiman-10585-2248.show.tikiwiki.org/tiki-calendar.php
show:show
admin:showadmin
joe, jane pw:password
tracker item
Quick Permissions "advanced" setting removes all perms
tracker item
Quick permissions on a BigBlueButton object permissions
tracker item
Redirect after login back to the HomePage
tracker item
A new page in a wiki structure doesn't inherit categ perms from structure parent but only object perms (unexpected for intranet type of sections of wiki structures)
tracker item
Remove requirement of global tiki_p_view wiki pages in order to allow to manage one local structure
tracker item
respect/obey object permissions (beyond global) with plugin pivottable
tracker item
Roles and Permissions
tracker item
RSS Calendar Security problem - anonymous users allowed access to secured calendar via RSS link
Preface: This is my first bug entered and I am also *very* new to TikiWiki.

With that disclaimer out of the way:

The problem is that the RSS calendar link at the bottom of the default install seems that it bypasses or overrides the security.

I had set up a restricted category and a restricted calendar tied to that category. I created a user with access and it worked fine. I logged in as a test user to make sure it was working correctly. I could see the public calendar and the public topics but not the restricted ones. I thought this is great.

Then, when I was not even logged in as any user, I clicked on the RSS feed at the bottom of the screen and guess what? It showed me all the contents of the restricted calendar and the public calendar, too.

Thanks.
tracker item
sandbox not available for users
Logged in user without edit permission can not use sandbox.

Despite comments, tiki-editpage.tpl, checks for edit permissions and displays 'Permission denied ...' See test around line 71 in tiki-editpage.php.

Further, the 'Preview' button is not displayed. See first line of wiki_edit_actions.tpl.

tracker item
Search results count overlooks permissions
When searching for terms which appear in areas for which a user has no permission, the search results show the full number of pages on which the term appears but the detailed results are limited to pages for which the user has permissions. This makes a certain amount of sense but may be confusing for users who are not aware that they are restricted from some content.
I'm not sure at this point whether this applies to only FT Search, Tiki search or both. (I've pretty much stopped using Tiki)
tracker item
separate permission to create forums
For some situations it would be extremely useful to be able to set a separate permission to allow a Group to create a new Forum.

This would then avoid having to give the Group the full tiki_p_admin_forum permission, which then also allows users in this Group to set Permissions.

Whilst the full Permission functionality is extraordinarily flexible and feature rich, it can also be quite confusing for a less experienced user and the use of Categories (ie using pre-packaged sets of permissions) is a much easier function which obviously should still be allowed from the Create New Forum screen.

This is still a valid feature request - so I've refreshed it (Aug 2013) - but its not a particularly high priority
tracker item
Share page bug
{THUMB(id=23, url="tiki-browse_image.php?imageId=23")}Share page bug on BRANCH-1-10{THUMB}

{THUMB(id=24, url="tiki-browse_image.php?imageId=24")}{THUMB}

I can no longer reproduce this behavior in 1.10. Please retest. Dave Thacker

tracker item
Some Wiki actions don't respect category permissions
tracker item
Split tracker admin/edit permission
The tiki_p_admin_trackers permission is needed to both edit the main attributes of a tracker and add/change fields etc., as well as to Export or Import csv files.

This means that when it makes sense to allow some users the privilege to Import and Export data in batch mode then they will also have edit access to the field structure etc which may not be appropriate.

tracker item
Standard permissions for features per groups
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).
tracker item
Structures section at object permissions table not shown
tracker item
the link 'remove from this structure' dont appears for any page in 'assing permissions to page'
A link to remove permissions from structure should be visible when editing permissions for a page that is in a structure.
In version 1.9.8.3, the version that I use, that link don't appears for any page.
I have detected the problem is a programming error in line 14 of file templates/tiki-pagepermissions.tpl. There is a test of variable $isStructure when the correct would be to test $inStructure that is the variable that is assigned in line 89 of file tiki-pagepermissions.php
tracker item
there is no tiki_p_edit_image_galleries permission
Although there are permissions such as tiki_p_create_galleries there is no tiki_p_edit_image_galleries.

So a group with tiki_p_create_galleries permissions can add a new image gallery but cant edit the description after they have added it. Which is a problem if they made a mistake.
tracker item
There should be a permission tiki_p_view_slides
Topic says it all
tracker item
Tiki Object Permissions
I have the global permissions set so that individuals can change the permissions of certain features. However, when doing so, the users are getting an error message on the tiki-object permissions file.

Notice: Undefined variable: tiki_p_admin_wiki in html/tiki-5.0/tiki-5.0/tiki-objectpermissions.php on line 36

Warning: Cannot modify header information - headers already sent by (output started at html/tiki-5.0/tiki-5.0/tiki-objectpermissions.php:36) in html/tiki-5.0/tiki-5.0/tiki-objectpermissions.php on line 469
tracker item
Tiki permission bug for page names using norwegian characters
TikiWiki 6.3 has a permission bug.
If the page name contains any of the characters æøå, groups without any permissions will still be allowed to view and edit the page.
tracker item
tiki_p_admin_menu: new permission to manage menus
As of Tiki 1.9.7, only Tiki admins (full admins) can manage Tiki menus. Yet, this is often something we may want to delegate to editors.

tiki_p_admin_menu would be very useful
tracker item
tiki_p_admin_objects enabled for a user, but no key icon appears in file gallery
i want to share files between groups of users, some can upload, some only download, others administrate (create and manage file galleries).
my problem is that the administrator users cannot easily assign permissions to the file galleries:
via a dedicated group i assigned tiki_p_admin_file_galleries and tiki_p_admin_objects to those users, but the key symbol to assign permissions to file gallery objects does not appear for those users. they can, however, use the link tiki-objectpermissions.php manually.

does the feature to show the objectpermissions depend on any other flags/permissions?
i could not find any hint in the documentation so far..
tracker item
tiki_p_watch permission:
tiki_p_watch_trackers exists.

But there should be a general watch permission. For a registration website, we want people to have accounts, but not necessarily to watch pages. Thus, now, we need to deactivate watches altogether.
tracker item
tiki_p_wiki_post_comments is missing for individual wiki pages (tiki_p_wiki_view_comments exists)
tiki_p_read_comments & tiki_p_post_comments exist in general permissions, but post is missing from specific wiki page override:

{img src=show_image.php?id=8}

tracker item
tiki-list_object_permissions.php -> Needs tabs for missing features
tracker item
Tiki's search engine does not respect permissions.
This needs to be solved or a big popup/note included when tiki admins activate the search feature.

It should also be listed in tiki-admin_security.php
tracker item
To post image in Blog you need tiki_p_upload_picture (in Wiki perm section)
tracker item
To show Links with no Permission for anonym - turns external Sitemap creation in a disasterarea 302
The Problem
i.e. the structure tee ist partial accessible for anonymous -
but in the Page view /tiki-index.php?page=xyz all the substrucktures are clickable but they are not accessible (permission of the subtree gives a 302 for the visitor - so he must go back ...

a robot like google creates so much traffic becose he want follow this dead links

so i thought this is solvable by a sitemap
but Tiki has no intern tool for a sitemap like some other cms.
so i started with a online sitemapgenerator - but disasterarea 302 permission
next sitemap-gen.py from sourceforge but the same disasterarea 302 permission
but much bigger becourse it generates from the apache accesslog.

So next i thought about this mess!OK Why create a link if it is not clickable for anonym
yes thats the first solution to give the thing a straight line

looks like a big bugfamily

<lq_013> before a few day's i started with working on a sitemap for tiki
<lq_013> first Idea with using a external tool end up in a disaster
<lq_013> this courced by permission on some struktures
<lq_013> next disasterpart is the rewrite seo engine wich produces some pages 4 times
<lq_013> each accessible in an other way
<lq_013> the sitemaptool from sourcefrge which makes analyse of the access.log produces much more shit
<lq_013> some things can be restricted in a config file but thats no god Idea
<lq_013> so my suggestion to solve some of this sitemap disasters is to cancel all a href=... where annonymous can't click to
<lq_013> this is more then recommented becourse all visitors and searchengines follow this links and get a 302
<lq_013> with redirekt to login or whatever
tracker item
topic permissions not working in tiki-list_articles.php
Upgraded from 1.8 -> 1.9 -> 2.0 -> 2.2.

In version 2.0 and above, anonymous users can list all articles despite topic permissions that should restrict listing to topicID of 0 or "public".
tracker item
Tracker history permissions for anonymous
tracker item
Trackers need "tiki_p_trackers_view_own" permission to view own items only
Trackers need a "view own items" permission. This would allow a user to view their own tracker items only. Thus, one could stop users seeing each others support calls, or in my particular planned app, other people's product registrations.

An example of the use of this is in product registration. My users would enter a serial number and some other details, like product location. Other products registrations are confidential, so thy shouldn't be able to see them.

If at a later date, a user wants to change their product details, so maybe change the location of the product, then they will see a list of only their products.

---
Related:
Tiki trackers for help desk -> customer support requests (requests are private)
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1293
tracker item
Typos on http://doc.tikiwiki.org/Permission
The comments on the page ((doc:permission)) report a couple of typos that should probably be fixed since they claim to date from March 2006.
tracker item
Upload File dialog drop-down list includes galleries the user does not have permission to view
Under File Galleries -> Upload File.

On the selection screen, there is a drop-down list for which gallery the user wants to upload the file to. This list includes galleries that have either been deleted, or the user does not have access to view.

Under the user, manually entered the gallery ID to view the galleries that should not be listed, and access was denied.

Clearing the cache did not change anything.
tracker item
User "Admin" does not have permission to admin polls after feature activation
CVS update of 1.10 at 04:27 UTC

After the admin user "Admin" enables the poll feature, they are unable to access the poll administration page.

To reproduce:
1. Log in as admin
2. Enable Polls checkbox via the Features-->Admin Page
3. Click on "polls" in left-hand admin menu
4. Permission is refused.

Another way to reproduce
1. Log in as "Admin"
2. Click on "Admin Home" in the left hand menu
3. Click on the "Polls" Icon.
4. User is taken to ~/tiki-admin.php?page=polls, which is not Polls Admin, but Polls comment admin.
5. Click on link at top of page: "To add/remove polls, look for "Polls" under "Admin" on the application menu, or Click Here."
6. URL when hovering is ~/tiki-admin_polls.php
7. Receive permission refused error.



tracker item
User can set permissions of file gallery when tiki_p_assign_perm_file_gallery is OFF
tracker item
User Information Page shows non-public wiki page titles
Wiki Pages that are in non-public categories (or are otherwise not accessible by anonymous) should not be viewable. This error has been fixed in other places (like RSS). However, this page:

http://www.michaelrisch.com/tiki/tiki-user_information.php?userId=XXX

shows non-publicly accessible wiki page names. Clicking on the name (thankfully) raises the security error, but the name shouldn't be visible in the first place.

This is in 3.x - not sure if it is a problem in 1.9 or 2.x, though I would suspect so.
tracker item
Users (without admin perms) are able to create blogs in other user's name
With the 1.10b (and latest svn changes) it is meant for admins to be able to change the creator of the forums.

Unfortunately, all users with permission to create blogs, can now create blogs for any other user - even if they can not post to them.

It seems that the latest file templates/tiki-edit_blog.tpl and .php requires that a value for the creator is passed back from the field Creator. Thus, the field has to be present with a valid content.
tracker item
Users must have global tiki_p_view_trackers to see tracker item even if tracker specific perm set
The problem is summarized in 2:

1) The category perm checking for individual tracker item always happens no matter what.

2) Even when it makes sense to check for category perms, the filter appears to not take into account specific tracker perm, because trackeritem is a "different" object from tracker.

The problem is in the following piece of code in trackerlib.php

{CODE()}
function filter_categ_items($ret) {
//this is an approxomation - the perm should be function of the status
global $categlib; include_once('lib/categories/categlib.php');
if (empty($ret['itemId']) || $categlib->is_categorized('trackeritem', $ret['itemId'])) {
return Perms::filter(array('type' => 'trackeritem'), 'object', $ret, array('object' => 'itemId'), 'view_trackers');
} else {
return $ret;
}
}
{CODE}
tracker item
Users think they can include attachments to trackers, even without permission
Using a Tracker with an Attachment field with the TRACKER plugin:

If the user __does not__ have permission to attach files to tracker items (but can insert/create new tracker items), Tiki will, nevertheless, allow the user to select a file to submit with the tracker. Upon submission, there is no notification to the end-user that their attachment was not really included.
tracker item
Video item to be removed
tracker item
When assigning tiki_p_search permission to a group, all other "tiki" permissions are also assigned
To reproduce:

1) Log in as admin.
2) Go to Groups Admin
3) Assign tiki_p_search permissions to a group with no administrative ("tiki" type) permissions.
4) When page refreshes, you will see that all Admin permissions have been assigned to the group, and the Administrative links have been added to the Application Menu module.
---
Confirmed by dthacker

{THUMB(id=44, url="tiki-browse_image.php?imageId=44")}{THUMB}

A user belonging to this group also gets admin menu after logging in.
tracker item
When creating a page, how to inherit permissions from source page?
This is for internal groups within a wiki, a bit like ((workspace))s.

Some pages have special perms. We'd need a way that new pages created from these inherit permissions.

It could be possible to do via category permissions but..
tracker item
When editing permissions on categories for a single group, all permissions are shown as empty
To reproduce:

#list categories as administrator
#assign some permissions to a single group for a single category
#go to the page to edit the permissions again
#select only the group that used the previous step
#expand the categories to see the permissions already set

Result: All checkboxes are empty

Expected result: Checkboxes filled in according to the permissions set
tracker item
Whole column "level" in users_permission table gets nulled out
Confirmed on clean install of 2.4. Testing on opensourcecms.org, it does not appear this bug carried into 3.0. Have not found this reported in the forums nor bug tracker.

Since upgrading to 2.4 (sorry, only have Fantastico), there is a bug introduced with the permission level assignment capability (level configuration at bottom of tiki-assignpermission.php page). If used once as expected / described, then any further "update" to permissions in that same group will ''Null'' out the whole "Level" column in the __users_permission__ table.

Go to __groups__, __admin a group__, __admin its permissions__. Click "level configuration: show" way at the bottom. Do an assign of a level to that group and hit update. Once done, simply hit the normal "update" button in the "assign permissions" section. Does not matter if you change a permission or not. Now if you try to "level configuration: show" again, the level fields for every permission are nulled out and no levels appear in the "assign" list at the bottom of the page. Browsing the table in PHPMyAdmin confirms this behavior.

Note that you do not have to do a level assign a second time. Simply trying to change the inclusion of any individual permission (or making no changes but simply clicking the update button in assign permissions) will cause this to occur. Also, it does not matter whether "level configurations" are shown or hidden.
tracker item
Wiki Permissions inheritance is broken
My administrators and anonymous users can see my wiki. My registered users and editors, who inherit base permissions from anonymous users, cannot see my wiki.
tracker item
Wiki strucutures show pages, even if user does not have permission to view a page
If a wiki page is included in a structure, Tiki lists the page when viewing the structure (or when listing TOC) -- even if the user does not have permission (tiki_p_view) to actually view the page. This presents an invalid structure to the use -- they are seeing pages that they do not have permission to view. Tiki should only show pages (in a structure) that you can actually view.

Alternative impelentaion (proposed by luciash):
To have an option "restricted pages in this structure will be ommited from the list" or "will be shown but marked as restricted"

Confirmed in 1.9.8 and 1.10.1
tracker item
Trackers, Permission; Permission and tracker properties options are unsafe and need improvements (what about editing?)
tracker item
workspace should create and assign file gallery, too, to keep files separated as pages
tracker item
workspace templates don't cover all possible permissions as globally possible
tracker item
WYSIWYCA for all permissions : feature_check in Table: users_permissions
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
tracker item
WYSIWYCA on Inline Tracker edit
tracker item

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Kanban
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Federated Timesheets
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools