Hello all,
As ever, your here/now and future development plans for UserSpice are fantastic - many thanks to you and the whole team.
From a personal point of view, I'm especially keen on your 2 model approach, with the "stable" ("Standard"?) version being of particular interest to me - as stable user management and security are my key drivers - as is the simplicity of adding UserSpice to existing projects.
In regard to features;
1. Allow users to login via their usernames or email addresses - with the option of choosing which.
2. Allow users to login via their social media authentication details - facebook and twitter as a minimum.
3. Multi tenancy architecture - to allow multiple companies/users to reside in the same set of UserSpice database tables, will require companyid column or similar.
Thanks again for all your dedication
Jamie
Thanks so much for your feedback. I'm glad you're liking UserSpice. I feel that it is a really cool development tool and that we haven't even scratched the surface of what it can do.
For features.
1. Yes! Before the release of 4.1, I'm going to add in the ability to login with the admin's choice of username vs email. There was a debate about whether or not one of them was "more secure" but I think the admin's preference should win out.
2. I totally agree on the social media integration. The thing I've figured out in researching that is that most of the code to build those integrations is not designed for redistributed apps (like UserSpice). It's made for people adding something like OAUTH2 to their own project. So, lots of things like keys need to be set on the end installer's end to make the authentication stuff not freak out. As such, once we get 4.1 released as stable, I'd like to offer these things as plugins with good instructions. So, people who want these features can have them, but they won't get in the way for people who don't. We found out that lots of people misconfigured their reCaptcha and it actually became a barrier to people using UserSpice, so we turned it off by default.
3. I like the multi tenancy idea. I can see what it would take to do that for 4.1. The good news is that we hardly ever touch the db in our upgrade process and if we do, it's usually adding tables/columns, so you could feel pretty safe adding those columns manually. I'll think through that one.
Hi,
Many thanks for you reply.
Hopefully the choice will come down to the site admins on choice of username of email for authentication 
As you say, social media authentication is more complex in installation, so your plugin idea makes total sense to add the layer of complexity to only those who want it.
I'll wait to see if you are able to add the multi tenancy feature to v4.1, but working in the IT field, I'm fully aware of what scope creep can do to project timelines! ;-)
In regard to the release of version 4.1, will this be the Standard or Pro version?
Regards
Jamie
Databases/tables are cheap, so I'm wondering where the value of "multi-tenancy" comes from? Can you describe a use case to help me understand? Right now it would be quite easy to deploy multiple instances of UserSpice each with its own database.
Hi Brian,
Yes, totally agree, Database/tables are cheap - although time less so - so my “multi-tenancy” was a suggested enhancement, as will would allow anyone developing and hosting solutions to potentially only have to install and maintain/patch one installation of Userspice, instead of several or more. That said, with the separation of Userspice into Standard and Pro version, required patches will be less frequent in your Standard version.
My suggestion came from the system I'm developing (utilising UserSpice) as my original thought was to have a separate application (and Userspice) database for each client installation (which definitely has advantages in total data separation etc) but could see the advantage of having one application database in terms of deploying application fixes, patches, enhancements and new releases across multiple installation etc.
As with any suggestion, one mans meat is another mans poison, so depends on if this would be of benefit to your general client base.
Regards
Jamie
JamJar, after reading your post I started thinking about a couple of ways it could be done, but as you alluded to, it could result in a major case of feature creep.
What email addresses would the different organizations be using? Would they be company emails or from a specific domain?
What about the content? Is the idea to have one login system, but depending on some user detail (email address, account flag, etc.) there would be a different menu or redirect or something of the sort?
Hi Brian,
Email addresses - specific to each companies, so from multiple domains.
So in regard to content, the redirect could be different for each domain?
Regards
Jamie
okay, would users need to have an valid email account on a previously known domain to allow registration then? How do you picture registration would be limited to certain users? Would you need a filter on the registration that ensures that only certain email domains can register? Since it would be for multiple customers, I would assume this would be on the Internet versus a local or wan inTRAnet...
Now that I think I'm understanding the use case a bit more, I can understand the value. Understanding all the conditions of implementation though would be key to keep the scope of work well defined.
Hi Brian,
Customers, could be multiple, external businesses - or as you say, local, wan inTRAnet etc
My idea would be something along the following lines, allowing users to register in userspice the same way as they do know, with a slight difference;
The domain name of each company is given a unique companyid; with every user registering/logging into that domain, being assigned that same companyid;
www.company1.co.uk companyid = 1
user1 : companyid = 1 userid = 1
user2 : companyid = 1 userid = 2
www.company2.co.uk companyid = 2
user1 : companyid = 2 userid = 1
user2 : companyid = 2 userid = 2
thanks
Jamie
Thanks. So would you see this as something a user selects during signup (like a dropdown for what group they are from) or should it be deduced from the user information already collected?
|
