Category: Permission

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.

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.

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

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

Contributors

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.

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

Contributors

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)]

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

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}

Contributors

Contributors

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.

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.

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?

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.

You cant set it that individual polls can be set to viewed by only certain groups.

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.

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.

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.

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.

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.

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

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).

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.

One cannot assign permissions on individual FAQs. This prevents from creating FAQ for different level of users.

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 ;)

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.

Dear community,

Here's a screenshot:
{img src=show_image.php?id=70}
Many blessings.

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.

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".

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.

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

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.

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.

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

Contributors

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.

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.

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.

__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

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...

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.

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

This could also be by via category system (with perms)

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.

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)

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.

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.

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.

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.

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

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.

===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.

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?

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.

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).

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.

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.

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!

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.

Features Classification

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}

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.

Contributors

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



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

Permissions on individual wiki pages are great.

But what if you want to change the perms


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

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

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.

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).

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

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.

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.

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.

To let Editors administer part of the site without making them full Admins (tiki_p_admin)

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}

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

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...

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.

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

Would make things easier to manage permissions.

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.

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.

Anonymous users aren't able to vote in polls even after check the poll vote option under --> groups-->anonymous-->tiki_p_vote_poll

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.

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)

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

{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

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.

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).

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

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.

Topic says it all

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

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.

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