Shared Content - Slight Change of Plans

So, initially it was intended to have a single table called "shared_content" to store information regarding the shared content, which would have the following fields:-

(content_id, user_id), both of which form the primary keys.

In the current implementation, when a particular content is shared with a group, we populate the database with all the users, who are in that group. But this would make the modification to any particular group difficult, as in that case corresponding changes to the "shared_content" table would also be needed.

So I think rather than populating the "shared_content" table with multiple rows, when content is shared with a group, it would be better to make another table "shared_content_group", with the following structure:-

(content_id, group_name), both of which form the primary keys.

In this way the group can be modified by the user. In case a group is deleted by the user, then we need to make sure that the corresponding entry is also removed from the "shared_content_group" table, otherwise if the user makes the group with the same name he deleted then this would result in problems, due to wrong entries in the database.

Now we have two scenarios:-

1. Find the users, with whom the author shared his content :- This is needed for making the UI of content shared by the author. I plan to do this by first querying the "shared_content" table, which would give the list of users, with whom the content is shared, then query the "shared_content_group" table and find the groups with which the content is shared. Finally, use this information to extract the users from the "group_users" table and make the complete list of users with whom the data is shared.

2. Find the content shared with any register user :- Getting this information from the "shared_content" table is easy, but getting it from the "shared_content_group" is a bit difficult. For this we need to first extract all the groups of which the user is a part of. Then find the content_id's (if any) associated with these groups from the "shared_content_group" table.

I think this would do the trick, I'll try to come up with the implementation of this in the next few days.

Details of Adding Shared Pages in AContent

This feature would allow an author to give editing permissions to the registered members, thus giving the fellow authors and non-authors the right to edit his content.

In order to add this feature a new tab to display and manage the Shared Pages is created and a new table called "shared_content" is created, which contains the information regarding what content is shared with a registered member.

This table contains two columns currently.

content_id

user_id

Both of which forms the primary key.

Using this information we can find the content shared with any particular user and give him the editing rights.

There is a possibility that we might have to add another column to this table which tells the type of the content :- "page", "folder" or "web-link", in order to add support of sharing all the data recursively under a particular folder or to enable the sharing of entire course.

Currently the work of displaying the content shared with the user in the side menu is under progress. There is also need to modify the current display of content under the shared menu tab. I am working to find the right javascript library which can help in giving a better and more intuitive display.

Details of Create User Group - Error Handling

On testing the system on the before described database table structure, I found that the system crashed when duplicate entries were added to the database, as the database would throw an error when duplicate entries would be added to the "group_users" table and the DAO library would thus call the die function, due to error in executing the database query.

For eg.

If groupname1 has already been created by author-1 and user-2 is in this group, then again groupname1 with user-2, should not be created by the same author-1 on pressing the Create Group button.

This step was giving errors due to duplicate entries being entered to the database.

So in order to resolve the issue, the database is now first queried if the row is already present in the database and if the row is already there, and if the entry is missing in that case it's added to the database.

Details of Create User Group -Problem-1(resolved)

There are two ways to do things:
1. If author1 ( say auth_1) creates a group (say gp_1) then it should be visible all the other authors as well. This is easy to implement but this way we do not ensure that every author must have his own preferences and thus auth_1 must have his own gp_1 and auth_2 must have his own gp_1

2. If author1 ( say auth_1) creates a group (say gp_1) then it should be visible to him only. If this is the case then auth_2 will also be able to create a group named gp_1 because for him user groups are different.

So to accommodate this the older suggested database(in proposal) could not work and had to be changed from :

1. group (group_id , group_name ,author_id)

2. group_users (group_id, user_id)

This will not work because here now if auth_1 submits the same form 2 times then 2 group_id's are generated and so we thought lets make group_name a primary key instead of group_id

1. group (group_name ,author_id)

2. group_users (group_id, user_id)

But now 2 authors cannot have the same group name for them as described above the group users list should be different for different authors.

So, finally to handle both the above issue, the following table is used

group_users(group_name, group_creator, user_id) PRIMARY KEY (`group_name`, `group_creator`, `user_id`)

This would handle both the above problems, different authors can have the same group name and single author cannot have two groups with the same name.