No offense was taken, I just wanted to make sure you understood why we have the security module as an add-on versus an included feature.  Thanks for your comments.

Trent,

Yes, this answers my questions. Thanks. Again, meant no offense as to your decision not to include it but mainly needed know the price.

The "other" framework I refer to specifically is for Visual Foxpro and the initial subscription cost is about the same as Strataframe current pricing w/Security add-on. And although this VFP framework has a very good security implementation, the one you describe definitely sounds more robust. For instance, the ability to assign more than 1 role to a user, auditing, etc.



Thanks again,

Randy

Looks like the Volume 1 of the StrataTrain E-Reference will be available on or around the release date of 1.5.  However, the E-Reference is lagging slightly behind the product in certain areas.  For instance, it does not currently contain any information pertaining to the security module, but it does contain information on most of the advanced business object features that have been added since the initial product release.

Hi,

"The new release will be made available on September 22, 2006. "

Do you know, will the StrataTrain E-Reference 
(http://www.stratatrain.com/buyIt1.html) be ready when the next release of SF is made available and will it contain material for the new features, such as the security add-on?

Kari

ps. Any info on the E-Reference pricing...?

The Role-Based security add-on is $295 per developer.  As for being included in the framework by default, the answer is no.  First, we provide all of the events and hooks in the framework to allow you to implement your own security if you choose not to purchase the role-based security.  But the Role-Based security that we are about to release far exceeds anything that any other framework provides.  This is the most robust security engine that I have seen and it will also include auditing, which is another piece that is not provided by any framework (to my knowledge).  The security even comes, out-of-the-box, with multi-lingual support.  All labels, messages, etc. all already provided in several languages and it will continue to grow.  Additionally, you do not have to do anything other than specify the locale ID that you choose to use (which can be changed at run-time since it uses the standard StrataFrame localization engine.  We also provide all of the end-user dialogs, session locking, end-user documentation, and a number of other things.  This is more than a "band-aid" solution to security and comes with all of the bells and whistles and this is why this is an add-on, not just an inclusion.

Through this process, new products have been introduced in the Messaging and Localization that we give you with no additional fee which includes translation tools, client translation packaging and tracking, and more.

I hope this answers your questions.

How much will this addon cost? Also, not to sound cheap or anything, but shouldn't security be part of an application framework vs. an add-on? Other frameworks we use come with security out of the box. Of course, you're free to use or not use their security, modify it, use your own, etc., but at least it's there if you want it.

The new release will be made available on September 22, 2006.  The Security Add-on can be purchased that same day.

OK, doesn't sound like it should a big deal to do in code, especially if I can just add the security key to an unused property and iterate through the menu options after it's loaded.



Any new info on expected date of the next release?

Tying the security into the menu system is certainly a large enhancement request, however, if you subclass a ToolStripMenuItem (button, separator, label, etc.), you must also re-create the control designer(s) for the menu itself.  The problem is that the control designer for the menu has the ability to add the menu items to the control, and there is no way to extend the control designer to tell it to add an new instance of our subclassed menu item over the base menu item.  For now, you have to manually test the permissions in code and disable/enable or show/hide the menu items accordingly.

Looking forward to these enhancements as well.



One more request to add: Menus (ToolstripmenuItems) to be security aware. For instance, if a user doesn't have access to a specific "permission key" that key can be assigned to a menu item to disable or hide it at runtime. This way, the user has a clue they can't run something (or they just plain don't see it) rather than having to display a "access denied" message after they click the menu.