Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Some issues with the first conference service which is manually created.

Description

The first manually created group chat service gets the same service ID as the conference service which is added automatically. This results in the following issues:

  • When trying to create room with same ID of the room in other service it throws an error, that such room already exists, but still lets you to create such room.

  • Deleting one of the service deletes also the other and all rooms on both services.

  • Sometimes it copies permanent room from previous service

Apart from preventing these problems from occurring in the future, existing (faulty) configurations need to be fixed. These faulty configurations can be identified by the existence of two services with serviceID value '1'. As we cannot distinguish which attribute (room, property, affiliation, etc) belongs to which of the duplicate service, we will duplicate all of these existing attributes. This will result in a situation that mimics the existing behavior. We'll upset the least amount of users this way.

Environment

None

Attachments

1
  • 01 Jul 2009, 04:42 PM

Activity

Show:

Bill MacAllister January 14, 2011 at 8:42 PM

I just hit this problem on my 3.6 server. It seems to me that there is a more fundamental database problem if the intention is to allow separate services to have rooms with the same name. If that is what is desired then the then either serviceID needs to be added everywhere roomID occurs or the roomID must be unique across all services. It makes sense in that case to generate the roomID and don't make the end manually do a uniqueness search before creating a room.

Guenther Niess November 6, 2009 at 1:31 AM

In my opinion it looks good, so I closed the ticket.

Guus der Kinderen October 26, 2009 at 1:13 AM

Guenther, I just checked in your patch, slightly modified to allow the code to be moved outside of the SchemaManager implementation. This way, we at least keep that code clean(er). Could you review my changes, apply modifications where needed and resolve this issue please?

Guus der Kinderen October 26, 2009 at 12:35 AM

Ah, bleh. This is going to take forever. We're currently under some pressure to release the next version of Openfire. Lets be pragmatic and go with Guenther's solution. It is available now and will enable us to move forward.

Guus der Kinderen October 26, 2009 at 12:18 AM

INSERT INTO ofMucRoom ( serviceID, roomID, creationDate, modificationDate, name, naturalName, description, lockedDate, emptyDate, canChangeSubject, maxUsers, publicRoom, moderated, membersOnly, canInvite, roomPassword, canDiscoverJID, logEnabled, subject, rolesToBroadcast, useReservedNick, canChangeNick, canRegister) SELECT ofMucService.serviceID, ofMucRoom.roomID, ofMucRoom.creationDate, ofMucRoom.modificationDate, ofMucRoom.name, ofMucRoom.naturalName, ofMucRoom.description, ofMucRoom.lockedDate, ofMucRoom.emptyDate, ofMucRoom.canChangeSubject, ofMucRoom.maxUsers, ofMucRoom.publicRoom, ofMucRoom.moderated, ofMucRoom.membersOnly, ofMucRoom.canInvite, ofMucRoom.roomPassword, ofMucRoom.canDiscoverJID, ofMucRoom.logEnabled, ofMucRoom.subject, ofMucRoom.rolesToBroadcast, ofMucRoom.useReservedNick, ofMucRoom.canChangeNick, ofMucRoom.canRegister FROM ofMucRoom JOIN ofMucService WHERE ofMucService.serviceID = (SELECT max(serviceID) FROM ofMucService WHERE serviceID > 1) AND ofMucRoom.serviceID = 1;
Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created July 1, 2009 at 4:34 PM
Updated January 14, 2011 at 8:42 PM
Resolved November 6, 2009 at 1:31 AM

Flag notifications