Category: Release20

After upgrading to 1.10, the icon to click to admin menu options does not appear in Admin...Menu. Need to reproduce and test.

When I go to administer modules I recieve this error.

An error occured in a database query!
Context:
File tiki-admin_modules.php
Url tiki-admin_modules.php

Message:
You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT `contentId`, count(*) AS `future` FROM `tiki_programmed_

This problems started after I upgraded to 2.0. I do not know what any of this means and need some direction.
Thanks
Cindy

The admin menu does not appear on first login after fresh install of 1.10

{syntax type="tiki" editor="plain"}
Administration, Features, Wiki


I can enable the 'Pictures:' feature in the 'Wiki Features', however when I then edit a page the 'Upload' feature does not appear.


I found if i remove the WYSIWYG editor feature, the Picture and File Upload becomes available when editing a page.

After editing and saving a certain section of a wiki page, it would be very helpful, if TikiWiki would scroll down to this section again, when reloading the page.

Many other Wikis like Mediawiki or Dokuwiki handle section editing this way and it is indeed very convenient.

Imagine you edit a section of a very long wiki page and you have always to scroll down manually, when you have saved the page but have to review it.

Upgraded a test/development site from 1.9.9 to 1.10beta1. Trying to get ldap authentication working to an active directory server. After configuring for ldap auth to AD - with 'use tiki for admin auth' checked - now I cannot log in as the admin user. The AD server is taking a really long time to respond, it's at another location - so it always times out. Unfortunately the Tiki site seems to keep trying LDAP and timing out before it will check internally for the admin user. The net result... I'm currently locked out of my development/test Tiki site. LDAP times out and I can't get in as admin either.

All users with permission tiki_p_search active can admin.

I've set up a user tracker at registration time on tw.o, when TwCOmmunity group is chosen between the two listed right now at registration time.
http://tikiwiki.org/tiki-register.php

This tracker mainily requests selecting a checkbox to indicate that the user understands and will follow the rules and guidelines of TW Community, etc.

I've set up a user field at that tracker, so that we can see when each users decided to join TW Community by selecting that checkbox. And while the compulsory checkbox is not acting as compulsory (due to bug), which users did accept and which ones didn't accept.
http://tikiwiki.org/tracker8

These are more patches on aulawiki.1.6.2 posted by xavi

* Versions 1.6.2x are intended just to make aulawiki work on tikiwiki
2.2, the way it worked before.
* Versions 1.6.3x -1.6.4 were transition step.
* Versions 1.6.5x -1.7.x has put back capability to add groups to the
workspace (not only users), and see all child's groups, starting from
the topmost a user can admin, when adding perms to single workspace
resources.
This was be done by adding some new functions to workspaceslib.php:

- get_includable_child_workspaces_groups : will get all groups in WS and child workspaces, starting from the uppermost on which one has admin objectperm down, purged by veryfing a list of includable groups to avoid loop inclusion.
- user_can_admin_workspace_or_upper(), an alias of
get_topmost_workspace_Iadmin(): will get up in the workspace path and
return an upmost parent workspace one can admin, thus gives him admin
capability on the ws and children, or false.
And in lib/workspaces/userslib.php, function group_can_include_group() will check if the group we are trying to include can be included.

with these functions a RolePerm with tiki_p_admin_workspace has
view of all child workspaces and their groups down from the
topmost one he can admin, no matter in which of these he is actually
(current workspace), and be able to add groups and assign perms to
groups within all these ones (only) without need of of having
tiki_p_admin_workspaces also on any child ws.

To the intermediate objectperm tiki_p_create_workspace_resour has been given as a gift the possibility to add single users, not groups, to the workspace predefined groups. On the other hand he can grant objectperms to his resources choosing among any group that belongs to his 'workspace-level'(brothers workspaces) + his parent's (dad, see what I am doing!)

This behaviour is easily changeable in the code, as the ability to do things is stated at the top, where (object)permissions on the workspace are tested once and translated into variables used throughout the code.

In practice:
===========
*'tiki_p_admin_workspaces' as an objectperm on a WS (got
from the RolePerms template for that type of Workspace) is de-facto a
local Workspace administrator. He can do everything (create new sub workspaces, add groups, change perms) except define new
workspace types and roles, and he sees only groups starting from the
topmost workspace he can admin to the bottom.
*tiki_p_create_workspace_resour, as objectperm on a WS (got from the
RolePerms template for that type of Workspace), can manage objectperms
of his ws resources (excluded the ws object itself) choosing among
a tree of groups that starts at his parent's level (dad, see what I am doing), includes 'brother workspaces' (on the same level, child of the same parent), down to bottom. He is a ''resource manager''. For adding users/groups to the ws, he can only add single users by typing the name, no groups. But if his ws has an admin group, he could add himself there. So __tipically workspaces either have a ws_admin role OR a ws_resource manager role__. On the other hand, a top, empty (no resources) workspace, with only an ws_admin role, would grant administration to all childs.
* For global tiki_p_admin_workspace nothing changes, although he is now prevented from including groups that include the includer, something that would put the entire site down.

For a user that has the approriate objectperms from the roles template
to the workspace (tiki_p_admin_workspace or, with less possibilities,
tiki_p_create_ws_resour, for the workspace object), everything can be
done starting from the resources module that has extra links to create child ws, add users/groups, and assign perms to resources.

The resouces module will show/hide Buttons and icons next to each
resource accordingly to what can be done by the actual type of user.


Most of the modifications happened in :

- tiki-workspaces_objectpermissions.ptp + templates
- modules/mod-workspaces_users_groups.php + templates
- lib/workspaceslib.php (new functions only)
- lib/users.php (new functions only)

With respect to the connection workspaces-categories, nothing should be changed. All categories related code is still there and used as before.

---
New permission scheme 1.7.0:
{CODE()}
1.6.2
------------------------------------------------------------------------
perm allows as allows as
name group perm objectperm
------------------------------------------------------------------------
view_ws - -view the ws

create_resour - -create resour onws

admin_ws do all on any ws -add group/user to ws


1.7.x
-----------------------------------------------------------------------
perm allows as allows as
name group perm objectperm
------------------------------------------------------------------------
view_ws - -view the ws

create_resour - (1) -create resour on ws
(de facto admin resour)
-change perms on ws
resources (excluded
the ws itself)
choosing from the
father ws groups and
childs
(father+brothers-to-bottom)
(3)

-add single users(not groups)
to ws predefined groups

admin_ws -do all on any ws(2) -create child workspaces for
any ws from the topmost ws
he has admin rights

-change perms on ws object
itself & resources &
child-ws objects and
resources choosing from
the topmost ws groups
he has admin rights

-add any groups to any ws
choosing from the
topmost ws groups
he has admin rights

-create child workspaces to
any ws from the topmost ws
he has admin rights

notes:
(1) this slot is free! Can't we use it to allow the creation of an
'organic workspace' of some predefined type with himself as
tiki_p_create_resour objectperm on it?

(2) as he can add the 'admins' group, and add users to it, he is
defacto a tiki_p_admin.
maybe he should only be able to add 'workspaces groups'? This would
make him different from a tiki_p_admin_groups and tiki_p_admin.
see comments and examples of different possiblties in
mod-workspaces_users_groups.php

(3) see comments and examples of different possiblties in
tiki-workspaces_objectpermissions.php
---------------------------------------------------------------------
TODO:
there's quite a lot I think, especially in the interface, making it
nicer and more intuitive.
-Add confirmation steps for various deletion actions
-Deletion of workspace does not delete its objects (should it?)
-test it really hard
-understand first, and maybe integrate, the working of 'Private Zones'
and 'user Workspace types' (isuserWS and userws filed in table).
{CODE}
---
LATEST NOTE:
Version 1.7.x has been committed to svn trunk.
You can now download the up-to-date version (not in mods format though) from:
https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/mods/trunk/features/aulawiki/
The mod in the repository does not provide a working example of these new features, it has the usual Teacher/Student Roles. One has to define roles with 'tiki_p_admin_workspace' and 'tiki_p_create_workspace_resour' to see this in action

Any registed user can use "Switch User".

I think this is very important, because everybody is able to be admin. :-(

Or can i dit a Misconfiguration? I dont think so.

---

today i see, everybody IS admin! (but i don't assign admin-perms to these users)

---

I found the Problem:

if i have tiki_p_search-permission so i have all "tiki"-perms too :-(

- How can i configure a group (or all users / anonymous) that they can use "search" (most important function of a wiki, i think) whithout make them admin?

Using tw.o forums and 2.0 (afaik):

You add a screenshot attachment to a reply in a forum post, and if you click on "preview" first, (as you would do on wiki pages), the image is lost (no tag is inserted on the forum post to help you link the attachment).

However, if you do the same attachment on a post, and click to post it (without previewing it first), the attachment link is shown.

Example at tw.o forums where it recently happened:
[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=29608&thread_sort_mode=commentDate_desc&was_queued=n]

---
according to comment added to this bug report, this issue is still present in branch Tiki5 still (so probably also in trunk)
---
Unbelievable, bug still present in forum posts in 12.x since 1.x! (with forum replies, there is warning, at least, but not yet with brand new posts in the forum and attachment is lost indeed) {sign user="xavi" datetime="2013-11-22T09:45:52+00:00"}

Reproduced here:
http://xavi-9794-1986.show.tikiwiki.org/tiki-view_forum.php?forumId=1
u: admin
p: 12345

Banners show as just an empty box when displayed. Images don't work, text doesn't work, nothing will get it to display anything but an empty box.

{banner zone=XXXXX} doesn't work either.

There appears to be some conflict regarding values returned by tikilib's list_file_galleries, returning 'parentId' instead of 'galleryId', when tiki-batch_upload_files.php wants galleryId.

This results in the pulldown list of which gallery to move the incoming files having wrong values set, moving them to the 'parent' gallery instead of the selected gallery, and for top-level galleries, moving them to the invalid "gallleryId = -1"-gallery, where they are unrecoverable.

With the prefs.feature_blog_heading perm enabled and tiki_p_edit_templates dissabled, users - with the perm to create blogs - will be able to create blogs but no heading will be shown when their blogs are viewed in tiki-view_blog.php.

In essence, unless both above named perms/prefs are enabled a user won't be able to create a heading, and no heading will be saved in DB for the blog.

And since the conditional to handle situations when $heading is empty has been removed in rev 9146 the blog will show no heading what so ever when it is viewed.

If I add an event for the 02/28/2009 the event does not display within the month mode, in list and week the event is shown.

Using the same 1.10svn from March 29th 2008 on two sites on the same hosting.

If "Time zone" setting at "Admin > login > default values" was set as default: "Detect Browser time zone if possible and site deafult if not" (or something similar) in the first tiki site, but unset on the second tiki site, then dates in site 1 are shown in tiki-calendar.php month view with a label which is wrong: it shows date -1 day. Site two shows the right date.

I.e.: today Wednesday April 2nd, on site one would say 04/01 (on the wednesday column, which is the correct one), and on site two, it would say: 04/02 (also on the wednesday column, the correct one).

When viewing the event at item view, then the date is shown correctly on both sites.

Once I set "site default" as default seting for new users on site one, dates were shown ok.

I'm afraid that previously registered users on tiki site 1 will have the wrong setting and thus, I will have to change their setting manually....

I would suggest that, if somebody else can confirm this bug, the default setting onp tiki.sql and 1.9_to_1,0.sql would be "site default" and not "browser based thingy....

Sometimes, first day of the week is Sunday, even if you set that to be Monday on Calendar settings.

This bug shows up for us (catalan interface, time zone "Europe Madrid (UTC+1)" when we have in tiki-admin.php?page=general, at preferecnes syntax:
"1.10 - $prefs.feature_foobar..."

When we swich this parameter to
"1.9 - $feature_foobar"

then fist day of the week in calendar is Monday, as expected

When trying to add a new page to an existing structure or create a new structure, I got the following error:

Field 'structure_id' doesn't have a default value

I check mySQL DB tiki_structure table, find the field 'structure_id' is not NULL,I check structlib.php,I find structlib.php not set the value of 'structure_id',only set 'parent_id',I guess that struclib.php have wrong.
structure is important feature ,wish to solve this problem


---
__''kerrnel22:''__ Unable to reproduce this in 1.9.10.1 CVS ...are you running CVS or release package 1.9.x? Also unable to reproduce in 1.10.0b1 CVS ...same question, are you running CVS or release package 1.10.0b1? If you are running the package in either, then it may be that the bug has been fixed in a patch to the CVS tree and you may need to wait for the next beta release.

---
re ''kerrnel22:'',i edit structlib.php line 202 :"$query = 'insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`) values(?,?,?,?)';",to "$query = 'insert into `tiki_structures`(`structure_id`,`page_id`,`page_alias`,`pos`) values(?,?,?,?)'; ,then out tiki can run,and can create a new structure.

While creating a new tracker in 1.10 error occurring.

An error occured in a database query!

Context:
File tiki-admin_trackers.php
Url tiki-admin_trackers.php
Query:
insert into `tiki_trackers`(`name`,`description`,`descriptionIsParsed`,`created`,`lastModif`) values(?,?,?,?,?)
Values:
0 daaku
1
2 NULL
3 1213325032
4 1213325032
Message:
Unknown column 'descriptionIsParsed' in 'field list'
Built query was probably:
insert into `tiki_trackers`(`name`,`description`,`descriptionIsParsed`,`created`,`lastModif`) values('daaku','',NULL,'1213325032','1213325032')

In database couldn't find 'descriptionIsParsed' field. Is it missed ?

{syntax type="tiki" editor="plain"}
"Delete unused images" in the Admin panels does not affect images uploaded via the WYSIWYG editor, and the user interface does not provide any other means of deleting ANY images from the FCKeditor upload directory.

I can't edit tikiwiki-1.10/tiki-index.php?page=HomePage when logged in as Admin.

1. Clicking on the Edit button on the bottom left results in quick "loading" message, but nothing else. The page remains as-is.
2. Clicking on the Edit icon on the top right results in quick "loading" message, but nothing else. The page remains as-is.

Page has the following text along the top, "Congratulations
This is the default HomePage for your Tiki. If you are seeing this page, your installation was successful."

A very crazy work around is to select "List Pages" on the left menu and select the page with a check mark, then click the Edit icon.

When using LDAP External authentication, I am unable to create a new user on the user administration page.

It does not require a password to create the user, but when you click Add, you receive the error message "Password should be at least characters long"


Users are created when they login the first time, but I need to configure permissions before they login.

If you use the categories mod, the trees have identical tags, such that a toggle of a tree node only toggles the node for the category in the module, and not the main category tree in the center column.

guys.. I fixed the probem.. doesn't appear that I can upload anything..


dthacker: thanks for the fix, but our dev's can't see what you changed. Could you please do a diff between your code and current CVS, and comment on the changes? Thanks!

When editing a page on dev.tw.o, I will have proper grammar and punctuation, but after I save it, it appears that all of my commas "," are stripped out in the display. When I go to edit (or even a preview from an edit), the commas also disappear from the edit window.

While not really a high priority, bad, this will crash the app bug, I think it's pretty important for someone who typed in text with proper grammar to have that show up.

*** Also noticing in the tracker, that when I submitted this ticket I had selected something in the Data Type, Feature, and Version sections, but they didn't save, as well as Area and Related Project. ****