I tried to integrate Dokuwiki with our Mantis installation and followed de Wiki on integration.
However I have a problem getting it to work.
I suspect that the problem lies in the fact that both Mantis and Dokuwiki resides as a subdomain within our webserver.
Without the inte3gration instructions, Dokuwiki is working fine.
After integrating it does not work.
When I click the link, Mantis will take me to
http://dokuwiki.
But page stays blank.
Where does the name space come in and how is that related to the plugins directory where you have to make a subdir called <mantis> and put in a syntax.php.
Can some verify that it should work with both systems ( Mantis and Dokuwiki ) as subdomains.
Thnx in advance,
Tom
Can Wiki integration handle subdomains
Moderators: Developer, Contributor
I investigated a little further and can now access Wiki. I had a problem while copying code to .php script.
My next problem is that I can not get into Wiki as a user:
When I change to
I get access ( anonymous I guess ).
It seems that the function returns false in in program dokuwiki\inc\auth\mantis.class.php .
I do not understand why because all authentication in Mantis is working correct.
Any ideas / hints appreciated.
Tom
My next problem is that I can not get into Wiki as a user:
I checked all files and contents from the integration document but cannot found any error or typo.Permission Denied
Sorry, you don’t have enough rights to continue. Perhaps you forgot to login?
When I change to
Code: Select all
$conf['useacl'] = 0;It seems that the function
Code: Select all
auth_is_user_authenticated()Code: Select all
function trustExternal($user,$pass,$sticky=false)I do not understand why because all authentication in Mantis is working correct.
Any ideas / hints appreciated.
Tom
You need to set the following configuration item in config_inc.php
Note that dot before the domain name. This tells the browser to share the cookie accross all sub-domains for your domain name.
Hopefully this fixes the problem.
Regards,
Victor.
Code: Select all
$g_cookie_domain = '.yourdomainname.com';Hopefully this fixes the problem.
Regards,
Victor.
Victor,
thank you, that did the 'trick'.
Just a question about authentication, does Wiki only recognize the default role of a user, or the role a user has in a project.
I have a quest account assigned to 3 projects as VIEWER and 1 project ( TEST ) as a MANAGER ( also tried REPORTER and DEVELOPER and UPDATER ), however the default role is VIEWER.
I added UPDATER to acl.auth.php
Tha account is not able to edit or create a wiki entry from that issue. It seems that only the default role is taken into account.
Can you verify that.
Tom
thank you, that did the 'trick'.
Just a question about authentication, does Wiki only recognize the default role of a user, or the role a user has in a project.
I have a quest account assigned to 3 projects as VIEWER and 1 project ( TEST ) as a MANAGER ( also tried REPORTER and DEVELOPER and UPDATER ), however the default role is VIEWER.
I added UPDATER to acl.auth.php
Code: Select all
* @VIEWER 1
* @REPORTER 2
* @UPDATER 4
* @DEVELOPER 8
* @MANAGER 8
* @ADMINISTRATOR 8
* @ALL 0Can you verify that.
Tom
It should support the project-specific access level.
If it is not working as expected, check that the $t_project_name is matching the name of the current project. It may actually be more reliable to get the current project using Mantis API, rather than extracting it from the Wiki page id.
Code: Select all
$t_project_name = getNS( getID() );
$t_project_id = project_get_id_by_name( $t_project_name );
$t_access_level = access_get_project_level( $t_project_id );
$t_access_level_string = strtoupper( get_enum_to_string( config_get( 'access_levels_enum_string' ), $t_access_level ) );
$USERINFO['grps'] = array( $t_access_level_string );