Hi,
What a great piece of software. Rather overwhelming in the beginning but after a while I really started to like it.

When I login in as UID (superadmin), I am not seeing the private spaces.
Is that a bug or am I missing something?

Cheers, Joep

Comments

joep.hendrix created an issue. See original summary.

joep.hendrix’s picture

Addional info: The space I am not seeing is a private space.

dpoletto’s picture

Hi @josep.hendrix: when the User UID #1 (AKA the site admin) adds a new Space and publishes it by submitting "Publish" then that Space is published and - automatically (AFAIK) - the UID #1 is set as Direct Member (AKA simply Member) of that Space (Private or not, it doesn't matter).

Test by visiting that Space directly or just through the Sitemap: you should see the newly created Space frame, inside it a red colored (human) cut-out little icon; you can click that icon to visit that Space, once landed you should be able to see the "Members" push-button on the top right side of the Space page, click it and check the fact that admin (UID #1) is initially the only one Direct Member auto-assigned to the Space you're testing (in other terms the UID #1 becomes the "Group Manager" on/for that Space <- you can double check this setting on the Gear Icon of the admin profile under "Spaces"). That's pretty straightforward.

joep.hendrix’s picture

Thanks @dpolletto for your answer.
Sure thing, the creator of the space is automatically added as a member.

Let me explain the situation.
We reserve UID 1 as the technical superadmin.
Spaces are created by adminstrators with the role administrator. If a regular administrator creates a space then this space is not visible by the superadmin.
I expected that superadmin would see all the spaces even if he has not created them.

dpoletto’s picture

Precondition:

I suppose other users you describe (Regular Administrators) were created with the Administrator role enabled (as the UID #1 has) and no other changes were done to Roles/Permissions (read: you're simply creating *other* users with the specific Administrator role enabled and you're simply creating Spaces using those users accounts).

AFAIK I can reproduce two cases on my OA 2.44:

Case 1:

An Administrator role user (UID #2: that you called "Regular Administrator") creates and publishes a (private/public) Space -> the creator is added as (direct) Member/Administrator for that Space AND the UID #1 is able to see that Space.

Note 1: if anything...instead UID #1 is able to see the Space (and its Sections) although it - doesn't *explicitly* belong to/doesn't appear into - the Members' list of that Space (which could be seen as a strange thing because it is actually granted to access/able to interact with that Space without been listed into it as a Member and/or Administrator).

Case 2 (the opposite):

The Administrator role user (UID #1 that you called "Technical Superadmin") creates and publishes a (private/public) Space -> the creator is added as (direct) Member/Administrator for that Space AND the UID #2 is able to see that Space.

Note 2: if anything...instead UID #2 is able to see the Space (and its Sections) although it - doesn't *explicitly* belong to/doesn't appear into - the Members' list of that Space (which could be seen as a strange thing because it is actually granted to access/able to interact with that Space without been listed into it as a Member and/or Administrator).

So the situation is (or appears) symmetrical: in both cases Administrator role users (UID #1, UID #2, etc) are able to access all previously created Spaces despite the fact noticed on both notes...at least this is happening in my setup (eventually test it on Pantheon to have a confirmation, maybe my setup is messed up and your one is not).

Considering both cases above I note that this is not what is currently happening to your site; would be interesting to explain better what do you mean with "We reserve" (it lets me think you alter Roles and/or Permissions somewhere along the road to make the UID #1 more special than others).

joep.hendrix’s picture

Thanks for your support.
A private space is accessible by UID 1 or administrator by direct access by entering the URL. It is just not listed in the menu nor on the all spaces page (/spaces).

So it makes it hard for admins to see what spaces exist on the site.

dpoletto’s picture

Ah, OK explained this way is better.

I noticed that too: that Space is accessible directly and through the Sitemap too (where it shows up regardless the Toolbar's menu limitation) *but* it doesn't appear into the respective (for the logged user which isn't its direct Member) Toolbar's menu item (the "All Spaces" page, as example) for those Administrators that weren't the original creators.

joep.hendrix’s picture

Exactly, I would expect that at least UID 1 would see all spaces in the menu.

dpoletto’s picture

Probably it is an issue of the Toolbar or, conversely, of the Sitemap (I don't believe so)...but it depends from the point of view.

Yep, at this point, why not asking...since it's what actually happens by visiting the Site Map or by accessing them directly...to let Spaces to be enlisted in Toolbar menu for *all* users that share the *same exact* Administrator role instead of expecting to made it works only for UID #1 (in this way UID #1 will be not treated differently than similar others Administrators and vice-versa...if the role is shared).

I don't know if this all is correct at all...I'm just speculating.

= OT Begin =

A question arises in my head (hope not to be really OT) re-reading this thread: why it should be appropriate/opportune to have more than one (site) Administrator if then those Administrator users will share the same role without any specific distinction (as is implicit in your scenario)? ...doing so how you can "reserve" a specific role if that role looks shared? <- this in not part of the issue you wrote, it's just a consideration about what you wrote in describing your scenario.

IMHO I generally expect that the UID #1 user has default Administration Role, appropriate (call them limited/different) Administration Roles are created and are assigned to the *other* Administrator users (if necessary), those users that will need those roles to deal with specific and segmented management tasks.

= OT End =

joep.hendrix’s picture

Thanks for your thoughts.
It is not a specific UID #1 problem, also adminstrators do not see all the spaces.
For example for a large site there will be more than 1 administrator. However, the do not see eachothers spaces by default.

Workaround for now will be to create a group administrators have them assigned to each space by default.

mpotter’s picture

Status: Active » Closed (works as designed)

This is "by design" and is how the Organic Groups module works (used for making Spaces in Atrium). If you want to debate whether this is "good or bad" then you should probably discuss it over in the Organic Groups issue queue.

User-1 can only fully access spaces that they are members of. So either create the space using the admin account (so the owner of the node is set to the admin), or add the user-1 admin to an Atrium Group (like "Admins") and then assign that Group as a parent of your top-level Space. Now via membership inheritance user-1 will have access to all spaces below it.

If you make user-1 a Space Admin of it's Group (Admins) then this permission will propagate as long as sub-spaces are set to "inherit" permissions rather than "use child" permissions. So in this way, user-1 can be automatically made a space-admin of every space.

In general, Atrium does not use traditional "roles" in Drupal very much. It is designed to assign users to Groups and then use the OG Permissions of the Group to determine the user permissions in a specific space.

joep.hendrix’s picture

Thanks Dave for your reply.
The problem is NOT that I cannot access the space, the problem is that the private space is not visible in the spaces overview (/spaces).
Even if the parent group is set to a group the user belongs to, the space is not visible.

For clarity these are the steps I have taken:
- fresh install of openatrium-7.x-2.44
- create additional user admin and assign the administrator role
- login as admin
- create a group administrators and add the siteadmin (user-1) to the group.
- create a private space and assign the adminstrators group as its parent
- login as user-1
- navigate to /spaces

The private group is not listed here.
When navigating to the node directly, the space is visible for user-1.
On the Sitemap page (/sitemap), the space is also listed.

I hope I have shed some light on the issue.

mpotter’s picture

In the /spaces page you should see tabs across the top for "Memberships" and "All". The "Memberships" tab only shows spaces that you have direct membership to (spaces you actively participate in). If you click the All tab then you should see all spaces that you have access to, including spaces with inherited permissions.

So are you still not seeing it in the "All" tab?

joep.hendrix’s picture

Nope, user-1 is not a member of any space only to one space as a member of the group the space belongs to.

There is no "all" tab if you are not a member of at least one space.
After becoming a direct member of another space, the "all" tab appears.
But even then, the private spaces are not listed there.

mpotter’s picture

Title: UID 1 not seeing all spaces » Add Inherited tab to Spaces listing page
Category: Support request » Task
Status: Closed (works as designed) » Active

OK, this is related to this issue #2558393: Inherited Space members don't see any Space they belong to neither into "All Space" tab/Spaces page nor as Recent Spaces list. although that issue got sidetracked talking about the toolbar even though it also reported the issue with the All Spaces tab. There is also issue #2141373: Private inherited space does not show on space page; add the Inherited tab to the space listing where the task to add an Inherited tab to the All Spaces page is shown.

Since these issues all seem to get sidetracked with the toolbar, I'm going to change the title of this issue to reflect the lingering task that still hasn't been addressed, which is adding the Inherited tab to the spaces listing. But this is rather involved since that entire page needs to be replaced with a Views-based listing rather than all the custom code currently used.

Will push this up the list for the 2.50 feature release next month.

joep.hendrix’s picture

Great, thanks for your support.
Work around for now is to directly add members (not via group) to a private space in order to show up in the toolbar and the spaces page.