kaw sample feature overview--license control and compliance v1

Kathleen Walsh SAMPLE OVERVIEW DOCUMENT

KAW SAMPLE Feature Overview--License Control and Compliance v1.docx of 12 Last Modified: 2-Aug-15 7:17 PM (Version: 164)

Company, LLC

Feature Overview:

License Control & Compliance

(trackid)

Review Version 1

(Last Modified: 2-Aug-15 7:17 PM) (Version: 159)

Revision History

Date Version Author Comments

150801 1 Kathleen First review



Table of Contents

Revision History ...................................................................................................................................................................... 1

Contacts .................................................................................................................................................................................. 3

Review Notes .......................................................................................................................................................................... 3

Outstanding Issues (2)............................................................................................................................................................. 3

Feature Details ........................................................................................................................................................................ 3

Summary ............................................................................................................................................................................. 3

Product Licensing ................................................................................................................................................................ 3

License Types .................................................................................................................................................................. 4

License Key .......................................................................................................................................................................... 4

Key Generator ................................................................................................................................................................. 4

Changing Licenses ........................................................................................................................................................... 4

System Startup .................................................................................................................................................................... 5

Login .................................................................................................................................................................................... 5

Exit Application / Logout ..................................................................................................................................................... 5

Licensing Email Notifications .............................................................................................................................................. 5

User Profiles and Management .......................................................................................................................................... 6

New User Properties ....................................................................................................................................................... 6

Other Inactive User Checks ............................................................................................................................................. 6

Licensing Checks .............................................................................................................................................................. 6

Inactive Flag and Role Assignments ................................................................................................................................ 7

Impacted Objects ................................................................................................................................................................ 7

Object Properties That Must be Current Active Users ................................................................................................... 7

Subscriptions and Email Notifications ................................................................................................................................ 8

Administrator License Page ................................................................................................................................................ 8

Analytics .............................................................................................................................................................................. 9

Installation and Upgrade ................................................................................................................................................... 10

Upgrade for This Release .............................................................................................................................................. 10

Future Upgrades ........................................................................................................................................................... 10

Appendix B: Future Features ................................................................................................................................................ 10

Appendix: Conventions ......................................................................................................................................................... 10



Contacts

Position/Responsibility Person

Business Analyst Kathleen Walsh

Product Manager John Smith

Review Notes

• Track Changes is used to indicate changes from previous review version.

• Screen shots in this document may only be visible in Page view mode, not Normal/Draft mode.

Outstanding Issues (2)

1. Upgrade if Named users exceeds Licensed value (see TBD under Upgrade).

2. Prevent direct DB updates which would violate license allowances (see TBD under User Profiles and

Management).

Feature Details

Company needs to audit customers and ensure they are in compliance with their licenses. To make this

easier, on both the Customers and Company, some features need to be added to the product.

SUMMARY

1. Changes to the User Profile allow better auditing of license types and Named vs. Concurrent licenses.

a. Users can now be Active or Inactive allowing customers to ‘turn off users’ without deleting them

completely so as not to consume Named seat licenses (also has other benefits for customers).

See the following for more details:

User Profiles and Management

Other Impacted Objects

Object Properties that must be Active Users

Subscription and Email Notifications

2. Enforcement of Named and Concurrent licenses through User Management and Login.

3. Real-time statistics on current system use.

4. Analytics on historical use of system and licenses.

5. Some related bugs and minor enhancement requests will also be dealt with as part of this feature; list

is in Track as children of Feature.

PRODUCT LICENSING

Product is licensed as follows:

• Administrator is not license-controlled

• Employee

◊ Concurrent



◊ Named

• Customer

◊ Concurrent

License Types

• Named Seats licensing controls the number of Users with a Role of the application’s type that can be

created. It also limits each user to logging in only once.

• Concurrent license controls the number of user sessions that can exist at the same time.

LICENSE KEY

In order to be able to decide if the system is in license-compliance, Product needs to store the customer's

license information (encrypted).

DESIGN NOTE: The design of licensing should account for possible expansion and change in the future. In

particular, we may add or change license types. My best guess as to a design element is the ability to re-

purpose parts of the key or include parts that are not currently used but are there for future use (e.g.,

extra characters or ‘bytes’).

• The key shall be unique for each customer and tied to a specific installation of the software/database.

For example, on installation, setup shall assign the system an ID that is used to generate the key.

• The key shall include the product(s) licensed and for each, the type and number of licenses.

Application License Type Number

Employee Concurrent Number of allowed users

Employee Named Number of allowed users

Customer Concurrent Number of allowed users

• The key shall be encrypted.

• The license key shall include an “apply by” date; if not applied to the system by that date, it is invalid

and a new key must be obtained.

Key Generator

• A single license generator tool shall be provided for internal use so that Services/Support can provide

all the license codes for customers.

◊ This tool shall be a self-contained executable that requires only the operating system (no other

pre-requisites).

• For security purposes, the License Generator shall be valid for 6 months. After 6 months, the

application will display an error that it has expired.

Important: This means Engineering will need to issue a new generator every 6 months; support must

have the new one before the old one expires.

Changing Licenses

• The license key may be changed at any time through Administrator. The system does not need to be

re-installed to increase or decrease available licenses.

• This function shall be available through the Administrator application and be controlled by a new

permission.



SYSTEM STARTUP

When system is started, the System shall verify there is a valid license key. If not, system shall log error

and email configured user. Administrator and command line utilities shall still function but the following

will not function:

◊ API

◊ Customer App

◊ Employee App

LOGIN

• For named licensing:

◊ Named users are allowed to log in multiple times from the same machine.

◊ If named licensing is in effect, when a user logs in, the system shall ensure they are not already

logged in on another machine.

◊ Once a user is successfully logged in, the System shall record the login date and time.

• For concurrent licensing:

◊ The system shall verify a license is available.

If a license is not available, the system shall display an error, log the issue, and send an email per

configuration. To, CC, BCC, Priority, Subject, and Message shall all be configurable.

◊ Once a user is successfully logged in:

∗ System shall record the login date and time.

∗ System shall decrement the number of available licenses.

EXIT APPLICATION / LOGOUT

If concurrent licensing is in use, when a user session ends, the system shall release all system resources

(including the license) held by the session(s).

A session may end when:

• User logs out.

• User exits application.

• Session times out.

LICENSING EMAIL NOTIFICATIONS

The system shall provide configuration and a session function that emails administrators when certain

license conditions occur.

1) New Configuration Manager settings for Licensing (new category):

a. Email addresses

b. Conditions under which email should be sent, such as:

i. concurrent users = max

ii. concurrent users = max – n

iii. concurrent users = max – n%



iv. named = max

v. named = max – n

vi. named = max – n%

2) System Startup: if license key is invalid, system sends email to configured users.

3) Login: if concurrent notification limit is reached or exceeded, system sends email to configured

users.

4) Save User: if named notification limit is reached or exceeded, system sends email to configured

users.

5) Daily: If at any time the number of searches per hour was exceeded, the system shall an email

with the details.

USER PROFILES AND MANAGEMENT

• These apply to all ways a User can be managed: Administrator, API, or transfer data.

New User Properties

• Active: Indicates if the user is Active or not.

◊ Inactive users are not allowed to login.

◊ Inactive users do not count against Named license limit.

• Last Login Date

The system shall store the user's last login date (optional; nulls allowed). (Note: This field will not be

filled in during upgrade. If a customer wishes to do this, they will need to create a custom utility to

pull the dates from the log files and populate the database themselves.)

• Customer License Type Concurrent or Named

If both Customer Named and Concurrent licenses are available (per license code), a new property of

the user shall be available for the Admin to assign one type to the User. Each user can be Named or

Concurrent, not both.

Other Inactive User Checks

• Inactive users are not allowed to be set for certain object properties. When an Inactive User is saved

the system shall verify that the user is not currently assigned to any of these. See Object Properties

That Must be Current Active Users for a list. (NOTE: This list is similar to checks when deleting a

user.)

Licensing Checks

If named licensing is in use, when a user is saved AND the user has at least one Role of Type = Employee:

• If this is a new Active user:

◊ System shall verify that an Employee Named license is available.

◊ If there is no available license, system displays error and lets admin edit User. (User can still be

saved as Inactive or with different Roles.)

• If the user was Inactive and is now Active, the System shall behave the same as above.

• If the user was Active and is now Inactive, the System shall reduce the number of Employee Named

licenses in use.

• If a user is deleted, the System shall reduce the number of Employee Named licenses in use.



• If all Roles of Type = Employee are removed from the User Profile, the System shall reduce the

number of Employee Named licenses in use.

Inactive Flag and Role Assignments

◊ TBA (Dev): we need a way to ensure that a customer does not make direct-db updates to change

users from inactive to active and by-pass licensing.

∗ One option is a stored procedure or utility that runs periodically to verify license; however, that

must also be tamper-proof. It cannot be tied only to system startup as our goal is to not have

them restart frequently.

∗ Is there some way to ‘code’ the record to know that it was updated by Product vs. direct-db

method? If the code is invalid, then the user is considered inactive.

∗ We have currently added a check in 2 places: Service start and User session creation upon login,

but are open to other (additional, instead of) suggestions.

∗ Other ideas?

IMPACTED OBJECTS

Several objects have properties that are required to be current system users.

• For a list of these objects and properties, please see Object Properties That Must be Current Active

Users.

• These conditions shall also be enforced for any method of updating the data: GUI, API, import/export,

and transfer data.

• For these object properties, the system shall not allow inactive users to be assigned. (Displayed lists

(excluding User Manager) shall not include any Inactive Users.)

• System shall check on Save/Submit of these objects that assigned users are valid and active. (These

objects save/submit functions currently have a check to make sure assigned users aren’t exist, we just

need to add “active” check.)

Object Properties That Must be Current Active Users

• These following object properties must be current, active system users:

◊ Customer Anonymous User Name

◊ Task Owner

◊ Groups

∗ Supervisor

∗ Owner

• Things that are not affected by user being made inactive:

◊ Analytics

◊ All objects:

∗ Creator

∗ Last Modified By

∗ Users in:

− History

− Notes



◊ Group Members

Not removing inactive users from groups allows for a user to be re-activated and the admin not to

have to go back and add them to the Groups.

This does mean it is possible for a Group to be assigned to something and all its users to be

inactive so no one can perform the function. We are not going to check or code for that scenario.

We will, however, include a warning in the documentation about it.

SUBSCRIPTIONS AND EMAIL NOTIFICATIONS

When a user is made inactive, their Subscriptions and Notification settings are not deleted; however,

emails are not sent to inactive users.

ADMINISTRATOR LICENSE PAGE

Access to this page shall be controlled by a new permission.

GUI: (to be updated with new desired fields)



• Displays License Key

◊ Allows it to be edited; access to this function shall be controlled by a new permission (separate

from the one required to access the page).

• Displays the number and type of licenses for each product

◊ Employee Named

∗ % Used

∗ Allowed

∗ Used

◊ Employee Concurrent

∗ Maximum in past <tbd time frame>

∗ Average over past <tbd time frame>

∗ Number of times users denied access in past <tbd time frame>

◊ Customer Concurrent

∗ Maximum Concurrent in past <tbd time frame>

∗ Average Concurrent over past <tbd time frame>

∗ Number of times users denied access in past <tbd time frame>

◊ Provides ability to view full list of users currently logged in

∗ Displays all the currently logged in users

∗ Provides filtering/searching

∗ Allows admin to kill session (useful if one has hung)

• Includes Email Notification Settings

◊ Send To, CC, and BCC fields

◊ Send conditions

∗ Concurrent users at maximum

∗ Concurrent users available below set number or percent of allowed

∗ Named users at maximum

∗ Named users available below set number or percent of allowed

ANALYTICS

• Quick Statistics

◊ % Named used

◊ Max % Employee concurrent used

◊ Max % customer concurrent used

◊ # Named users not logged in x months

• Track use of the system over time (line chart)

◊ X = months

◊ Y=

∗ Concurrent Customer users



∗ Employee sessions

INSTALLATION AND UPGRADE

Upgrade for This Release

• Existing users shall have the new properties set as follows:

◊ If user has at least one Employee role AND

∗ License Key allows Concurrent, License Type = Concurrent

∗ License Key does not allow Concurrent, License Type = Named

− TBD: Behavior for situation in which number of users exceeds allowed Named Licenses.

◊ Active = True

• New permissions shall be added.

Future Upgrades

• The license code does not need to be re-entered when the system is upgraded without changing

servers (e.g., applying a Service Pack or performing an in-place upgrade from one version to another).

Handling server changes and allowing multiple servers to exist at the same time will be a process call

and Product Management will work out with Services and Support how to handle the licensing of co-

existing systems.

Appendix A: Future Features

The following features are candidates for a future release. They are included here for information and to

ensure the design does not make implementing these later difficult.

• Cascade Replace/Delete considers Inactive Users

When a user is made inactive, they are not allowed to be used as certain things (e.g., Group Owner).

In the future, the system should allow the admin to 'cascade replace' the user if they are found to be

one of these.

• More flexible notification

◊ Other methods of notification (e.g., text message, IM)

Appendix: Conventions

• GUI Terminology

The GWT Style Guide contains more details; however, definitions also apply to non-GWT technology.

◊ Inline Page (or Page): An inline page is one that is in the framework of the main application

window.

◊ Non-Modal Screen (or Screen): A non-modal screen is separate from the main application window

page, but is still part of the application and is not opened in a new full browser or browser tab.

◊ Modal Dialog (or Dialog): A modal dialog is displayed on top of the current screen or page.

• GUI Elements (Labels, Fields and Functions):

All GUI Elements are not always included and enabled. The individual requirements indicate when a

specific element is include and enabled.

◊ Included: An element that is included is present on the screen.

∗ "Always included" means it is always present.



∗ "Included only if…" indicates conditions under which it is included. GUI tables may have

separate columns where the column itself is the condition (e.g., if the screen has different

modes (read-only; edit; manage)).

If the condition is not true, the element is not present.

◊ Enabled: A field that is enabled is available for the user to type into or select from; a function that

is enabled is available for the user to select. Labels are always read-only.

∗ "Always enabled": means the element is always enabled.

∗ "Enabled only if…" indicates the conditions under which the element is enabled. GUI tables may

have separate columns where the column itself is the condition (e.g., if the screen has different

modes (read-only; edit; manage)).

If a field or function is enabled only under certain conditions, it is disabled if those conditions

are not true.

∗ "Read-only": Used for fields that are present but always read-only (e.g., a screen label, create

date). In some cases, the values can be changed, but through a function, which is listed

separately with its own enabled/disabled conditions.

◊ In some cases, a field may be "blank"; this refers to the field value, not the field label. It is used in

cases where we want to include the label, but indicate that no value is assigned (for example, in

Product, a Object ID is not assigned until the document is saved, but we do not want to hide the

Object ID field itself—that is considered bad design for localization).

◊ How functions are implemented (buttons, links, menus) is part of GUI design and based on internal

and industry standards.

◊ Fields types (single-line text boxes, multi-line text boxes, radio buttons, DDL) are included in the

requirements.

• Formatting

◊ Angle brackets ( < > ) are used to indicate variables. The brackets and words inside the brackets

should be replaced with the appropriate variable value at runtime. For example:

Message: <property> cannot contain spaces

Example: Password cannot contain spaces.

◊ Italics: References to other documents and sections (or headings) are in italics.

◊ Strikeout: Struck out requirements or parts of requirements have been removed; the strikeout is

used to explicitly show that something that was implemented at one time needs to be removed.

Strikeout is used only for features and functionality that was implemented in a previous release or

sprint. It is not used during document reviews before implementation (track changes is used for

that purpose to indicate changes from one review version to another).

◊ Underline is used for:

∗ Requirement labels so they stand out in the text of the requirement.

∗ References to a specific requirement that include the label. For example: Functions per the

General Save requirement (KM-A1000) in the 1A-General and Shared PRD.

◊ Grey text enclosed in {} are notes for the document owner about similar requirements so when

changes are made they are made consistently.

• Highlighting

◊ The following highlight colors are used to indicate different types of requirements:

Color Purpose Reviewer Responsibility



Yellow New functionality for the release. Review and plan release based on these

requirements.

Light Blue Newly included or updated

requirements for existing

functionality.

Review and indicates any disagreement

about how functionality is described in

requirements vs. how you think it does or

should work.

No highlight Existing requirements; previously

included and reviewed.

None

◊ In addition, the following highlight colors may be used to indicate open questions or action items.

Color Purpose Reviewer Responsibility

Green Questions for reviewers to answer Answer!

Purple Author’s questions/to do list; goal is to NOT have

any of these when a document is posted for

review.

None

Grey Author’s notes for future changes, things to do

later (like enter bugs).

None

kaw sample feature overview--license control and compliance v1

Documents