Hi Neil,

Edit roles can be set at the page level or the feature instance level. View permissions are set at the page level for content system pages, that is, pages in the menu. For details see Roles and Permissions.

MyPage is currently either enabled or not enabled at the site level. It would be fairly easy to add a web.config setting to specify which roles can use it, but in general its a feature designed for public consumption not role driven. Its like My Yahoo or iGoogle, it allows users to create persoanlized pages using content made available to the public in the content catalog. Just like google and yahoo have widgets that users can add to their custom pages, you ca expose mojoportal features in the content catalog as widgets by marking the instance as available for MyPage. Some features work better than others in MyPage. Only content that has no security requirements should really be exposed as content for MyPage because it is designed to be available to all users.

SiteOffice, is disabled completely by default and is only enabled on the demo site to show the UI concept. There is a plugin model for it but currently no features that really work and the plugin model is not even documented, thought some developers have emailed and let me know they implemented their own features that plug in to it. I am really not sure of the future of Site Office. I implemented it with ExtJs and they changed teir license so now I cannot get upgrades or bug fixes. I would really like to re-do it using YUI, but I'm also doing some prototyping in Silverlight that seems very compelling for Line of Business apps which is the kind of apps I envision in Site Office. The current site office model is designed to be available to all authenticated users if enabled and the roles permissins determine which application features would load into Site Office.

I'm not sure what you mean by Event Calendar Pro export. Permissions to edit and manage the feature are managed the same as other features, by page edit roles or instance edit roles.

Hope it helps,

Joe

No, I meant it would be relatively easy for me to implement this in the next release so that you could use a Web.config setting. I will do this since it is easy to implement.

Event Calendar Pro does not curretly export to other calendars, it is planned for a future release to add support for import and export in iCal format but it is not currently implemented. I do hope to implement this in the next 2-3 months. My plan is that the export feature should follow the view permissions, if the user has view permission to see the events they should be able to pull those events into their own calendar program. It seems reasonable, because if a user can see the event nothing stops them from manually adding it to their google calendar for example.

Maybe what you are thinking of is our Oomph integration, which is a javascript utility that works on the List View and does allow users to import events into Yahoo or Google Calendars, but all it does is recognize the events in the page by the way they are marked up in html. Its not a true import export as I envision but I suppose it is an export. In any case, it works the same way, its just a convenience, if the user can't see the page because they are not in a role to see it, then they can't import events. If they can see the events then why disable it since they can still manually copy events into their calendar.

It sounds to me like a lot of your pages should be member only in terms of view permissions on the page so that only your members can view them. I would create a role named Members and only add your memebers to the role and then use this role to protect member only pages. Users who are not in a role with view permission will not see the page in the menu or be able to view it even if they know the url.

Best,

Joe