Clarification on "Concurrent CMS Users"

Hello,

I want to make sure I understand this correctly.

Is the following true if I have have a Small Business Edition?:

1) A single person can be logged into the actual Sitefinity software

2) There is no limit to the amount of people that can log into a secure site that is using Sitefinity as its framework.

Thanks,
John

I think I asked that in the webinar and that's how it sounded...from their answer.  Once they enter the backend it uses up a concurrent user....however it's worded HERE such that if a user logs into your site anywhere and they have admin access that uses up a concurrent license.

Hi Steve,

Limitations are set only for backend users that are logged in to the administration area of the CMS where you can create,edti update pages, content, users, permissions etc. There are no limitations to the public part of a secured ( not secured) website.

All the best,
Ivan Dimitrov
the Telerik team

I want to make sure I do not have to manage non-CMS secured users outside of the CMS. Can I still use the Sitefinity framework to manage the users that are not going to be using the backend and when those users login (they will not have permission to use the CMS part of the site) will they count toward concurrent users?

Thanks.

Yeah, that's what they mean John...it wouldn't make sense to price a CMS @ $8000 if only 10 people can be logged in...you can only have 10 people in the backend managing users at the same time though.  So you could have 200 users logged in with access to the backend, but it only knocks against the concurrent count if they ENTER the backend.

Thanks Steve...
I am just being too careful in my questions.....I started thinking...technically someone logged into the website is touching the CMS in a small way so I thought just maybe that would be a problem.

Hello John S.,

Just a small clarification, we restricting the concurrent users by a role. In other words, we are counting the concurrent users in the Backend role. These are only users that can have permission to access the administration.

Wait, so you mean if a user with the Backend Role is logged in anywhere on the site (not even IN the backend?)

If the above is the case, I'm floored...how could you ever use it for a private login required site and still build modules against it?

This seems like a shady area not clearly defined in current pricing schema, which makes me quite concerned.

Hello Bill, Steve,

Wait, so you mean if a user with the Backend Role is logged in anywhere on the site (not even IN the backend?)

If the above is the case, I'm floored...how could you ever use it for a private login required site and still build modules against it?

Hello Georgi ,

This post seems to contradicts what you say:

www.sitefinity.com/.../sitefinity-4-0-rc.aspx

An example of a problem, if you have 100 employees that all have permission to edit pages on a secured site then each of those employees will need two log ins or there will only be 5 people allowed on the actual website at one time.

John

Hey Georgi,
  Yeah, we're getting conflicting info on this...

It becomes a massive issue when you want to make a site in which people want to be logged in so they can have personal preferences.  Like take telerik.com for example.  I like to stay logged in so I get my favorite links bar at the top and I can know which threads I've read.  If I had edit rights... :) ...then you get one less editor while I'm browsing the forums with no plans to ever change a page.  Or like in our case locally, a totally internal system in which there is no other option but to log in. 

It's not the module building I mean, but creating a module who's editing\management is exposed in the backend.  The SDK in 4.0 is defiantly a godsend over 3.x, but if I make something available in the backend then it's only tweakable by that concurrent limit....like I can't have a submenu item for reports for them to generate or custom analytics.  Those would all have to be frontend controls in another sub-admin area right?

I would agree it makes sense to limit to /sitefinity if you're going the concurrent route, but not the entire system.

Here's another example:
- I create a module which on the front-end registered users can submit listings into the database.  On the backend in the administration, the secretary or the boss can go in and transfer them out or approve them.  In SBE with one concurrent backend user, that means only the boss OR the secretary can be in the system at any given time...unless there's a generic admin user, which means they log out of themselves, log in as admin user, change things, then re-log in as themselves.

Steve

Also, are we talking (assuming standard) 5 per SUBDOMAIN since each sub will have it's own DB and webroot?

Hello all,

We have updated the RC thread, but I am posting this here as well:

Any user belonging to the Backend Users role or to the Administrators role who authenticates within a Sitefinity 4.0 website is counted towards the concurrent user limitation. It doesn’t matter whether this backend or admin user authenticates by logging into the public facing website, backend administration area, or a third-party application using our RESTful Web Service APIs. That user is removed from the concurrent users count when he personally logs off, he is forcefully logged off by an administrator, or his session expires. The session expiration time can be controlled from the configuration settings of Sitefinity.

@Steve:
It becomes a massive issue when you want to make a site in which people want to be logged in so they can have personal preferences.  Like take telerik.com for example.

Hey Georgi,
  Well we use separate databases right now for the subdomains becasue we just either don't want cross-contamination.  Each research project shouldn't be able to see anything from another project.  So we've just made a new subdomain for each one.

Sorry I should also note that, yes that customers role works, I mean I wouldn't normally give a customer the Backend role...but Staff usually would all have it so they can change things.  I like the idea of sitefinity being the "System" to manage company data, even a small SBE project. 

Like with this Role system I can't even make a Front-end for my admins to manage the backend data with since the potentially might not even be ABLE to log in.

Steve

Georgi,

I didn't say they were all doing CMS changes at the same time....

...however, it is quite realistic for a Small Business, lets say 10 people, using the Standard version to all have the rights to change content. It is also very very realistic for all these people to be logged in to other non-CMS secured pages doing work that the site is actually built for. In this case with the Standard edition, only 5 could be working in their actual secured, non-CMS, portion of the site unless they all had two logins; 1 for CMS work, the other for normal work.

A bit off thread.....

I completely understand the reason telerik is retricting CMS users; however, it should not affect a standard workflow. People generally despise logging into anything and to ask them to lout and then log right back in to do something else seems counter intuative.

I am lucky enough to not have much of an issue with this situation at this point. I just really feel for the people that have sold people Unlimited CMS Users and then took that away on an upgrade. As I said, I do understand why you guys did this but I could have gotten myself in serious trouble with customers if I convinced them to drop a competitor for Sitefinity and then took this away. In most cases they probably don't need the extra CMS users but psychologically they will feel slighted and ripped off.


Thanks,
John

 

Hi Georgi,

Hello,

Thank you for your suggestions and opinions! We are having some discussions on the concurrent users limitation.
By the way, what do you think about the upcoming Browse and Edit feature and the concurrent users? Since this feature will basically allow people to modify any content, page through the front-end pages, these users should be counted as concurrent as well, even though they are not in the administration.

@Georgi

You asked for it.

It sounded like you would ask us, kind of what would you have rather

a) Browse and edit functionallity

b) Only Backend editing and only those users counting as concurrent users

Want to start a poll?

Want to bet on the outcome?

Markus

PS: I don't need the browse and edit feature at all. I have other things on my wish list way further up then this!

Browse and edit is indeed an interesting feature for some clients and quite handy sometimes. The latest version of Telligent Community has this type of feature as well and it can be quite useful for quick edits. As for a user with editing privileges using browse and edit I'd say they should count against the concurrent user limit as long as they're actively editing - switching into edit mode at least - but not when they're just browsing or using the site like any other user would.

"It's a bit like having some friends over to watch television, everyone "can" use the remote control, but only one person can actually use it at a time."

@Georgi  the above post is a PERFECT Analogy...only decriment either actively editing users, or users who toggle on that edit\browse feature :)  I would assume it would be similar to DNN where the page is in "edit mode" you get an edit bar across the top and see the content areas you have access to?...if that's the case I'd say I'd be fine with someone in THAT mode taking up a concurrent....we just need a standard user to be able to log into the website and do their work, and sometimes be able to edit a page.  But if the concurrent is taken up just by logging in you're pretty much boned into multiple logins or hacks.

@Markus No, that's not what they're saying...it's not an either or, they just have a couple scenarios they're trying to work out.  This is a feature we've been waiting and asking for, for well over a year.  It might not be important to you, but it's a very critical feature to a lot of us...we don't want some people to see the admin end (they break things)...in fact it's one of the top voted items on the UserVoice poll.

I just wanted to also weigh in on this discussion. I'm also very concerned with the impact of the concurrent user model 4.0 is introducing, if it makes no clear distinction between users logged, and users logged in and actually editing something.

Here is a perfect example of how the planned model may not work for a long-time client. We use Sitefinity for several internal and external sites. One of those sites is our organization's internal Intranet. We currently use the Sitefinity security model to allow people to accomplish two very different things:

1. Edit content
2. Access secure or limited-access areas of the Intranet

Now, we have some users who have access to (1) above, (2) above, and in many cases both (1) and (2). It is completely impractical in this case for users who have a CMS login for dual purposes, to have to log in and log out every time. They currently log in first thing, in order to have access to secure information while they browse. They may or may not have any intention of editing. If they are not editing, they should not count toward concurrent user limit. I can see why if they access the admin section, the CMS immediately begins counting them, but not while in the live site. Coming from a long-time web developer myself, I understand the complexity to manage this approach would be far higher in comparison to simply checking roles but it could be done. A product priced and marketed as an leading edge enterprise CMS, this feature needs to be more mature.

With the current model, Telerik is forcing us down one of three paths:

1. Expect staff who have dual use for CMS account to log in and out all of the time (impractical).
2. Assign staff one login for editing and one for access secure information (impractical, mickey mouse solution)
3. Manage public users accounts outside of CMS architecture (completely impractical and a waste of time)
4. Upgrade from $8000 version to $20000 version in order to avoid concurrent users

Again, I support the idea of concurrent user limits, but it has to be done correctly. Sitefinity 4 is being marketed as a professional, enterprise grade solution. The above issues should be a non-factor. Concurrent user detection should be based on actions, not on roles.

We have a team of about 30 CMS users manage our Intranet. We could very easily manage with 10 concurrent users, if it meant it was based on actions (actually being in the admin area editing something). Expecting agencies  to spend an extra $12000 because of simplistic user detection is not realistic or fair.

I've been developing with Sitefinity since v2.0 and am always impressed by the constant improvements as the product has evolved. V4.0 looks very promising, but I have to tell you I think Telerik really missed the mark with how concurrent users is being managed and implemented. It's going to hold a lot of long time clients back in my opinion unless done correctly.

@Kevin - well said. "I support the idea of concurrent user limits, but it has to be done correctly."

Thank you all for the valuable input and ideas!

There are cases where users have dual functions on a website - login to make content edits or simply authenticate to see a restricted page. For websites with such user requirements, it would be best to have two membership providers. One would be for users managing the website's content and the other provider would be for users who will authenticate onto the public facing website to view otherwise restricted content.

The login control on the public website can be implemented, so that it works only with the "public users" membership provider. Sitefinity users with dual function will need to have two different accounts in this case. Users won't need to do the thinking which account they should use, because they will know that the "front end" login control will let them login with one credentials and the "backend" login control will let them login with another credentials. 

If an organization has many users who manage the website and it is inconvenient for them to manage two accounts, then the best solution is to upgrade to the Sitefinity Enterprise Edition and take full advantage of its unlimited concurrent users.

It is a great suggestion to count concurrent users only when they are actually making edits or browsing the backend of the system. There is no question that it is possible to be done. There is nothing impossible when it comes to computer science. However, there is usually a trade off cost involved for everything. If we count the concurrent users as @Kevin suggested, this will have a great impact on the performance of Sitefinity. Not just the back end, but also the public facing part of the website. We would need to make a lot of checks on user's behavior. It is a question whether to make all Sitefinity websites very slow or to have users with dual function maintain two accounts, if they cannot afford the Enterprise Edition. If we can figure out how not to count users only when they are actually editing stuff without a trade off cost, then you can be sure that we will do it.

On the other hand, please, note that with one license for the Enterprise Edition, an organization can build both its website and intranet and still have unlimited users on both. The intranet can be a sub-domain such as http://intranet.mycompany.com. I don't know whether there is a better bargain on the market for a similar product for both a website and an intranet.

Browse and Edit will be available in the official Sitefinity 4.0 release. In Sitefinity 3.7 if a user is browsing a page that they want to quickly go and edit, the user can just add the following query string to the page url: "?cmspagemode=edit" and hit enter (e.g. www.website.com/services/promo.aspx?cmspagemode=edit). An alternative would be to use the control that @stormy mentioned.

Greetings,
Anton
the Telerik team

We would need to make a lot of checks on user's behavior. It is a question whether to make all Sitefinity websites very slow or to have users with dual function maintain two accounts, if they cannot afford the Enterprise Edition. If we can figure out how not to count users only when they are actually editing stuff without a trade off cost, then you can be sure that we will do it.

Maybe the solution would be to cut back on functionality instead of usability for the different versions.

For example

Professional Enterprise renamed to Professional Unlimited

SBE = 50 Pages
SE = 250 Pages
PE = 1000 Pages
PU = unlimited Pages

SBE = 1000 Items
SE  = 5000 items
PE = 20000 items
PU = unlimed items

SBE = 5 concurrent users
SE = 20 concurrent users
PE = 250 concurrent users
PU = unlimed concurrent users

SBE = Generic Content,  Lists,   Images & Documents,  Newsletters,
SE = Generic Content, News, Blogs, Lists, Polls,  Images & Documents, Events , Newsletters,
PE= Generic Content, News, Blogs, Lists, Polls, Forums , Images & Documents, Events , Newsletters, Wiki
PU =Generic Content, News, Blogs, Lists, Polls, Forums , Images & Documents, Events , Newsletters, Wiki

Or modulare solution (but I guess this is a bit late in the process :-)

I still think that big companies usually can afford the 20k without a problem. Its more the small fish that are hurting with the current concept/pricing.

Developer Productivity, Increased by 70% ??

Yes if you buy the Pro Enterprise - for all others you could end up with less costing more - wishing that 3.7 would be continued.

Markus

@Markus

I know it's just a suggestion, but that implementation is a step back (worse) from what we have now...

You're suggesting MORE limitations on SE and up....right now it's just concurrent users...who'd buy a $2000 CMS that has limits on the content that can be entered, or how many pages they can make with the trade off being 15 more backend editors.  You also certainly can't institute a content or page limit on an $8000 purchase...

@steve

who'd buy a $2000 CMS that has limits on the content.

=> all those who don't need more content. It's like asking someone who would by a SMART car with only 2 seat. Those who don't need more.

All I wanted to say is that to me all the limitations are very clinicle and kind of artificial. Telerik clearly stearing away from the small fish.

So instead of artificially cut back why not make the products really different (and adjust the prices :-))

To me it is clear that I would expect the same stuff from a 2000 USD 4.0 that I had in a 900 3.7 -> otherwise why would I switch again?

Its a Telerik business desition which I guess at the end we have to except.

Markus

@Markus

Hmmm, I would argue the current scenario is fairly good (assuming standard edition) for a small developer\company.  I mean it's clear they're going enterprise...but at least standard has ALMOST everything you'll need to get by (Except maybe load balancing).  I see what you mean about the restrictions being artificial...seems like the concurrency was tacked on as an extra thing to justify the price jumping.

@Anton

Could perhaps you consider maybe at least upping the concurrent users on the $8000 package just a bit to 15 or 20?  It's a $6000 jump from the previous edition and only adding 5 more users...

Would also like to see a shift in standard/Professional concurrent licensing, the CEO said there is little need for more than ten in an environment of 300 so why is there no movement on the ammount of concurrent users and the actual purpose these restrictions have been implemented for?

@steve

Don't worry. I don't think that Telerik can afford to take away more stuff after all the bashing they are already taking.

2k is not a problem for a developer but for many very small businesses. I got a lot of customers in the range from 1-3 persons. They simply can not afford 2k for the CMS alone and the SBE has some limitation (localization) which make it sub optimal for a country with 3 languages spoken and all 3 languages connectect by a 1,5 hours drive.

The problem to me as a developer is that SF might be working for clients who can afford 2k but not for the others. So I either need to have to CMS at hand (which is nearly impossible) or abandon SF.

To me all the big firms with own developers can fork out the 20k without a problem.

@Neil

I am positve that the shift will come. Just give them time.

Well the actuall purpose of restrictions should be clear to anyone, not?

Markus

Hello,
can you please  confirm that if I've a SBE I can't have my 5 editor users to access the backed concurrently even to the frontend? so I've to assign them a another front-end user?
Thanks

Hello Ilaria,

Currently this is how Sitefinity works indeed. Only 1 member of the Backend Users role can be logged in Sitefinity. We received quite a lot of feedback and are working on improving how the concurrent users limitation works. We will be addressing this in Q2.


Kind regards,
Grisha 'Greg' Karanikolov
the Telerik team

This means that we have to provide two users for the user that are also publisher........ Q2 will be more or less for the end f April or what?

Thanks

This means that we have to provide two users for the user that are also publisher........ Q2 will be more or less for the end f April or what?

Thanks

@Paolo

Q1 is in the week of April 4th planned. So don't expect Q2 any time soon after this. The best I would assume is July 2011 for a Q2 release.

Just my uneducated guess :-)

@Ilaria
http://www.sitefinity.com/purchase/license-comparison.aspx SBE only 1 concurrent user, as far as I know up to now.

Markus

@Markus

Have a look here

They'll be aligned with the other controls release schedule, so that should give an ETA on a release week

So Q2 2010 was July 14th...

@Steve

Thanks for backing up  my uneducated guess. Now its an educated guess :-)

Looking forward to the Q1 first

Markus

Hi Steve,



We have 4 employees trying to develop various templates in a single
machine locally(development environment), but we are unable to access
the URL or the admin control panel concurrently  though we have
purchased 5 user license. Can you shed some light on this?



Thanks,

Johnson