Privacy

It is very customizable indeed. But i am afraid i don't understand what you mean exactly. Can you explain this a little, maybe by use case ?

Do you mean that a stream should be customizable with user options? E.G. "i dont want to see messages with type X" ?

thx for input

This is a feature i am willing to implement for a long time. But i have some difficulties on how to build it.
Example i have created some nodes and i posted a shout or facebook status message.

Options from here:
1/ There is a heartbeat block available at the user profile page that shows his personal stream, as there is now. Here there would be an extra button in the heartbeat messages that leaves me as user a choice: a) makes the message public to all, b) leave it private or c) maybe only me and friends. Just updating the value of access would fix it already. This would work great but there are some issues with this aproach.

• Site builders have the option to set the private activity block. If they don't, they would have to know from documentation that it is possible to "block" activity.
• So this "block" is my next issue. This indicates that it happens after it's logged. So other users see it at first and the user should go to his profile page to "correct" it. So we certainly would need a kind of afterEvent box that appears to ask the user what he will do with the just-now occured event. Strange in some cases.

2/ Everytime activity is about to be logged, the logged-in user is asked in his original event if (s)he wants to make this public. Everytime feels kind of awkward since even flag link can trigger events, even worse, some events are done by cron ... . This would be very difficult as for starters we would have to hook into every form that triggers events heartbeat can log to.

So currently my best guess is to do it customly. I give an example of how it's can be done:

I alter the shout form so a selection box is added to have the access choice described above. When submitting the shout box, we hook into the submit to log activity (in hrules module it's done by rules) . In that data that's about to be logged, we can use the added access option to populate the access field.

There is an easy way to have the same functionality that Activity2 provides but even more flexible. Since every logging of activities is triggered by rules you can use a condition to check if the acting users wants an activity to be recorded. All you need to do is create a setting for this (profile fields or cck if using content profile). This setting is checked in rules. It is some work if you're having many different messages but it would allow users to decide for each type of activity if they want it to be recorded. Activity2 is not that flexible.

Hey Drake,

Really like you name btw :) Joey tribianni will be glad.

Well here are a couple of things :

Since every logging of activities is triggered by rules you can use a condition to check if the acting users wants an activity to be recorded.

. This is not exactly true. You can log activity by calling the api function and that's even more customizable. In the submit hook we check the extra field. But as you said, you could do it with rules conditions but that's not the same thing. I want it to be logged for sure!! And when viewing it, the access is checked, since i do want to see such a private message in my own private stream.

The other thing you said, is true : i want to enable message templates in the user profile (profile/content_profile indeed). So this is something i will create this week. Good proposition.
But again, it's not the same thing. Check the following use case:

I posted three pages. Two of them can be public, but in the third page, as an author i want to decide to not show that particular one....

so i am thinking further.

The approach we discussed is committed. You can now opt in / out from messages (http://drupal.org/cvs?commit=331350).
So on the account page we see the access set by users. Notice that we write and check access at display runtime and not at logging. The reason for this is simple: Users can have set that they dont want to see pages and they still see all the old pages. You encounter this by updating the profile and on submission changing the value of access but i did not choose for that.
As i still want developers and implementers to have the chance to log access custom, i change the log access value at this point. A later check if the value is not public, is enough to say that the custom visibility overrules the other settings.
Techy talk, but i gave it some thought.
Example of this:
You have a shout box and you form altered to let it take a custom checkbox "keep this private". Then you would set this value to the access value throught the heartbeat_api_log function. This would always be more important than the user saying "everyone can see this page type messages).
Well, i tested it, and seems to work. The demosite will have that functionality soon.

Please test it out and gimme some input on this new feature.

Note that it has slow down heartbeat a little as every actor needs to load with its heartbeat relations. I intend to later move it to friendlist_activity as it is not all needed for the api module itself.

thx
Stalski

Privacy option needs user to have control on who can see their activities and not the other way around.

If you say you don't want to show messages "adding nodes" for restriction "only to friends" , then only your friends will see it, etc ...
This works great for me. Am i missing something?
Users decide how their activity will be shown to others.

This is really weird. I can see it working as you demanded :/
So i say 'adding an article" : only my friends can see it. I log in with a friend, and see it. I log in with no-friend and i dont see it. The public heartbeat i took as example.

Are we talking about something else or so? ;)

what's the status on this?

Committed the result of this debugging process. Thx gkap for pointing this out.
the bug was simply said that the permission "never" show messages to others just wast approached correct. This fixed and the setting works.

Feel free to reopen if someother user profile setting bug comes up.