Content by user/permissions

Jen-

There are several issues here. Let's unpack and address them.

1) The ability to add content works perfectly for general service handbooks or FAQs, but we would like to provide clients with the ability to add restricted content relevant to eah individual client/user, such as: client x project handbook, that is content restricted to that user only. Currently MySite will list all books, including ones that are restricted to other groups and roles.

The mysite_type_book_data() function uses db_rewrite_sql() correctly, so individual book pages should not be shown to users who can't access them. Can you verify this?

Secondly, it may be that mysite_type_book_options() may also need to use db_rewrite_sql. This should restrict the list of books that an individual user is allowed to place in their MySite collection. If you'd like to test that, change line 38 of book.inc to:

  $result = db_rewrite_sql(db_query($sql));

This second issue may be an error in my logic, and thus a fixable bug.

2) Also, could each user be provided with thier own unique taxonomy in addtion to other general choices?

Not sure how this would work at the moment. Are you using a module for taxonomy-based access control? We could write a plugin that you use instead of the default term.inc.

Or do you mean "A user taxonomy consists of all posts made by a single user, regardless of how those posts are tagged or what type they are."? This case is easy to implement, though restricting access to it is not, see #4 below.

3) Another great feature would be the ability to post unique blocks per mysite user, w/ visibility restricted by user, kind of like og_blocks.

I'm working on block support right now. There is no plan, however, to restrict block selection per user (or per role). It might be easy enough to add per-role restrictions for block content. Currently, the administrator can define the list of block content that should be available for users to add to their MySite pages. I hadn't considered use-cases where visibility was an issue.

4) In general, MySite doesn't handle OG-style permissions because the MySite module is unfinished and its target is Drupal core. Advanced access controls (like OG) are potentially desirable, but I don't have the time to address them right now.

One development path might be for users to define who can see each element of their MySite page. The access to each content group could be set using permissions similar to node_access rules. The problem with this approach isn't the supporting code. It's the User Interface that your end-users would understand.

---

Let's try to tackle these issues one at a time.

#1 may be a bug. Can you test the above patch and see it it behaves as you desire?

#2 needs more information. Please open a separate issue.

#3 discussion should continue at http://drupal.org/node/128185. Reopen the issue.

#4 is another separate issue, which we'd need to define more thoroughly.

Again, let's go one at a time. You may need to close this task and open separate issues for each one.

0) Which version of MySite are you using? I've been developing in HEAD for quite a while. For the answers below, I'll assume you're using 5.x.1.10. If not, change the Version on this thread.

1) This code has changed some and been committed to HEAD.

If your original says:

$result = db_query_range($sql, BOOK_FROM, BOOK_THRESHOLD);

Try: $result = db_query_range(db_rewrite_sql($sql), BOOK_FROM, BOOK_THRESHOLD);.

This new code should work and would fix your privacy problem. If not, tell me what the error is.

2) We'd have to write a separate include, I think, to handle taxonomy restrictions. However db_rewrite_sql() works on taxonomy terms, so it may suffice to use that. Problem is, we're using taxonomy_get_tree() right now, which can't be wrapped in that way.

Open this part as a separate feature request, though I don't have time to look at it now.

3) Blocks are now supported in HEAD. When I finish documentation and testing, this will be the 5.x.2 release.

4) Addressed.

5) I looked at the code again. The database default is private, but the form default is public. (The database default value is '0' or 'private').

I fixed this in HEAD, so that the first time a user hits the MySite page, an account is created in the background, with the default value of 0.

If you need an immediate fix, find this part of mysite.module inside mysite_edit():

    if (!isset($edit['status'])) {
      $edit['status'] = 1;
    }   

And change the 1 to a 0. Likely this should be an administrative setting. If so, open a new issue to ask for that feature.

From your email:

And also is there any way to give users access to add content, but not to "edit mysite". I thought I could remove the "edit mysite" tab in the view, but I need to make the default for new all sites is set to private and not public view. Is there any way to accomplish this?

I don't think this would work with the current implementation. In the HEAD version, where MySite's are created automatically, you might be able to do this by changing the access permissions to the mysite_edit menu item.

However, you can _restrict_ user choices pretty easily. Here's a simple solution.

- Remove all LAYOUT files except default.php
- Remove all FORMAT files except default.php

If there is only one choice, users won't be given any options. (This may cauase problems if users have already selected the reomved options, though).

- Turn off the THEME include under MySite settings.

Change this code:

    $form['mysite_edit']['status'] = array(
      '#type' => 'radios', 
      '#title' => t('Allow others to see your personal page'), 
      '#default_value' => $edit['status'],
      '#options' => array(0 => t('No'), 1 => t('Yes'))
    ); 

To:

    $form['mysite_edit']['status'] = array(
      '#type' => 'hidden', 
      '#value' => 0
    ); 

This will force all user sites to be private. Again, if users have already set theirs to public, you may have problems.

6) Also from your email:

Also is there any way to restrict listing of added content or taxonomies in the list according to group permissions? For example "Content A" was submitted and access to it limited to "Group A" only. "Content A" is listed under "Group A" and added to a general "mysite taxonomy". Is there anyway to restrict members of other groups from seeing "Group A" content in the taxonomy listing?

Not really. See #2. We'd have to rewrite the mysite_type_term_options() function to handle the permission restrictions. The best way to do that would be to create an alternate term.inc (like term_access.inc).

--
Closing thoughts.

I am thinking about how to add a permission layer (likely in a mysite_access.module). But first I need to get v5.x.2 finished.

The permissions issue is complex, because there are so many different levels were permissions might conflict. For example, the Block and View implementation in HEAD totally ignores access settings for the parent modules, becuase implementation would be quite difficult. Instead, it is left to the administrator to simply select "public" content for inclusion in MySite.

I'm changing this to a "support request" since there are too many features being discussed. Open new tickets for new features.

OK. Now we're down to one issue:

#1 I changed the code and now there is no option at all to add book content at all under add/remove content. I have it enabled in Mysites, I double checked. All that shows up is the taxonomy(the only other option I have enabled).

Hm. You have group permission to view some of the books, right? The db_rewrite_sql() addition enforces node_access rules like those put in place by OG.

I have added the public/private default as a setting. It will be committed to HEAD later this week.

You can pay me back by bugtesting the 5.x.2.0-beta1 when I release it later this week....