View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1243 | Composr | galleries | public | 2013-05-21 18:55 | 2013-07-11 02:09 |
| Reporter | Rishi Saravanan | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 1243: create options for user to restrict viewing of uploaded images and videos | ||||
| Description | Right now I have our website set up so that whenever a user adds and image or video, it all shows on the front page and on main photo/video pages. This is probably making users shy to share more photos of themselves. Therefore I propose creating two restrictions the user could optionally apply when adding an image, bulk images, or video. Two checkboxes could be available under the Description field. One box would make it so that the photo/video could only be seen if someone accessed the parent gallery through clicking on the galleries tab on the person's profile page. The other box could restricting the viewing to Friends. One or both boxes could be checked. Both boxes would be unchecked by default. If you have other thoughts on this, I'm open. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 16 | ||||
| Sponsorship open | |||||
|
|
Hi Rishi, The "Don't advertise" feature could be done using custom fields and a block filter without any custom programming. I might need to put up a bug fix for you as filtering on custom fields had a bug, but otherwise it should work. Regarding the privacy controls, I have some concerns about doing this as a sponsored feature only as discussed above. I wouldn't really want to just do it for images and videos, because that would essentially leave Composr a bit inconsistent. I'd rather take an approach where we draw together the style of the privacy module (where you define your privacy on your profile fields), the concept of 'private' calendar events, and privacy for all these additional content types too: images, videos, personal galleries, news, downloads, catalogue entries. You would be able to choose a privacy level for all (in order of increasing privacy): - Visible to guests - Visible to members - Visible to friends - Visible to just me and staff I should note that incorporating this would mean we'd need to disable caching on certain blocks, but that shouldn't be a big deal (as now block display would be very user-specific, not shared). I will put in a cost with this in mind. If you do just want to do it for images/videos, we can do a lower cost, but it wouldn't be incorporated into Composr yet. We'd do it in a branch, and hopefully pull that branch in at a later point when we considered the functionality well rounded. |
|
|
Hi Chris, It certainly sounds good to be consistent and apply privacy options for all those content types. I like the broad vision of it. It will be a significant upgrade. Let's do it. |
|
|
Hi Chris, This topic brings to mind a couple more questions: 1) I've never quite understood an aspect of adding Friends. It appears that user A can add user B to his friends list without user B even granting permission. That doesn't seem to give us much control over who is in our friends list, therefore diluting the idea of privacy. We'd have to keep removing people we didn't want in our friends list. Was this intentional? (maybe you already explained this before and I'm forgetting). 2) how difficult would it be to have an additional privacy option where we could choose specific members to view our piece of content? |
|
|
1-- The idea is that Composr maintains friendships in two separate directions. When you add a friend, the other can choose make it mutual. However, I took a look and this was not at all clear in the display, so I've made some changes to the layout. Now on someone's profile you'll only see friendships that that person has set. Privacy settings are/would-be checked in terms of what the member who owns the content has set. If Sally has said Bob is a friend, and made her content friend-accessible-only, Bob could see Sally's content. However, if Bob had not set Sally as a friend, Sally could not see Bob's friend-accessible-only content. |
|
|
2-- Adding this would bump it up to 16 hours. I do like the idea. This all touches a lot of database querying code, and category listing code, and that has been largely rewritten in v10. Therefore I think the best way to approach deploying this for you would be to implement on top of v10, and upgrade you to a v10 in-development version. A few client sites are running different v10 versions and it is generally stable. |
|
|
1) okay, that's how I figured it should work. 2) this feature would bring the privacy level up on par with other social networks, so let's do it |
|
|
* Something's gotten mixed up on the sponsorship credits. * For the "Don't Advertise" feature, let's have a question mark next to it so that a tooltip pops up where I can explain what it means. |
|
|
Hi Rishi, Did you try reinputting '96'? I think you need to put in the NEW amount, rather than the ADDITIONAL amount. (Mantis, the bug tracker we use, is a little quirky) |
|
|
This is now implemented into v10. Rishi, I think the best course of action is if I back-port specifically the images/videos parts for you. Generally there are a lot of changes all over the system for this, e.g. the calendar is heavily altered and that's interwoven with other privacy changes made for another customer, but you don't need most of them. v10 isn't really ready enough for release yet. I have changed my view on the "Don't advertise" feature. You are using the activity feed, which can't actually be filtered by custom fields. However, the way privacy is implemented, you can set content to members-only. Such content will not show on the activity feed, as that only shows fully open content. I think overall that is neater anyway. Some notes: - We have implemented a notification for when friends are invited to content - We have implemented a privacy control for the member photo - The privacy functionality is in the new 'content_privacy' addon. Hence, it is optional for sites to have this - It is quite nice that essentially we now have per-entry permissions. I never wanted to extend the current group permissions scheme to entries, as that would be unwieldy, but this works intuitively and works as a base for other interesting future possibilities |
|
|
Sounds like a plan, Chris. After it's back-ported, I'll test it out and see if there are further questions. I'll need to test that part about "don't advertise" to more fully understand what you've done instead. |
