When user has no domain settings permission, system settings forms are submitted to all domains

Here is my first patch.
When user as no domain settings permission, instead of not putting any domain_settings form at all, the form is altered the same way, using the same submit callback, but with a hidden domain_id form item, which is set to a default value (what it would be if displayed).
This way, if an administrator decides that, by default, system settings forms apply to "current domain", then the user will save settings only to current domain.

Fixed title

Well, the theory is...

But in practice, it happens that I can be a user with "administer site configuration" permission, but without "access domain settings form".
This way, the system settings forms I submit will affect all domains, including default domain, even if I'm currently working on another domain.

That's really not the expected behavior (in my point of view, which may be biased), and at least, if it's not a bug, it should be a usability issue...

agentrickard : no warning at all, as Domain Settings just falls back to default behaviour if user has not access to domain settings form...

I should add that my patch does not force to save settings only to current domain if user can't see "domain settings form". Instead, it uses the "Default form value when submitting system settings" set in admin/structure/domain/settings.

This, maybe, could be considered as a bug ? When the form is not displayed, should Domain Settings save settings to all domains (which is actually the case), or should it use this "Default form value when submitting system settings" (which I suggest with my patch) ?

3.x port.

Indeed, the problems this other issue raises are interesting. I ported the associated patch 3.x then improved it a bit (see #809128: Restrict settings form to users with domain access).
I'm affraid both patches couldn't be applied one over the other, that's why I wrote a final patch, including modified patch in #12 and last patch in #809128: Restrict settings form to users with domain access (comment #9).

This "ultimate patch" is attached, and here is a summary of its effects :

• DS form* only displays the domains that current user has access to (if current user has "administer domains" permission, then all domains are displayed).
• DS form displays "All domains" option only if current user has "administer domains" permission.
• DS form has a default value fallback system : if only one available value, then it's the default, if many values are available, and a default could not be determined using configuration, then current domain is default.
• If current user has not "access domain settings form" permission, then the form is hidden, and the previously computed default value is used.

* DS form is Domain Settings form, abbreviated.

This prevents many flaws, such as saving settings to a domain I don't have access to, or saving to all domains while not having the permission. This also prevents from bypassing domain_settings module when having permission to access system settings form, but not the permission to "access domain settings form".

Regards,

David

I don't agree on this

  // If the user does not have access to this domain, stop now and allow the
  // normal form processing to occur.
  if (!isset($user_domains[$default])) {
    return;
   }

First because a user who has "administer domains" may not have current domain in its domains.
Next, I think that domain_settings should never disappear and let the form unaltered (which would mean letting the user save to all domains, without any check).

There are, indeed, ways to display a DS form where no suitable default is available. For example, when domain login is not restricted, users may possibly login on a domain they've not been assigned. But in such a case, is it normal, and secure, to let them save administration settings to all domains ? I think not.
Instead, I think that the user should be displayed the DS form, without any default selected. This way, he will have to confirm his choice by explicitly choosing a domain.

If user can't display the form (no "access domain settings form" permission) though, something must be done.
But failing to manage by-domain settings is not an acceptable solution. So what's about it ?

The last fall-back situation :

• user has not the permission to see the DS form (and thus to select the target domain)
• user has not been assigned the current domain, leading to failure to determine a default value
• still, user has access to the settings form

What kind of solution :

1. Throw "Access Denied" to user, although he should have access to the settings form ?
2. Display the computed DS form, telling the user the proper domain where to save could not be defined ?
3. Save to current domain, ignoring that current user is not assigned to current domain ? (After all, he's been granted login on this domain, and has access to the settings form.)

• Adding to above propositions, a message could be logged, to tell the administrator that something may be wrong with the site's configuration...

None of these sound extremely good to me, but those solutions sound better than "do nothing and save globally" option to my ears. My preference goes in this order : 3, 1, 2.

Regards,

David

Answering to your points :
- That's true, I forgot about that. ^^'
- Well, saving to "primary domain" also means saving to all domains that have no specific setting yet.
- That's true, but is there anything doable for these ? I guess not...

Attached patch adds following improvements to previous patch :
- as a last fall-back, default to current domain, only if DS form is hidden (if DS form is displayed, it can have no default value, forcing user to chose one)
- when DS form is hidden, display a warning message telling the user wich domain the settings will be saved to.

Regards,

David

No opinions on this one ?
Patch still applies on last dev version. ;)

It's possible to default to the current domain if the form is displayed. There's a setting for this in Domain Access. ;)
And my patch allow to follow that default setting, even if form is not displayed.