Hi agentrickard,

I thought I'd expand on my original post in order to get a stronger grasp of what I need to do to achieve my goals. My use case is differing from yours and that is where my confusion really lays. I think there's a big need for what the module was originally intended for. However, I think there is a great opportunity to expand on it in a way that may be of even more interest to the Drupal community.

Emphasis

My interest is more in the area of your user domains component.

Goal

I need to offer the ability for each user to their own social network / website / blog / profile. User domains is perfect for this. Imagine Myspace as an example of this.

Challenges

With the current setup I've discovered a couple barriers in achieving the goal.

I would love to sort out the following...

1. Configuration tools that allows a User Domain Owner to restrict access to their user domain.
---- There are a couple modules that will allow me to restrict access to nodes, which is great. But I'd like to offer the ability to lock off the entire sub-domain.

2. Provided that there's a solution to #1, I suppose this can be accomplished with themes, but I wonder how difficult it would be to allow domain managers the ability to redirect uninvited guests to a "this site is private" page. Again, Myspace is a perfect example of this.

3. This next one seems like a security flaw... and a fairly serious one at that... but forgive me if I'm wrong... it could be by design, based on your needs.

Currently the user has the ability to publish content where he shouldn't be allowed to.

For simplicity during development, I have it set so that the average user cannot post to other domains. I've achieved this through disabling the Access Control "View Domain Publishing". Theoretically, the user should only be able to post it to their own domain.

From the publishing settings on the add node, this is apparently the case.

---- However, by browsing to one of the other domains, the user still has the ability to create content which is published to that domain. This can be done via a menu item. Or by browsing to subdomain.local/node/add....

I can't imagine this is by design... because after posting using the described method, the user get's an Access Denied message on their own content with no ability to change this with admin support.

By logging as an admin I can change the content back to their own domain, and after the access works as expected.

3. Building on #2... user ability to manage content on multiple domains.

Of course it is a great feature to allow the user to manage more than one sub-domain. While Myspace does not allow this, I think it's a great way to cut down on multiple usernames per user.

With View Domain Publishing enabled, it would be more useful (for all users) to not be given checkboxes for ALL domains. Even for admin... in my testing alone I've ended up with a dozen domains and in most cases I don't need or want to see the options to publish there. On big sites this could get out of control quickly.

Ideally.... a user would only see options for the domains that they are permitted to manage, and (following issue #2) only be able to publish content to those permitted options.

5. A user does not have the ability to publish to the "front page" of their sub domain, unless the content is also published to the primary domain front page via the overkill permission "administer nodes". This can be overidden in themes and views, but it would be a stronger implementation to have this as part of the module. I realize that this may not be possible due to Drupal's architecture.

---- phew ----------

That's it for now. IMHO this module could be one of the greatest assets to Drupal... let me know what you think and if you have any simple workarounds that might get this quickly inline with my vision. I'm primarily building a prototype and so I'm not worried about hack jobs right now...

FlexVixon

Comments

flexvixon’s picture

flexvixon commented

haha. And please forgive me for my grammar and numbering issues. I was copying and pasting all over the place..... :P

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Category: support » feature

There is an awful lot here to go through.

1) Domain Strict offers some level of access restriction. The problem is that normal users do not have a system for 'inviting' someone to belong to their domain. That would be supported by the current API, or by a small additional module.

You could also prefix the 'permissions' table per domain, but then you need a way for users to set permissions for their domain.

2) This is by design. Allowing users to publish on other domains is not a security issue (at least, not as that term is generally used). Configuring the module as described below will eliminate this issue.

I do not think that 'view domain publishing' -- which is a horrible name, I admit -- works the way you expect.

Give users the 'view domain publishing' permission and then set the 'Content editing forms' setting to:

 -- Take user to their assigned domain
  Before being presented the editing form, users will be taken to the
  first domain assigned to their user account.  This function is most useful
  when you users are only allowed to enter content from a single domain.

  Note that for users who have more than one assigned domain, this option
  will take them to the first match and the user will not be allowed to
  change the domain affiliation.

3) Read the section on what 'view domain publishing' actually means. Specifically this option:

  -- Show user their publishing options
  The node editing form is shown normally, and the user is presented a
  list of checkboxes.  These options represent the affilaite domains that
  the user is allowed to publish content to, according to the domains
  assigned to their user account.

  Note that if this option is selected, users with the 'view domain publshing'
  permission will also be shown a list of affilates to which the node is
  assigned. This list shows only the affiliates that the user cannot edit.

  Warning: If this option is selected and the user has no domain publishing
  options, the user will not be allowed to post or edit!

4) Why no #4?

5) You can set 'promote to front page' as a default workflow under Admin > Content > Content Types. These are global settings, though, which is a core limitation. Easy to change using hook_form_alter() and a little code.

As for the rest, this should all be supported by the internal API. If it isn't then let me know what parts are missing.

The real question for me is one of time. I don't have time to implement these features, but I can support their implementation through the existing system.

flexvixon’s picture

flexvixon commented
Category: feature » support

Yeah, quite long. I got excited as this meets a good 80% of the use case I've designed. Definitely opens doors. I'll do what I can to get the prototype up and running on my own, but when this thing goes to production mode I'll have a budget to sponsor more development. Perhaps we can chat about that...

In the meantime I'll spend some time looking at the API.

RE, your number 2__

Overall View Domain Publishing is a great start. Admittedly what I'm thinking about is a different level altogether - but one thing I can give you feedback on...

I got hung-up a few times because when I went to edit content it was kicking me to a different sub-domain than I was hoping for.

I looked closer and you did document the behaviour... that it defaults to the first sub-domain that you attached the user to.

That makes sense in a way, but it was super confusing at first. Again, allowing the user more control in this area would be ideal. I was actually forced to delete the user and recreate it again in order for it to default to the site that I wanted it to.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

You shouldn't have to delete the user. But you would need to edit the user as a user with the 'assign domain editors' permission, which allows you to set which domains a user belongs to.

'View domain publishing' has one main problem -- it is a global setting. What you really want are per-role settings for this, which would not be too hard to implement, but do need some thought.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Closed (works as designed)