Problem with LDAP

Post here for help with installing or upgrading mojoPortal pre-compiled release packages. When posting in this forum, please provide all relevant details. You may also want to review the installation or upgrading documentation.

If you have questions about using the source code or working with mojoPortal in Visual Studio, please post in the Developer forum.

Post here for help with installation of mojoPortal pre-compiled release packages

When posting in this forum, please try to provide as many relevant details as possible. Particularly the following:

  • What operating system were you running when the bug appeared?
  • What database platform is your site using?
  • What version of mojoPortal are you running?
  • What version of .NET do you use?
  • What steps are necessary to reproduce the issue? Compare expected results vs actual results.

You may also want to review the installation or upgrading documentation.

If you have questions about using the source code or working with mojoPortal in Visual Studio, please post in the Developer forum.

This thread is closed to new posts. You must sign in to post in the forums.
11/20/2008 6:12:28 AM
Gravatar
Total Posts 18439

Re: Problem with LDAP

Yes, this is now implemented in svn trunk so it will be in the next release. There is a new Web.config setting:

<add key="UseRelatedSiteMode" value="false" />

set it to true and all sites use the same users and roles as site with SiteID 1, if for some reason your root site has a different siteid, its also configurable.

<add key="RelatedSiteID" value="1" />

I think it needs one more thing that I will try to work on in the next few days, that is, in this mode we can set which roles can edit pages, but there is no setting for who can create root level pages in the site. If I add a site setting for this, then any pages created below root level will by default inherit the same permissions. So it will be possible for example to give a department its own site, create a role corresponding to the department admins and then assign that role as the site edit roles. Its still possible for system admins or content admins to create pages with different permissions. Admins and Content Admins role really becomes that for the whole system of all sites. We may not want department admins to have that power, so this new site edit roles will give us ability to delegate at the site level without sharing the super user roles.

For the moment I've shifted gears and working on a 301 redirect system for pages whose urls change when the page is renamed. After I complete this and the new site edit roles setting, I will make another release.

Best,

Joe

You must sign in to post in the forums. This thread is closed to new posts.