Ben Tiedt:TinyMCE in SP3 loads dialogs as modals by default. You can try disabling this by adding <editorOption name="dialog_type" value="window" /> within the <editor> nodes in the communityserver.config file for both the "Standard" and "Enhanced" editors. This will cause all dialogs to be loaded as new windows (slightly slower, but may correct this issue).
TinyMCE in SP3 loads dialogs as modals by default. You can try disabling this by adding
<editorOption name="dialog_type" value="window" />
within the <editor> nodes in the communityserver.config file for both the "Standard" and "Enhanced" editors. This will cause all dialogs to be loaded as new windows (slightly slower, but may correct this issue).
I saw you on my site earlier and appreciate you taking the time to look into it. That did the trick! Thanks!
Hi Edoardo,
Edoardo: I'm running a CS configuration that, thru Morpheus, leverages an aspnetdb that is on a different database (same server, dedicated db) from the CS's one.Now everthing works fine except for two things: I cannot rename a user I cannot delete a user In both cases the sprocs cs_user_rename and cs_user_delete are fired against the CS db and they point to a aspnet_user table that's on the CS db (the wrong one in my configuration). The result is that any operation against the userlist crashes (inconsistency between the local cache and the aspnetdb). Is this a supported scenario? Is this to be considered a bug?
I'm running a CS configuration that, thru Morpheus, leverages an aspnetdb that is on a different database (same server, dedicated db) from the CS's one.Now everthing works fine except for two things:
In both cases the sprocs cs_user_rename and cs_user_delete are fired against the CS db and they point to a aspnet_user table that's on the CS db (the wrong one in my configuration). The result is that any operation against the userlist crashes (inconsistency between the local cache and the aspnetdb).
Is this a supported scenario? Is this to be considered a bug?
A known limitation of Morpheus in a multi-database environment is that user renames and deletes are not supported without modifications. Since a centralized rename of a user would impact all potential satellites sites using the same membership database, we do not make the change automatically. If this is your scenario, then you can change the sproc to point to the fully qualified tablename (server.database.owner.object) on the appropriate database. So, assuming you have access to the db via the same credentials you could change a reference of "aspnet_user" to "myserver.mydb.dbo.aspnet_user".
The only alternative would be to implement a distributed scenario where all satellite sites are notified of a user rename or delete, which is considerably more work.
Hope that helps...
One is glad to be of service...
Jose Lema: A known limitation of Morpheus in a multi-database environment is that user renames and deletes are not supported without modifications. Since a centralized rename of a user would impact all potential satellites sites using the same membership database, we do not make the change automatically. If this is your scenario, then you can change the sproc to point to the fully qualified tablename (server.database.owner.object) on the appropriate database. So, assuming you have access to the db via the same credentials you could change a reference of "aspnet_user" to "myserver.mydb.dbo.aspnet_user".
It helps, indeed. I see and understand: altough you could tie the rename/delete to the membership provider this would result in being potentially disruptive against local caches of satellite sites that we might don't know about. I'll go ahead and change the sprocs, pretty easy.
Thank you!
Bye.Dodo.
Running CS 2008.5 (v4.1.30912.2823) on Windows Server 2008 RTM and SQL2005 w/SP2.
Jose Lema: Actually, our current plan is to release the final bits of SP3 early next week (just a bit ahead of schedule)
Actually, our current plan is to release the final bits of SP3 early next week (just a bit ahead of schedule)
We are not in the end of "next week", but I haven't seen the final version of the SP3 yet. Or did I just miss it?
[:'(] Sob. Any news?
Dennis van der Stelt:As I see it, random comments can't be deleted. Of course there's something about them, but I can't see the difference. I just click one delete button on "review comments" page and sometimes they do, sometimes they don't. Good thing is, that the comments that can't be deleted, never can be deleted. It'd be much harder when they do delete after a while :-)
This issue has been resolved and the fix will be included in the final release of CS2007 SP3. The fix will prevent this issue from occuring to new posts. To correct existing posts, the following SQL can be executed against your CS database:
update cs_Postsset UserID = u2.UserIDfrom cs_Postsinner join cs_Sections s on cs_Posts.SectionID = s.SectionIDinner join cs_vw_Users_FullUser u1 on cs_Posts.UserID = u1.UserIDinner join cs_vw_Users_FullUser u2 on u1.Username = u2.Username and s.SettingsID = u2.SettingsIDwhere u1.SettingsID <> s.SettingsID
The issue is documented here: http://docs.communityserver.org/kb/article.aspx/405/deleting-comments-results-in-access-denied-message/
Erik P. Ernst: We are not in the end of "next week", but I haven't seen the final version of the SP3 yet. Or did I just miss it?
Today we announced the immediate release of Community Server 2007.1 (which included all SP3 changes).
I am in need of the source code.
Ben Tiedt: tinyMCE in SP3 loads dialogs as modals by default. You can try disabling this by adding <editorOption name="dialog_type" value="window" /> within the <editor> nodes in the communityserver.config file for both the "Standard" and "Enhanced" editors. This will cause all dialogs to be loaded as new windows (slightly slower, but may correct this issue).
tinyMCE in SP3 loads dialogs as modals by default. You can try disabling this by adding
Thanks Ben. This fixed me up as well.
Copyright© 2008 Telligent Systems Inc. All rights reserved CommunityServer.com • Telligent.com