site_a contains no content.
site_a has a folder community of community_a.
site_b has a folder community of community_b.
user is only in community_b.
user creates a new content item in site_b, enters content, saves.
content item is assigned to community_a!
How does that happen?!? He couldn’t have copied it from the other site, it has no content.
I know how to fix the problem in the backend table, but I want to be sure that this doesn’t happen again.
The behavior described by Jason is just the default behavior. It is possible to change that behavior either in the system def (applied to all ctypes) or in each specific content type. Do multiple content types exhibit that behavior? Did this used to work correctly?
When you copy an item, it is assigned the user’s current community by default. This behavior can also be overridden.
We’ve made no modification to the content-type community assignment. I’ve only had this reported to me for one content item. Since the current user can’t work with the content item via workflow (community mis-match), I’d imagine if it had happened with anyone else, they’d have reported it to me quickly. Therefore, I’m left to assume this is a one time event.
Emphasizing again, that the user in question is/was not in the community to which the content item was assigned upon creation.
I could file a ticket with Technical Support, but since I can’t reproduce the problem, nor can the user in question, I’m doubtful we’d get very far. The only thing I have to go on is the content item in question, and I’m not sure what that could tell us beyond what we already know.
We currently have a ticket open with Percussion (TAR#:MA-09-01-0018) on an issue much like you are describing, however we cannot reproduce the underlying problem. The problem (for us) is believed to be related to our database having multiple tables for the same content type. One of our content types (erauGeneric) was listed in the database with CT_ERAUGENERIC, CT_ERAUGENERIC_BAK, CT_ERAUGENERIC1, CT_ERAUGENERIC2 tables. Percussion was able to observe the community switching to the Enterprise Investments community but we could not find out why the extra tables were created in the database. The bug was believed to be related to our Oracle Database and Rhythmyx 6.5.2 environment.
We get that on our 6.5.2 system using Oracle 10g (recently upgraded to 11g.) Some of our content types have up to eight tables. It seems to have something to do with Rhythmyx trying to create/modify the table when you make changes to content types in the Workbench, but failing when it breaks some of Oracle’s rules on table/field name length. But the XML file in the ObjectStore folder only points to one table. We’ve been told we can delete the rest (but we haven’t got round to it yet.)
I don’t think I would delete those tables. The reason I opened the ticket in the first place was because when the new table was created all of the relationships to that content type were lost. When a user went to edit an item in that content type all of the data associated with that item was blank. I had to rebuild all of those items by cutting a pasting from the published site, thankfully we didn’t have too many live items in that content type yet. I have been told we are being given an SQL script that will re-associate the lost items to the new table.
This issue is currently being addressed within technical support. I already have the resolution and I’m currently testing it on your environment. You can look forward to receiving an update shortly.
Given your description and his, I’m not inclined to say that this is the same issue. In his situation, old content items of the affected content type will jump to the CI (Fast Forward) community when being updated. The behavior itself seems to be caused by multiple local tables for the same content type in the repository and the Objectstore XML file pointing to the latest table, not the original. The multiple tables were likely caused by known bug RX-12934 (Renaming a content type sometimes deletes the content type), but we are still testing.
In your case, it sounds like the item is put in the wrong community right from it’s insertion and it’s only happening for a single user. The cause could be similar, but there’s no way to know without getting a copy of your environment and reproducing the behavior.
If the user can reproduce the behavior consistently, submit a ticket to TS.
After significant testing here, we discovered that Steve was running into bug RX-14754. If you have a content type with a single local field and you remove that field, add a new local field, and then save the content type, you’ll cause a new local table to be created in the database. Since 1 local field is always required, you should technically create the new local field first, save, then remove the original.
The latest patch, RX-14789, addresses this issue by not allowing you to remove the only local field without first creating and saving a new one. Please contact Tech Support if you would like to download this patch.