Test user doesn't have edit/delete access to the discussion thread they created

[ychae]

I think this is related to the general auth update but I wanted to track specifics where I could so I don't forget.

When I create a thread as test user, the ellipses drop-down doesn't show any options for me. However, when I log in as admin all the options are there.

As test user I have copy link, edit, and delete access to the parent thread once I click into the thread. But I don't get those options to the sub-threads and the thread in the main list of discussions:

[tschaffter]

Specifications

Project

• [x] Users with READ access to a project can SEE all the thread in this project
• [x] Users with READ access to a project can CREATE new thread
• [x] Users with READ access to a project can REPLY to any thread
• [x] Users with ADMIN access to the project OR (READ access to the project AND is the AUTHOR OF a thread/message) can EDIT the thread/message
• [x] Users with ADMIN access to the project OR (READ access to the project AND is the AUTHOR OF a thread/message) can DELETE the thread/message

Similar approach for

• [x] data catalogs
• [x] tools
• [x] general discussion

[ychae]

The following functionalities were tested in General Discussion, Project Discussion, Tool Discussion, and Data Catalog Discussion:

General, Tool, and Data Catalog Discussion - Test user creates new discussion:

• [x] Can add new threads
• [x] Can delete any thread they created
• [x] Can delete any thread they created
• [x] Can edit title of discussion
• [x] Can delete entire discussion
• [x] Cannot edit any thread that was added by admin user
• [x] Cannot edit/delete any discussion started by admin user

Project Discussion - Test user creates new discussion in a project that they created:

• [x] Can add new threads
• [x] Can edit any thread they created
• [x] Can delete any thread they created
• [x] Can edit title of discussion
• [x] Can delete entire discussion
• [x] Cannot edit any thread that was added by admin user (but can delete the entire discussion)

Test user creates new discussion in a project that they are invited to with READ/WRITE/ADMIN access:

• [x] Can add new threads
• [x] Can edit any thread they created
• [x] Can delete any thread they created
• [x] Can edit title of discussion
• [x] Can delete entire discussion
• [x] Cannot edit any thread that was added by admin user

Test user adds to an admin created discussion in a project that they are invited to with READ/WRITE/ADMIN access:

• [x] Can add new threads
• [x] Can edit any thread they created
• [x] Can delete any thread they created
• [x] Cannot edit/delete any thread created by admin
• [x] Cannot edit title of discussion (READ/WRITE)
• [x] Cannot delete entire discussion (READ/WRITE)
• [x] Can edit title of discussion (ADMIN)
• [x] Can delete entire discussion (ADMIN)

[ychae]

@tschaffter Thanks so much for all the updates to the discussions! Please see my comment above for results from testing -- long story short, all the expected behavior was working great!

The only odd thing I found was that when I deleted threads from a discussion, the participant icon list on the main page didn't update (see screenshot below):

To reproduce:

1. Log in as admin user
2. Go to any discussion (this example uses the General Discussion page)
3. Create a new discussion
4. Add in a couple of responses as admin (responses can also be added as test user)
5. Go to the main list of general discussion: you should now see the number of replies and a few new user icons
6. Go back into the discussion and delete all the responses
7. Go back to the list of general discussion: the number of replies are gone but the number of user icons remains the same.

[tschaffter]

@ychae The discussion is made of two models, Thread and Message. The Thread has a property called contributors. Each time a Message is added to a Thread, contributors is updated to keep track of the last N users who posted a message. The reason I have added the contributors property is that it's more efficient to get this information quickly rather than pulling the last N messages and extract their authors. The drawback is that contributors is a duplicated piece of information and because there is not reference link between messages and contributors, removing a contributor at the time of removing a message is not trivial. Moreover, the discrepancy we see is because a delete message completely disappear. In the future I not do it that way but instead still show that someone posted a message but deleted it. Not deleting purely objects but instead "deactivate" them would also be more provenance friendly. For now I recommend not changing the implementation as someone did contribute at some point in the discussion, even if the contribution has been deleted since.

[ychae]

Ah that makes sense. Thanks for clarifying!