UserSpice Stable (Standard?) and UserSpice Pro

[JamJar]

Hi Brian,

Not sure why a dropdown select would be necessary, as by the user being on http://www.company1.co.uk domain indicates they are signing up to userspice for company1 and so on - or am I missing something?

thanks

Jamie

[mudmin]

That's a really interesting use case.

I don't know how many people would use it, but this is my take...

I don't mind "feature creep" as much as I mind "code creep." For instance, some of the "features" that allow people to turn things on and off require a ridiculous amount of code for a single switch. Some of that has been cleaned up and simplified (thanks to Brian) in 4.1.

If we can add a feature like that which doesn't add a lot of complication to the code, I'm definitely fine with it and it would stop us from breaking your stuff as we update. This weekend is going to be a little crazy for both Brian and I but we can definitely chat about this.

[JamJar]

Totally agree, the project I'm working on is driving me nuts in terms of the user interface as what appears as a simple click of a switch to the user, adds a lot of coding to us developers.

Multi tenancy is for scalability, but as you say, I'm not sure many people would use it, so totally understand your need to discuss it before you can make a decision. As with any decision, does the development effort justify the reward.

[uspicef4n]

Hi all,

First of all thanks for userspice. I am in the same shoes as JamJar. Looking into having a subadmin lets call it. One god account followed by multiple subadmins (company1 admin, company2 admin) that can create new users. All the users can see the same directory but the company1 admin can indicated different rights to different pages compared to the rights that company2 admin.

Thanks again, and will keep on reading the formums

[mudmin]

I would say that you can pretty safely add the extra column to each relevant table of the db called
"company id" and you won't break anything.

From there it should be pretty simple to copy the join form and modify that for your need to allow one user to create another.

[brian]

Sorry, I really dropped the ball on this one...not sure how I missed the activity after my last post.

@JamJar, sorry I missed your last post in particular. I was thinking you had a single website/URL where people would sign up with a certain company or something. What you would actually want is to have multiple front end websites, using a single UserSpice backend. Now I understand, and yes, dropdown not necessary in that scenario

I will think about that, because now I understand the value of it, and I understand the desired implementation.

@uspicef4n, Regarding the creation of users, do you mean like a bulk username creation? So the users wouldn't create their own account, rather they would be created on the backend?

[uspicef4n]

@mudmin I understand the table part of adding a companyid, the obstacle was when the god account only allows coAdmin1 to see 'page1' and 'page2' while allowing coAdmin2 to see 'page2 and 'page3'.

@brian I'm looking into allowing coAdmin1 to control the users in its own group lets call it 'company1' and coAdmin2 control the users of the 'company2'

here is the scenario:

godAdmin can:

• create new companies (groups)
  
• create new users, being the respective useradmins for each group
  
• can see all pages
  
• assign rights to pages by group
  

The useradmins for each group can:

• create/edit only users for the respective group
  
• edit what pages can be seen by each subuser from the allowed pages of the group
  

In othe words:
A super user can create different organizations. Each organization can have one or more admins. Those admins can create users or departments(groups inside the organization). The admin decides what pages can be seen by each user from the allowed pages from the super user. the admin cant see pages visible to other admins in other organizations.

too much?
Thanks again.

[mudmin]

That's where the relational part comes in.

Here's how I would tackle that part.
If you only need 1 godAdmin, you're already set. The user with the id of 1 can already view all pages regardless of what is setup in the database. Sneaky, I know.

The trick to all the stuff you're doing is at the sql queries at the top of the pages that fetch the "editable data." So, in other words, if each user has a companyID attached in the user table and a useradmin has the same companyID, then when you make your version of the "view all users" page, all you have to do is change the query from
$userQ = $db->query("SELECT * FROM users LEFT JOIN profiles ON users.id = user_id ");
to
$userQ = $db->query("SELECT * FROM users LEFT JOIN profiles ON users.id = user_id WHERE companyID = $user->data()->companyID");

Basically, because your companyID is coded into the user table related to that useradmin, any time you put "WHERE companyID = $user->data()->companyID" it is going to restrict that useradmin's access to only "their own" people/companies.

The same goes for creating a new user. The useradmin has their company id hard coded, so whenever you create a new user you would insert the company id of the admin in as the one of the newly created user.

Soooo, here's how I would tackle this problem.

The things that the godAdmin should be able to do should be controlled through the built in userspice functions. In other words, the only people who should be able to visit these broad reaching pages are the ones who have the access level of god-admin. They can even have a master list of company ids on the side so they can reference them when creating new groups/companies etc.

All of the useradmin stuff should be restricted by sql query (to the company id) AND by access level in userspice.

Does that make sense?

I look at this a lot like the Wordpress Multi site stuff. I know that there are people out there who want this and I'd love to roll out a version for it. In the mean time, I can definitely try to point you in the right direction. Hopefully you can share back how this stuff works for you.

[uspicef4n]

This looks great. You are right, basically WP. So it looks like basically I will have to recreate the following pages:

• login
  
• all admin
  
• join
  
• password
  
• user_settings
  

and keep the included US pages to control the whole thing. Should I wait for the 4.1.2 release for any mayor changes?

Thanks again.

[mudmin]

If you are primarily in the development stages, the 4.1.2 update won't break anything for you. It will mostly fix glitches that you probably didn't notice.

I'd feel pretty comfortable going forward with your development knowing that the patch will be really easy. You just unzip it in your root and you're done. Probably 10 files or so and all core system files that you won't be modifying anyway.