(R) Roadmap (R) eCommerce Pipeline Meeting Notes 2014-10-23 Monthly
Meeting Notes Release 1 - Sprint 3: Details Release 4 - Sprint 1:
Details Release 4 - Sprint 2: Details (R) eCommerce Project Introductionr
(R) Install Clarity eCommerce v4.X Installation Guide for Clarity
eCommerce v2.x (R) 1. Getting Started (R) Framework Source Control Setup
(R) 2. Creating the eCommerce Website Solution (R) 3. Creating eCommerce
Modules in DNN (R) 4. Creating the eCommerce Pages in DNN (R) 5.
Customizing eCommerce Modules (R) Clone (R) Fork (R) Syncing a Forked
Repository (R) Naming Conventions Videos Specification Clarity Ecommerce
Directives Installation Store Account Dashboard Navigation Account Order
Item History Account User Profile Associated Product List Best Seller
Catalog Checkout How to implement CEF Cart Tag in Storefronts Micro Cart
Pinterest Board Product Attribute Product Comparison Product Details
Ratings Shipping estimator User Dashboard User Password Reset Admin
Discounts Discount Detail Discount Management Browse Discounts Search
Discounts Users User Account Detail User Account Management Add Users
Browse Users Search Users (R) User Documentation Product Import
Spreadsheet Clarity Connect Service Providers (R) Ecommerce Development
Lifecycle & Processes (R) How To Submit a VSO Bug (R) Bug Prioritization
(R) CEF Website Quality Assurance Steps File Lists (R) Terms &
Definitions (R) Sprint Planning How-To Articles 2015-Q2 Documentation
Updates 01. Architecture (R4) Dependency Map What languages do we use?
What Technologies do we use? Where will data live? 02. Project
Development Standards (R4) Coding Standards How does CEF meet the
Architecture? Projects Outline 03. Application Lifecycle Management (R4)
Code Reviews Coding in Each Project 01. Clarity.Ecommerce 02.
Clarity.Ecommerce.DataModel 03. Clarity.Ecommerce.Models 04.
Clarity.Ecommerce.Workflows 05. Clarity.Ecommerce.Services 06.
Clarity.Ecommerce.UI In-line Code Documentation Summary Tags with
Atomineer Other Projects Continuous Integration (CI) (Video) Continuous
Integration Continuous Integration with TeamCity Continuous Integration
with VSO-TFS Development Lifecycle & Processes (Video) Development & QA
Cycles During a Project Quality Assurance (Video) What A Good QA Testing
Plan Should Include CEF Website QA Checklist Work with Git Source
Control (Video) Creating a New Project or New Feature Repository (Video)
Source Control & Version Control for CEF (Video) Source Control for New
Features or New Projects Checking Out Code Pulling a Commit Which
Requires Upgrade Instructions Work with Visual Studio Online (VSO)
(Video) Create a Bug as a Client (Video) Reporting a Bug as a Clarity
Team Member Bug Prioritization How To Submit a VSO Bug Scrum Sprint
Planning Writing Software Change Notifications (SCNs) 04. Functional
Design Document (FDD) (R4) 05. Road Map (R4) CEF Pipeline 06. Marketing
Documentation (R4) 07. User Documentation (R4) Price Calculations
Recent space activity Timothy Scott Heimsoth
Ratings updated Oct 21, 2015 • view change
Service Providers created Oct 14, 2015
James Gray
Where will data live? updated Oct 12, 2015 • view change
Installation updated Oct 12, 2015 • view change
Checking Out Code created Oct 09, 2015
Space contributors
(4 days ago)Timothy Scott Heimsoth (12 days ago)James Gray (53 days ago)Zach Waggoner (54 days ago)Chris Reddick
(61 days ago)Ken Beckstead ...
Contents 1 Roadmap 1.1 Contents 2 Definitions 3 Releases 4 E: Stabilize
Product 4.1 Sprint 1 – Baseline Product and turn off unstable features
4.2 Sprint 2 – Create testing and documentation 4.3 Sprint 3 – Bug fixes
and product clean-up 4.4 Sprint 4 - Stabilize Product while adding in
‘turned-off’ features 4.5 Sprint 5 – Initiate and define roadmap and
development process. 4.6 Sprint 6 – [Identified as an output from
Sprint 5] 4.7 ARCHIVE 4.8 Release 04.02 – Mar. 2 - Apr. 17 , 2015 nd th
4.9 Release 04.03 – Apr. 20 - Jun. 5 , 2015 th th 4.10 Release 04.04 –
Jun. 8 - Jul. 17 , 2015 (subject to change) th th 4.11 Release 04.05 –
Jul. 20 - Aug. 28 , 2015 (subject to change) th th 5 Archive/Completed
5.1 Release 04.01 – Nov. 24 – Mar. 1 , 2015 th st 6 Documents
Definitions Releases – Targeting for 3 sprints per release. Noting that
this isn’t set in stone but an objective from the team. If this will not
occur there will need to be a separate meeting with the CEF business
owners to review the adjustments necessary if this requirement isn’t
met. Format will be XX.XX for release numbers. Sprints – By definition
each sprint will have the objective of a demonstrable set of code that
is committed, tested and available on the demo site at the end of each
sprint. If this will not occur there will need to be a separate meeting
with the CEF business owners to review the adjustments necessary if this
requirement isn’t met. Product Requirements Document (PRD) – requires a
minimum of a sitemap (per function), design wireframe (ideally graphical
design), functional bullet list of requirements and use cases/user
stories for validation. Business owner (and designer) produced item(s).
Functional Specification (FS) – detailed architectural requirements and
plan for where code/logic will live and how it will be formatting/setup.
CEF architect or developer produced item(s).
Releases Project Breakdown E = Epic, , R = Requirement, T = Task, , F =
Feature D = Deliverable Q/C = Questions/Comments E: Stabilize Product
Sprint 1 – Baseline Product and turn off unstable features · F: Product
Demonstrable o R: Implement functional Demonstrable from master branch §
T: § D: We hold a 2 hour long Demo to review ALL functioning features at
length · C: Require Tim, Zach, Chris, Ron, James, Andy (observe), Dustin
for this meeting o R: While pushing demo site Document all process from
Branch to Release § D: Release Management Process for Demo site o R:
Remove all non-functional UI feature from Admin access (leave code but
comment out) § C: Add specific "TODO@Person" tags to these locations to
determine who is responsible for getting it working later, easier for
that person to find it in the code o R: Document all features that are
turned-off due to instability § D: Beginnings of new “Redo” Backlog List
§ C: Document projects where that feature is functional and could copy
code from o R: Create Upgrade Plan § D: Upgrade Instruction document o
R: Create Unit Testing for all storefront controls § D: 70% code
coverage for all storefront controls Sprint 2 – Create testing and
documentation · F: Solidify testing plans and core documentation o R:
Complete a round of Functional (Click Through) testing documenting each
test and screen § D: Use Cases and Test Cases Document § D: Functional
Design Document o R: Complete full QA (Code Review) of OOTB product § D:
Full QA Checklist § D: Technical Design Document · F: Log and record
Product Bugs o R: Add Existing Bugs to Sprint 3 Backlog § D: Identified
Bugs are entered in detail to Sprint 3 o R: Create Unit Testing for all
Admin controls and Sales Order and Product Workflows § D: Tools
identified and Unit Testing document created Sprint 3 – Bug fixes and
product clean-up · F: Product Bug Fixes o R: Fix Existing Bugs found in
Sprint 2 Backlog § D: Identified Bugs are entered in detail to Sprint 2
o R: Create Unit Testing for Workflows § D: Tools identified and Unit
Testing document created Sprint 4 - Stabilize Product while adding in
‘turned-off’ features · F: Adding back previously unstable features o R:
Using the Sprint 1 Redo Backlog list, take the non-functional UI that
was hidden and make each item visible as it becomes functional § D:
Added features are added to Functional and Technical Design Document v2
· F: QA Release Management Process 1. a. i. 1. 2. 3. 4. 5. ii. 1. iii.
ARCHIVE
Release 04.02 – Mar. 2 - Apr. 17 , 2015 nd th Admin All remaining
features built out from P4H Client project. Accounts Accounts Payable
Accounts Receivable Ratings and Reviews Account Management User Accounts
Sales Packing Slips Shipments Carrier Account Management Add shipping
providers prioritize based off client needs System Configuration screens
System collection management Finalize UI Designs Begin implementing the
new UI designs Testing and validation against these new features Connect
2. a. b. 3. a. b. c. d. i. ii. iii. iv. 4. a. b. c. d. 5. a. b. i. ii.
iii. iv. v. 6. a. 7. a. b. 8. a. 1. a. b. 2. a. 3. a. 4. a. b. i. ii.
iii. iv. 5. a. b. 6. a. b. c. d. 7. a. 8. a. i. ii. iii. iv. v. b. i.
ii. 9. a. Finalize AX integration Begin Belle (Informix) integration
Demo site Inventory and move functionality from existing demo site into
core PRD/FS validation and initial location of the sites Ensure updated
with latest release items and validated by business owners Chris and Ron
QA and validate Functional spec docs and use cases Test cases Template
discovery documentation Implementation manageable items Documentation
Evaluate readthedocs.org Development process Extensibility Core Client
admin functionality Features Multi-linqual/Multi-currency Extend feature
set and fully validate: Reviews Recommended and similar
products/categories Improved filtering management User dashboard
Tracking and analytics integration Functional design documentation
Update with items for current and next release SEO Prerender.io Core
integration to Google Analytics Unit testing coverage C# coverage only
– target of 20% coverage Release 04.03 – Apr. 20 - Jun. 5 , 2015 th th
Automation Web deploy for local -> dev -> qa -> stage ->
prod initially in place for demo site. Note that some steps can be
removed for the time being. Needs to be “push of a button” simple deploy
for web app and data Run initial validation against the sandbox/demo
sites Admin Stand-alone capability – this ties closely with the item
“SAAS research” below Configurations Pull configuration related items
into the database. Settings, variables, etc. Demo site Ensure updated
with latest release items and validated by business owners. Chris and
Ron QA and validate Functional spec docs and use cases Test cases
Template discovery documentation Implementation managable items
Documentation Ensure coding standards documented for each key area of
the platform coding Upgrade process fully documented (manual process for
this release) Features Shipping providers Payment providers Tax
providers Customs/Duties providers (international) Functional design
documentation Update with items for current and next release Integration
Clarity Connect definition and restructuring Microsoft Dynamics GP
connector Netsuite connector SAGE connector Oracle connector SAP
connector Configuration and management screens Demo capability for an
integration Demo capability for API listing of the eComm and an
integration Refactoring 9. a. b. c. 10. a. b. c. 1. a. b. 2. a. 3. a. b.
c. d. 4. a. 5. a. 6. 7. a. b. c. 8. a. i. b. i. c. i. d. e. 9. 1. a. 2.
a. 3. a. b. c. i. ii. 1. a. b. c. 2. a. b. Architecture updates
completed merged and validated C# Refactoring Work Caching mechanism
Testing Unit testing to 50% coverage Initial Client Side Framework
testing in place with 5% coverage Begin running stress testing and load
testing – very initial runs Release 04.04 – Jun. 8 - Jul. 17 , 2015
(subject to change) th th Connect CRM Prioritzation based on marketing
research (validate market size) Demo site Ensure updated with latest
release items and validated by business owners Documentation Developer
documentation – how to use the platform – modules, client side layer,
C# customization, etc System documentation and diagrams – where things
go and how they work. Best practices for integration and data
migration/storage for standard entities Help documentation – embedding
within the admin UI Demos/how-tos Functional design documentation Update
with items for current and next release Licensing and access control
Ability to control access to functionality that’s in place via licensing
controls (instead of via physical file changes) Maintenance Reporting/BI
Advanced reporting Advanced notifications and event based integration
points Improved UI for building and customizing event based BI and
advanced reporting Research SAAS research Enable initial demos with
capability for different domains for API/Service layer vs.
implementation layer and validate. Likely will require adjustment to
CORS or JSONP “Automated” upgrade Initial updates to upgrade process to
enable upgrade in under 30 minutes following standard steps between
releases 04.02 and 04.03 and further releases (i.e. this is an example
of two different releases) Storefront Stand-alone capability – this ties
closely with the item “SAAS research” below Begin proactively
researching for ways to build developer community Plan for/attend
development conference(s) Security Audit Release 04.05 – Jul. 20 - Aug.
28 , 2015 (subject to change) th th Demo site Ensure updated with latest
release items and validated by business owners Functional design
documentation Update with items for current and next release SAAS
implementation More mature implementation Validation and demos in place
Scalable model Possibly a "free" model if they use our payment processor
and up to X transactions Further cost buckets beyond that - etc.
Archive/Completed Release 04.01 – Nov. 24 – Mar. 1 , 2015 th st Demo
site Inventory and move functionality from existing demo site into core
PRD/FS validation and initial location of the sites Ensure updated with
latest release items and validated by business owners Architecture
updates completed merged and validated C# Refactoring 2. b. 3. a. 4. a.
b. c. 5. a. b. c. i. 6. a. 7. a. b. c. d. 8. a. JS updates: type script,
require Unit testing coverage C# coverage only – target of 20% coverage
Documentation Development process Extensibility Core Client admin
functionality Connect POC research and functional build Document
architecture Specific integration Microsoft AX Admin Mockups for new UI
SEO Prerender.io Friendly URLs for all default instances Per category
and product titles Core integration to Google Analytics Functional
design documentation Update with items for current and next release
Documents eCommerce Roadmap Review_2014_11_15.docx
eCommerce Pipeline Immediate Bottleneck Items Date Feature Hours (est.)
Client Category Notes 2015-05-02 AX MEF 50 MOB Connect Broken into
phases 1. Push data from AX to CEF, 2. Push data from CEF to AX, 3.
Final validation 2015-05-02 Demo Site 80 ALL Storefront Work with Noah
and Zach to enable MOB, BELLE, and other storefront ready implementation
of core catalog functionality 2015-05-09 SEO 35 ALL Storefront Implement
urls, unique per cat, subcat, product meta data (title, description,
keywords, h1), auto-generated sitemap 2015-05-16 Cart, Checkout, User
Dash. 80 MOB Storefront Work with Noah and Zach to enable MOB storefront
ready implementation of cart, checkout and core user dashboard
Brainstorm Latest Version Mobile Tech Connect AX MEF Storefront
SEO/Prerender Belle Tire Connect Informix MEF (ish) Storefront Account
Management Claim an account during registration Quote Process Location
look up (Scheduler) - Subscription Model (length of time, max quantity,
range, etc.) Quote Processor (send to location, etc.) Catalog Category
Product Listing Product Detail Search/Search Results SEO/Prerender
Wizard Mobile Storefront Xamarin based storefront Catalog Cart/Quote
Atlas Connect NetSuite MEF Storefront Catalog Advanced search
capabilities Checkout Tax/Duties integration Shipping integration
Shipping configurator My Account / User Dashboard Store credit available
Notifications/UI messaging Invoice management Admin Account management
Store credit management Chacodog Storefront Checkout Shipping
integration Discounts/coupons Admin Discounts Product management screen
enhancements Clone a product Protec Storefront Admin Multi Tiered
Pricing Parts4Heating Admin Purchase Orders Shipping Dashboard Mayflower
Connect ABBAS MEF Storefront Mega-menu 7. b. ii. iii. c. 8. a. i. b. i.
ii. iii. iv. c. i. ii. 9. a. b. i. ii. c. 1. a. b. c. i. d. i. e. i. f.
i. 2. a. i. b. i. ii. iii. c. i. ii. iii. iv. 3. a. i. b. 4. a. b. c. d.
i. ii. iii. e. i. ii. Customer specific pricing Volume based discounts
Admin United Methodist Communications Connect Dynamics GP MEF (eConnect
instead of Web Services used for Brick) Storefront Multi-store /
Different domain but same catalog and select categories/products per
store. Digital Products (Download) Coupons/discounts. Customer specific
pricing/volume discounts. Admin Digital Product Management TBD upon
project commencing A1 Graphics Connect Storefront Multi-store /
Different domain but same catalog and select categories/products per
store. Design tool (optional). Admin Older Version Footprint
Multiportal/store management (settings) Multilingual label management
Checkout Payment Processing / PayPal Search Advanced search directive
Checkout Process improvement (UI) - directive updated with validation,
other features in Foot Data mapping - template for our system and field
use age and mapping model Data model definition documentation Brick
Account Management Claim an account during registration (looks up
account in ERP and allows validation process specific to that project)
My Account / User Dashboard Quotes Orders Invoices Checkout
Multilocation shipping Multicontainer shipping Integration to Freight
shippers Tax table integration Panagrossi Checkout eCheck processing
code Review with James Gray for more items? Horsetrailers
Ratings/Reviews SEO Landing Pages Analytics/Tracking Functionality Admin
Attribute management updates? Review management? Account management
Notifications Search/other notifications/criteria Email template for
notifications
Create from Template Title Creator Modified 2014-10-23 Monthly Meeting
Notes Chris Reddick Nov 15, 2014
Date Oct 23, 2014 Attendees Andrew Hawes Noah Shipley Timothy Scott
Heimsoth Chris Reddick Goals Discuss entities that are missing in the
platform along - update/add inventory in Jira. Discuss underlying
business logic missing or needing more robust build out - update/add
inventory in Jira. Discuss processes hampering dev missing or needing
more robust build out - update/add inventory in Jira. Schedule next
instance of this meeting. This is intended as a confirm / sync on key
entities so we can drive forward with building them out along with key
business processes that need implementation to allow the current and
near term sprint items to open up. Discussion Items Time Item Who Notes
See attached for notes - eCommerce Monthly Review_2014_10_23.docx
Action Items Chris Reddick to post meeting notes. Concurrent Items Chris
Reddick to update attached doc with notes. Timothy Scott Heimsoth to
update attached doc with notes. Noah Shipley to update attached doc with
notes. Andrew Hawes to update attached doc with notes.
Sprint Overview This sprint is designed to be focuesd on completing and
polishing the sprint 2 items as well as develop new processes to insure
smoother sprint iterations in the future. Timeline (11/3 - 11/19) (11/3
Quality Code Coverage: Currently at ~%10 and targeting for %15 coverage
by completion of this sprint. Team Members Noah Shipley (70 hours total
Eric Adam (15 hours, out 11/11 - 11/16)
Darrin Ezell (8 hours) Chris Reddick (10 hours) Tasks
JIRA: http://pm.clarityclient.com:8080/secure/RapidBoard.jspa?rapidView=14&view=planning
Key Summary Type Created Updated Due Assignee Reporter Priority Status
Resolution Stake holder CEF-1 26 Create an automated deployment process
for the demo site Oct 08, 2014 Apr 23, 2015 Oct 31, 2014 Noah Shipley
Noah Shipley
Open
Unresolved CEF-1 53 Move less colors into constants Oct 14, 2014 Nov 20,
2014 Darrin Ezell Tim Heims oth
Closed
Fixed 2 issues Current Status and Pace . Chart by: AssigneeTotal: 2
Risks Framework improvements could impact feature development tasks Tim
and Eric are both out of the office during the sprint Footprint project
could impact some of the team members Retrospect Click here to review
the retrospect notes:
Sprint Overview This sprint is designed to be focuesd on final major
architectual improvements to the framework and demosite improvements.
Timeline (11/24 - 12/06) (11/24 - 12/4) Development period (12/5 - 12/6)
QA period (12/6) Merge back into Release Branch (12/8) Planning Period
(12/8) Retrospect Project Organization and Location Development Process
Documentation on the development process utilized for the ecommerce
platform can be found . here Source Control Project:
http://stash:7990/projects/CEF/repos/framework/browse Branch: Release4
Subbranches: Release4/{FeatureName} Tag: R4-S1 - Architectual
Improvements and demo site Database Server: SQLA Database:
_ClarityEcommerce_V2_5 DNN_CEF_v2_5 Documentation Location:
http://documentation.clarityecommerce.com/ Version: 1 Quality Code
Coverage: Currently at ~%10 and targeting for %15 coverage by completion
of this sprint. Team Members Noah Shipley (62 hours total - 50 hours for
core, 20 hours for support if needed) Andrew Hawes (20 hours) Timothy
Heimsoth (40 hours)
Eric Adam (10 hours)
Darrin Ezell (8 hours) Chris Reddick (10 hours) Tasks
JIRA: http://pm.clarityclient.com:8080/secure/RapidBoard.jspa?rapidView=14&view=planning
Key Summary Type Created Updated Due Assignee Reporter Priority Status
Resolution Stakeho lder CEF-12 6 Create an automated deployment process
for the demo site Oct 08, 2014 Nov 26, 2014 Oct 31, 2014 Noah Shipley
Noah Shipley
Open
Unresolved
CEF-15 3 Move less colors into constants Oct 14, 2014 Nov 20, 2014
Darrin Ezell
Tim Heimsoth
Closed
Fixed
2 issues Refresh
Current Status and Pace
Total: 2 . Chart by: Assignee
Risks Framework improvements could impact feature development tasks
Andrew is out of the office during the sprint Holiday Footprint project
could impact some of the team members Retrospect Click here to review
the retrospect notes: Release 4 - Sprint 2: Details Release 4 - Sprint
2: Details Sprint Overview This sprint is designed to be focuesd on
final major architectual improvements to the framework and demo site
improvements. Timeline (12/08 - 12/21) (12/8 - 12/17) Development period
(12/18 - 12/19) QA period (12/21) Merge back into Release Branch (12/19)
Planning Period (12/19) Retrospect Project Organization and Location
Development Process Documentation on the development process utilized
for the ecommerce platform can be found . here Source Control Project:
http://stash:7990/projects/CEF/repos/framework/browse Branch:
Release4_1 Subbranches: Release4_1/{FeatureName} Tag: R4-S2 -
Architectual Improvements and demo site Database Server: SQLA Database:
_ClarityEcommerce_V2_5 DNN_CEF_v2_5 Documentation Location:
http://documentation.clarityecommerce.com/ Version: 1 Quality Code
Coverage: Currently at ~%10 and targeting for %15 coverage by completion
of this sprint. Team Members Noah Shipley (62 hours total - 50 hours for
core, 20 hours for support if needed) Andrew Hawes (20 hours) Timothy
Heimsoth (50 hours total - 30 hours for core, 20 hours for support &
planning)
Eric Adam (10 hours)
Darrin Ezell (8 hours) Tasks
JIRA: http://pm.clarityclient.com:8080/secure/RapidBoard.jspa?rapidView=14&view=planning
Key Summary Type Created Updated Due Assignee Reporter Priority Status
Resolution Stakeholder CEF-12 6 Create an automated deployment process
for the demo site Oct 08, 2014 Nov 26, 2014 Oct 31, 2014 Noah Shipley
Noah Shipley
Open
Unresolved
CEF-15 3 Move less colors into constants Oct 14, 2014 Nov 20, 2014
Darrin Ezell
Tim Heimsoth
Closed
Fixed
2 issues Refresh
Current Status and Pace
Total: 2 . Chart by: Assignee
Risks Framework improvements could impact feature development tasks
Footprint project could impact some of the team members Retrospect Click
here to review the retrospect notes: (
(R) Install Clarity eCommerce v4.X Installation Guide for Clarity
eCommerce v2.x (R) 1. Getting Started (R) Framework Source Control Setup
(R) 2. Creating the eCommerce Website Solution (R) 3. Creating eCommerce
Modules in DNN (R) 4. Creating the eCommerce Pages in DNN (R) 5.
Customizing eCommerce Modules (R) Clone (R) Fork (R) Syncing a Forked
Repository (R) Naming Conventions About the Clarity eCommerce Project 1.
2. 3. 4. 5. 6. Embed your own or PowerPoint Presentation company video
app.episodic.com Quick Links Click on the red links below to create a
new page with that title Sprint Template
Installation Process
Announcements Add a and tag it with the label to have it appear in the
recently updated content list below blog post announcement Recently
Updated As you and your team create content this area will fill up and
display the latest updates.
This content has been migrated to > > Specification
Use this step by step process to setup source control and environment
for Clarity V2 eCommerce platform. Step-by-step Guide for Getting
Started With V2 Preconditions: You have a DNN website created &
installed properly You have valid credentials for Clarity's Stash
repository You have access to either DevB or DevA internal development
servers You have a baseline knowledge of the principles and anatomy of
AngularJS, ServiceStack, DNN, & an eCommerce storefront Create an SQL
Database from a copy of the latest Clarity eCommerce database on SQL-A
(_ClarityEcommerce_V2 currently) Create an SQL login for the newly
created database Using the instructions for making your own working copy
of the Framework repository at (R) 1. Getting Started Access IIS and
setup a virtual directory within the /DesktopModules folder of your
configured DNN website called 'Ecommerce' and point it to the
Clarity.Ecommerce.Services folder Convert this virtual folder to an
application by right-clicking it in IIS Within the
Clarity.Ecommerce.Service folder, adjust the connection string in the
web.config 6. 7. 8. 1. 2. 3. 4. 5. 6. 7. 8. 'ClarityEcommerceEntities'
to point to the eCommerce database you've just set up Go to the
Default.aspx page within the root of the DNN website aand add as an
ng-app="clarityEcommerce" attribute on the html element. At the bottom
of the default.aspx page, just before the closing
</body>
tag add at a minimum the following tags:
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Common/angular.min.js
<script src=' '>
</script>
http://cdn.clarityecommerce.com/Live/v2.1/ThirdParty/ngGrid/ng-grid-2.0.7.min.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/app.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Store/Product/Controllers/ProductCatalog.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Store/Product/Controllers/ProductDetail.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Store/Cart/Controllers/Cart.js
Now go ahead and check out the 'dnn modules' repository from the stash
project. Drop all of these modules the DesktopModules section of your
DNN website and begin adding them via Hosts->Extensions->Add New
Module Tips & Tricks Don't forget to build the framework solution once
you check it out to create the non-versioned files As you begin to
modify the code for the UI project - you will want to add another
virtual directory pointing at the /App folder of the
Clarity.Ecommerce.UI project and modify any of these tags to point
there. Any modifications to the Services, Workflows, and/or DataModel
will be available upon successful rebuild of the Framework solution.
Related articles (R) Install Clarity eCommerce v4.X (R) CEF Website
Quality Assurance Steps (R) How To Submit a VSO Bug CEF Website QA
Checklist How To Submit a VSO Bug Showing first 5 of 6 results Create a
SQL database from a copy of the latest Clarity Ecommerce database
schema. Create a SQL login for the newly created data, so that it may be
accessed from the DNN site. Obtain a copy of the latest Clarity
Ecommerce code base and place the files outside of the root of the DNN
site. Once the DNN site has been set up, access the IIS setting for the
site and create a virtual directory called Ecommerce as a sub folder of
the DesktopModules directory. Within the Ecommerce virtual directory
create another folder called API and point it to the
Clarity.Ecommerce.Services directory. Within the
Clarity.Ecommerce.Services folder, adjust the web.config
“ClarityEcommerceEntities” entry to point at the latest Ecommerce
database instance set up in step 1. With-in the DNN root directory edit
the default.aspx and add as an attribute to the html element.
ng-app="clarityEccommerce" At the bottom of the default.aspx page add at
a minimum the following tags:
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Common/angular.min.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/app.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Product/Controllers/ProductCatalog.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Product/Controllers/ProductDetail.js
<script src=" ">
</script>
http://cdn.clarityecommerce.com/Live/v2.1/Cart/Controllers/Cart.js
Once the following steps have been completed add DNN modules as
necessary for the implementation needs.
This content has been migrated to > > Specification Clarity
Ecommerce Directives Installation Determine what your site should be
called What is the name of the site/company?
______________________________ Will you
need eCommerce for this site?
__________________________________
Create Your Folder Structure Create a on either or in Project Directory
Development-A DevB C:\Data\Projects\[ProjectName] Create the
following folder structure in the Project Directory _Backups Dev Cef
Dnn Live Cef Dnn Get the Core Framework from Stash Go to Stash and log
in http://10.10.30.90:7990 Navigate to the repository (aka, trunk)
eCommerce Framework
http://10.10.30.90:7990/projects/CEF/repos/framework/browse Click, in
the upper-right (want to know the difference between and ?) Fork clone
fork Name the new repository (new feature|bug fix|client project) - [3
Letter Client Abbr -] name NF|BF|CP e.g.: or NF-User_Ratings
CP-SBI-Videos Click Fork Repository Select the drop-down and copy the
URL Clone Make sure a is installed Git Client For Windows:
http://msysgit.github.io/ Right-click in your folder structure and
select Dev Git Clone Paste the URL from your clipboard and select your
options Click (you will have to enter your stash password) Clone Prev:
eCommerce Development Home Next: (R) 2. Creating the eCommerce Website
Solution
Source Control & Version Control for the Clarity eCommerce Framework
This media has been moved to (Video) Source Control & Version Control
for CEF Creating a New Project or New Feature Repository This media has
been moved to (Video) Creating a New Project or New Feature Repository
This method has been retired and is no longer part of Clarity Best
Practices Create your Visual Studio Solution Place any other existing
website files into your folder structure You are most likely copying an
existing site Make sure you follow this structure when copying as older
sites may not follow the structure This structure allows better
interaction with and the solution directories Git Visual Studio Create a
new website in and point it at .\Dev\Web_v01_001 IIS The website
should be named www.[projectname]dev.us (or .info depending on what
the person purchasing the site was able to acquire) Make sure you have
write permissions enabled for the DNN folder and Network Services have
access to write to the folder Launch Visual Studio Click > and select
your directory Open An Existing Website... .\Dev\Web_v01_001 Add the
following projects from eCommerce to the solution: AuthorizeNet.Helpers
Authorize.NET Clarity.Ecommerce Clarity.Ecommerce.Data
Clarity.Ecommerce.DataModel Clarity.Ecommerce.Models
Clarity.Ecommerce.Services Clarity.Ecommerce.UI
Clarity.Ecommerce.WebService Clarity.Ecommerce.Workflow Move the folder
from the project into the directory StaticContent UI
.\Dev\Web_v01_001 (Note: With new folder structure this will not be
necessary) Save the solution file (.sln) in the folder as .\Dev
[ProjectName].sln Use a PowerShell Script to Manage Edited UI Files
Edit the PowerShell Script to point to the appropriate module folder
locations. You should now be able to build the UI project and with
cascading dependencies to compile everything you need to get started.
Prev: (R) 1. Getting Started Next: (R) 3. Creating eCommerce Modules in
DNN
This content has been retired and is no longer part of Clarity Best
Practices Logging in to DNN Open your new website in a browser Log in as
host or a superuser using the password information from PassPack Create
the Modules Category Go to > Admin Taxonomy Edit Module Categories
Click Add Term Enter Clarity Ecommerce Install the Extensions Go to >
Modules Get More Modules Click the tab Available Extensions Click Create
New Module Enter the following information From: Control Folder:
Ecommerce Code: X.ascx Name: X 4. e. 5. 6. 7. 1. 2. 3. 4. a. b. c. d. e.
f. g. h. i. j. k. l. m. n. 5. 6. a. b. c. d. e. f. g. h. 1. a. 2. a. b.
i. 1. Desc (optional): Add a description saying what this module does
Edit the new Module Assign the Category Clarity Ecommerce Repeat steps
3-6 for all modules eCommerce Prev: (R) 2. Creating the eCommerce
Website Solution Next: (R) 4. Creating the eCommerce Pages in DNN
This content has been retired and is no longer considered part of
Clarity Best Practices. Please see the Specifications section. Generate
the Pages for the Modules to Rest on Go to > Admin Page Management
Click and name it "Store" Add Page Go to Store Click (place one on each
line) Add Pages BreadCrumbs Cart CategorySearch Checkout CustomerDetails
CustomerFind FindProduct ImportSearch InventoryLocations
LimitedProductSearch ProductDetail ProductSearch PurchaseOrders Admin Go
to Admin Click (place one on each line) Add Pages Administrators
LimitedProductEntry ProductEntry Test UserEntry Users VendorEntry
Vendors Set Up Main Store Page Edit the (default HTML module on a page)
to what the page is called Header
<h1>
Some Store Page
</h1>
Go to > > > , title it "JS Injections" and click Modules Add
New Module All Categories Content Injection Add Module Go to the new JS
Injections pencil menu and select Add/Edit Injections Click Add
Injection Select the following options (where xxxxx is the name and yyy
is the three letter code of the project) 2. b. i. 1. 2. 3. 4. ii. c. i.
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.14/angu lar.min.js">
</script>
<script src="http://code.angularjs.org/1.2.14/angular-route.min.js">
</sc ript>
<script src="/js/xxxxx.variableutility.js">
</script>
<script src="/js/ngApp/xxxxx.ng.js">
</script>
Enabled: Checked Click Submit Click Add Injection Select the following
options (where yyy is the three letter code for the project) Injection
Name: ng-app top Inject Where: Top Content to Inject:
<div ng-app="yyyApp" ng-controller="AppCtrl">
Enabled: Checked Click Submit Click Add Injection Select the following
options Injection Name: ng-app bottom Inject Where: Bottom Content to
Inject:
</div>
Enabled: Checked Click Submit Go to > > , title it "Store
Navigation" and click Modules Add New Module HTML Add Module Go to the
new module's pencil menu and select Store Navigation Edit Content Switch
to and populate with the navigation links HTML Mode 3. b. 4. a. 1. 2. a.
3. 4. 5. a. b. 6. Navigation Module Code
<h2>
<a href="/Store">Store</a>
</h2>
<h2>
<a href="/Store/Admin/Administrators">Admin</a>
</h2>
Go to > > , title it "Store Main Page Content" and click Modules
Add New Module HTML Add Module Populate some basic information for the
store home page Set Up each Store Sub-Page Go to a sub-page Edit the
(default HTML module on a page) to what the page is called Header
<h1>
Store X Page
</h1>
Go to > , select > select and click (don't make a Modules Add
Existing Module Store JS Injections Pane: ContentPane Add Module copy)
Go to > , select > select and click (don't make a Modules Add
Existing Module Store Store Navigation Pane: OnePage3 Add Module copy)
Go to Modules > Add New Module, select the Module relevant to this
page select Pane: OnePage9 and click Add Module You may get a or similar
error, ignore this and move on TargetInvocationException Go to ./Store
for the root page if you can't use the sub-nav Repeat 1-5 for each
sub-page Prev: (R) 3. Creating eCommerce Modules in DNN Next: (R) 5.
Customizing eCommerce Modules
This content has been retired and is no longer considered part of
Clarity Best Practices. Please see the Specifications section. The
default modules from the platform are located in the
Clarity.Ecommerce.UI project under /Admin/. These are pushed into the
DNN website's \DesktopModules\Ecommerce\ folder overwriting any
changes each time the UI project is built. To avoid having your
customized implementations and templates overwritten, rename the base
default module with the client's three letter abbreviation. Any items
that are identified as new features should be built in the UI project.
Alternatively, you can disable this functionality in the CopyFiles
powershell script. Prev: (R) 4. Creating the eCommerce Pages in DNN
<future>
This content has been replicated to the new documentation section under
Work with Git Source Control Cloning is really the default behavior
you'd expect from SVN. This is how you'll create your local working
copy. You don't need permission via pull request to merge back (assuming
you have r+w to the parent repository). You should clone a repository if
you plan to push your changes back to the same repository where you have
read+write access privileges. You should also clone a repository if you
are building a new repository that is unique.
This content has been replicated to the new documentation section under
Work with Git Source Control If you want to contribute code enhancements
to an existing repository, you should create a new repository by
creating a fork of the original. For example, if you want to contribute
minor bug fixes, enhancements, or new features to another git project,
the easiest way for those changes to be merged into the original
repository is with a Pull Request from a forked repository. See Make a
Pull Request on GitHub. Fork Documentation from Atlassian Note: When you
fork a repository, all metadata associated with the repository such as
commit messages, branches, tags, etc. are copied over to the new
repository so that it's an exhaustive duplicate of the repository and
all of its contents.
This content has been retired and is no longer part of Clarity Best
Practices. Please see the Working with VSO and Working with Git sections
Error rendering macro 'multimedia' : null Here's a quick video on how to
setup fetching the latest updates from the Framework using a remote repo
pointer. The official name for this is syncing a forked repository. Big
ups to for helping sort this out!
This content has been replicated to the new documentation section under
Coding Standards Clarity eCommerce Framework Abbreviation: CEF Name in
Code: ClarityEcommerce [] - Brackets indicate project or scenario
specific name Scenario Format Example Notes Database Name
_CEF_[PROJECT] _CEF_BIO, _CEF_PFH Version maintained in table
System.Info Folder DNN \DesktopModules\ClarityEcomm erce
Angular Directives cef-[directive] cef-shopping-cart Namespaces
Clarity.Ecommerce Project Implementation Folder [PROJECT_CODE]_CEF
BIO_CEF As in C:\Data\Projects\BIO_CEF Visual Studio Solution
Folder Clarity.Ecommerce.[Component] Clarity.Ecommerce.Services
Framework folder ClarityEcommerce Marketing space Clarity eCommerce
Framework SQL User Names CEF_User CEF_User If a specific user is
needed other wise use the standard user HTML IDs cef[Id] cefCart Use
camelCase DNN Admin Skin Name ClarityEcommerceAdmin
Clarity eCommerce Training Video
CEF Installation for V2 - Shows installation from scratch with debugging steps for remnant DLLs - runtime ~1 hour. Best viewed in Windows Media Player. (Note: This video was recorded late in the evening during after hours - please do not watch the video if after hours comments might be offensive) CEF Admin Overview - Shows a walk through of the ecommerce administration tool.
CEF Specification Includes the specifications for CEF's UI and
functionality. Pages: Clarity Ecommerce Directives Installation Store
Account Dashboard Navigation Account Order Item History Account User
Profile Associated Product List Best Seller Catalog Checkout How to
implement CEF Cart Tag in Storefronts Micro Cart Pinterest Board Product
Attribute Product Comparison Product Details Ratings Shipping estimator
User Dashboard User Password Reset Admin Discounts Discount Detail
Discount Management Browse Discounts Search Discounts Users User Account
Detail User Account Management Add Users Browse Users 1. a. b. c. d. e.
Search Users (R) User Documentation Product Import Spreadsheet Clarity
Connect Service Providers
Most of the storefront directives have the ability to either transclude
or include a template. To include a template, do:
<cef-directive template="path/to/template.html"></cef-directive> The
template path is relative to the project root. Alternatively, you can
transclude the template: <cef-directive transclude>
Hello, Clarity Ventures.
</cef-directive> If you specify neither a template nor transclude, the
directive will use a default template. It's also possible to bind
stylesheets to directives. Do this by adding 'css-bind':
<cef-directive css-bind="path/to/stylesheet.css"></cef-directive> The
css path is also relative to the project root. Some directives also come
with a default stylesheet. Use it by adding 'default-css':
<cef-directive default-css><cef-directive> If you are a directive, you
can integrate these features as follows: writing To make the template
customizable, use the following template:
cefApp.directive("cefDirective",(cef: ClarityEcomApi) => { return {\
restrict: "EA", transclude: true, scope: true, template:\
Utility.customizableTemplate(), link: (scope: ng.IScope, $element:
ng.IAugmentedJQuery, attr: ng.IAttributes) => {\
Utility.customizeTemplate(scope, $attr, cef.directiveUrl("path/to",\
"defaultTemplate.html")); } } }); Note that scope is set to true (this\
creates a child scope that prototypically inherits from the parent\
scope). If you don't do this, the directives will share the same\
template customization object. This will also work with an isolate scope\
(setting the scope to an object). Also note that the third argument to\
Utility.customizeTemplate is just a string (cef.directiveUrl returns a
path relative to the store directory). Now users can use your default
template, or override it with a template or a transclude. To add a
default stylesheet, use the following template:
cefApp.directive("cefDirective",($cef: ClarityEcomApi, $css: ng.css)
=> { return { restrict: "EA", template: '
Hello, Clarity Ventures.
', link: ($scope: ng.IScope, $element: ng.IAugmentedJQuery, attr:\
ng.IAttributes) => { Utility.styleDirective(scope, $attr, css,\
cef.directiveUrl("path/to", "defaultStylesheet.css")); } } }); Now
users can opt in to use your stylesheet by adding 'default-css'.
css-bind is its own directive and is automatically available everywhere.
Standup Environment & DNN Website PRO – Three or four Letter Project
Abbreviation ENV – folder name for environment you're creating (dev,
stage, live, etc) Create Staging (Dev-B) & Local project Folders
[Drive]:\Data\Projects\ _Archives PRO [Drive]:\Data\Projects\
\Framework PRO\ENV [Drive]:\Data\Projects\ \ClarityConnect
PRO\ENV - If required [Drive]:\Data\Projects\ \Data PRO\ENV 1.
e. 2. 3. 4. a. b. i. 5. a. i. ii. b. i. ii. 6. a. b. c. 7. 8. a. 9. 10.
<script defer="defer" src="/DesktopModules/ClarityEcommerce/UI/lib/cef/framework/cef-dnn.js">
</script>
Open the Website Solution file in Visual Studio if you haven't already
Start putting the UI tags in See the excel file for UI reference schema,
there are also Wiki pages for tags under Store in the left nav menu of
this page. For DNN Sites, entering the custom tags into the HTML module
can be tricky as by default the editor will strip any HTML or JavaScript
that it doesn't recognize or approve of. This is a safety feature of the
RadEditor (the WYSIWYG) control. To get around this, perform the
following steps: Log in as host Go to > in the Host HTML Editor
Manager DNN Admin Bar Click Default Configuration 4. 5. 6. 7. 8. 9. 10.
11. 12. 13. 1. 2. a. b. c. d. e. f. 3. 4. 5. 6. 7. a. b. c. d. e. Scroll
to the bottom and click the button Copy Choose from the area
Administrators Bind to Roles Check Bind to Website Click the button
Create In your new profile, uncheck all the Administrator (Current
Portal only) Content Filters Click the button Update Go to your instance
on a page and click HTML Module Edit Content Switch to mode and put in
HTML
<div cef-cart>
</div>
Click and then again and observe the only change made was it added to
our custom tag (which doesn't break it) Design HTML ="" Save your
changes and observe the module actually shows up on the page My Cart
From here, you can continue with additional tag settings like template,
etc.
Setup Notes The eCommerce framework requires a few dependencies to be
set up prior to utilizing the directives available in the storefront
library. They are documented in the section. In addition to this, there
are two actions that need to be taken for Storefront pages, see below
for the Installation details. Include Script
This step prior to utilizing the storefront controls is to include the script below on every skin file. This loads the core CEF directives, and any other dependencies such as Angular, so that the Tags can properly function.
<script defer="defer" src="/DesktopModules/ClarityEcommerce/UI/lib/cef/framework/cef-dnn.js">
</script>
Angular Routing Requirement change for DNN websites In a DNN website,
there is an additional change that must be made for pages containing CEF
Tags, especially Cart, Checkout, Catalog and Product Details (others yet
to be confirmed as of 2015/09/11). Log in as Host (or another Super
User) Go to the appropriate page: /Cart /My-Cart /Catalog /Products
/Product-Detail etc. On this page, go to the menu in the upper right and
choose (you do not need to activate Edit Mode) Edit Page Settings In the
first tab of the settings dialog, check Do Not Redirect Switch the tab
(should be the final tab) Advanced Settings Scroll down until you see a
large text box called Page Header Tags Enter the following content to
this box: <base href="/Cart/"> Where is the url to page (from #2 above)
Cart this You need to add a closing tag such as </base> or make it self
closing with /> do not You need to ensure that you have a on each end
of the page url in the base tag, having only 1 will break this process
do / You do need to ensure that no page is a sub of another page that
also has this type of base tag. For instance, do not have /Products be
the catalog page with /Products/Product-Detail beneath it.
/Product-Detail should not be a child of /Products or it will break this
process With the above steps performed for each page with a CEF control
on it, you should be good to go. If this is not working, please contact
Zach or Timothy Scott Heimsoth or James Gray for Assistance
NA ?
NA ?
NA ?
Description The associated product list directive is intended to provide
a user with a list of the associated products of the product currently
being viewed. This directive is driven off the product SEO URL path.
Attributes Association-Type Usage:
<cef-associated-products ></cef-associated-products>
association-type="'Related Products'" Values: The values for the
association type are drivent by the product association types that are
defined in the system. These have the potential to be defined per
implementation. Sample Code Sample 1: Definition Implements the default
associated product list Code
<cef-associated-products></cef-associated-products> Result Sample 2:
Definition Implements the associated product list with a specific
collection type Code
<cef-associated-products association-type="'Related Products'">
</cef-associated-products>
Description The best sellers directive provides a view for all the
products that have been identified as best sellers by the system. Sample
Code Sample 1: Definition Implements the default product best sellers
Code <cef-product-best-sellers></cef-product-best-sellers> Result
The $catalog angular service contains Control objects, each of which
specifies one piece of the search DTO and has a corresponding directive.
By default, the catalog contains a ViewSelector, Sorter, Paginator,
PriceFilter, and SearchTermFilter. The ViewSelector does not contribute
to the search DTO, but it does allow the user to control which template
is used to display the results. The Sorter is a composite control
containing an OrderControl and an AscendingControl, which respectively
specifies how to sort the results and in what direction. The Paginator
is composite control containing a PageControl and a PageSizeControl,
which specifies respectively the current page and the number of items to
show per page. The PriceFilter filters the results based on a list of
price ranges. The SearchTermFilter filters the results based on a
string. In addition, there are 2 composite controls which initially are
empty, but to which you can add arbitrarily many controls of the same
kind by including directives. In CompositeControl<CategoryFilter> you
can add Controls which filter the results based on a category. In
CompositeControl<AttributeFilter> you can add Controls which filter the
results based on an attribute value. All configuration takes place in
the HTML. This is an example:
<section cef-product-catalog>
<div cef-product-view-selector>
</div>
<div cef-product-sorter choices="Price, Name" default-value=“Name”>
</div>
<div cef-product-paginator num-choices="5">
</div>
<div cef-product-price-filter>
</div>
<div cef-product-search-term-filter>
</div>
<div cef-product-category-filter primary>
</div>
<div cef-product-category-filter type=“CategoryTypeName1”>
</div>
<div cef-product-category-filter type=“CategoryTypeName2”>
</div>
<div cef-product-attribute-filter name=“GeneralAttributeName1”>
</div>
<div cef-product-attribute-filter name=“GeneralAttributeName2”>
</div>
<div cef-product-results animate animate-cascade="0.15">
<div cef-product-results-view searching>
</div>
<div cef-product-results-view no-results>
</div>
<div cef-product-results-view view="Grid" page-size-choices="9, 18, 27" template=“path/to/grid.html”>
</div>
<div cef-product-results-view view="List" page-size-choices="10, 20, 30" default-page-size=“20” template="path/to/list.html">
</div>
</div>
</section>
cef-product-catalog must be present. It just adds the $catalog to the
scope and attaches a style sheet. cef-product-view-selector presents a
range of views depending on what is specified inside the
cef-product-results directive. When the user changes the view, it
updates any controls that might depend on the view (such as the
PageSizeControl) and does a new search, using the corresponding template
to display the results. cef-product-sorter presents the OrderControl and
AscendingControl to the user. The choices attribute specifies the
possible values for the OrderControl. By default, the one initially
selected is the first choice. If you want, you can add the default-value
attribute to change that. Right now the catalog can only sort by Price
and Name. cef-product-paginator presents the PageControl and
PageSizeControl to the user. The num-choices attribute specifies how
many options to show the user for the PageControl. If the current page
is 5, and the num-choices attribute is 3, then the choices will be “4,
5, 6.” cef-product-price-filter presents a list of price ranges. These
ranges are generated automatically based on the current search.
cef-product-search-term-filter presents a textbox containing the string
to filter the results by. cef-product-category-filter presents a 2-level
tree view of categories. If the type attribute is present, it will only
present categories of that type. Each CategoryFilter contains optionally
1 selected category and 1 selected subcategory. This directive actually
instantiates a CategoryFilter and adds it to the catalog. However, if
you have 2 of these directives that have the same type attribute, it
will grab the one that already exists rather than making a new one. That
way it does’t keep creating new ones when you navigate back to the page,
and you can display the same control in multiple places on the page. If
you have more than 1 CategoryFilter, the results will be only the
products which satisfy both filters. If 'primary' is present, then that
filter will show in the main part of the URL, rather than as a query
parameter. Only one category filter may be primary.
cef-product-attribute-filter presents a list of attribute values. These
values are found automatically by looking at the products that are in
the current search (disregarding this specific filter, and disregarding
the pagination). This directive also instantiates a new AttributeFilter.
For the same reason, if you specify 2 of these directives with the same
name attribute, then it will grab the one that already exists instead.
cef-product-results must be the parent of any cef-product-results-view
directives. On this you can add the animate attribute to have the
results animate in and out, and the animate-cascade to specify the
offset of the animation of each item from the one before it in seconds.
cef-product-results-view specifies a particular way to view the results.
If you have the searching attribute, then that template will be
displayed while the catalog is retrieving the results. If you have the
no-results attribute, then that template will be displayed when there
are no results. If you have view attribute and give it a value, then
that specifies the template for a specific view, and the
cef-product-view-selector will display it as an option. On each view,
you can specify a page-size-choices attribute, which will be the choices
displayed by the PageSizeControl when the corresponding view is active.
You can also specify the default-page-size, which will be selected
initially when you change views. If you don’t specify the
default-page-size, then the first choice will be selected initially.
What happens when you go to the catalog is this. First the link
functions of all the directives are executed, which configures the
catalog as described above. Then, routeParams) is
executed, which will set the values of the controls equal to the values
specified by the parameters in the URL. This mapping of controls to the
URL parameters is currently fixed. If the corresponding parameter is not
in the URL, then it will use its default value. After all the controls
are synchronized with the URL, catalog.search() is called. This gets\
the results, does the template management of the results, and it also\
gets back metadata for the controls. This metadata assigns a number to\
each option of each CategoryFilter, AttributeFilter, and PriceFilter,\
which represents the number of results under that option, but taking\
into account all of the other current filter values as well. When the\
user makes a change to a control, then the control calls\
catalog.update(), which first notifies all the other controls of the
change in case there are any dependencies (and this notification
cascades), and then calls $catalog.search() again if the search DTO has
changed.
Description The checkout directive is intended to complete the sales
transaction experience in an ecommerce site. Typically the checkout
process is initiated from the cart when a user has a few items in their
cart and clicks a checkout button when navigates them to a page with the
checkout directive implemented. The checkout directive is for the moment
limited on configurability, but by default it provides a 5 step process.
Step one determines what time of user is going through the checkout
process. If a user logs in we can retrieve some of the form data for the
rest of the process. If the user checks out as guest then the system
forcess them to fill out extra fields. Step 2 of the process gets the
shipping and billing address. If the user is checking out as guest it
also provides user login fields for the next time the user uses the
system. Step three determines the method of shipping and updates the
transaction total. Step for the payment processing portion of the
experience. Step five provides a confirmation of the order and typically
sends out a confirmation email to both the buyer and seller. Sample Code
Sample 1: Definition Implements the default checkout Code
<cef-checkout></cef-checkout> Result Step 1: Step 2: Step 3: Step 4:
Step 5:
Description The Cart directive is intended to provide a user defined
list of products to then take action upon later in the ecommerce
experience. The cart is a fairly versatile control. Tag HTML CEF Tag
<cef-cart type="Cart"></cef-cart>
<div cef-cart type="Cart">
</div>
Attributes Attribute Description Usage Possible Values Type Specifies
the type of cart to read. We use Cart Types for Wishlists, Watch Lists,
Favorites in addition to the standard Shopping Cart type="Favorites"
Cart (default) Favorites Wish List Request For Quote Bookmark Watch List
Request For Sample Template aka- Transclude The template property has no
default values. By default the cart directive will use the default
template the system provides. This property provides a way for the cart
to have a custom look and feel override the default system template.
template="/templates/MyCusto mTemplate.html The relative path to where
you are storing the project templates. Common Locations:
/Portals/_default/Skins/<Proje ct>/Ecommerce/cart.html
/DesktopModules/ClarityEco mmerce/Templates/cart.html
/templates/cart.html Sample Code Sample 1 Definition Implements the
default cart. Code <cef-cart></cef-cart> Result Sample 2 Definition
Implements the cart with a different of user defined product list. type
Code <cef-cart type="Wish List"></cef-cart> Result Sample 3 Definition
Implements the cart using a project specific template with it's own
styling. Code
<cef-cart template="/Portals/_default/Skins/Project/Ecommerce/cart.html" css-bind="/Portals/_default/Skins/Project/Ecommerce/cart.css"></cef-cart>
Result
Description The micro cart directive is intended to provide a user with
the minimum cart details. This directive is essentially a lite version
of the cart directive. Sample Code Sample 1: Definition Implements the
default micro cart Code <cef-micro-cart></cef-micro-cart> Result Sample
2: Definition Implements the micro cart with transcluded html markup
Code
<div cef-micro-cart>
<a ="/My-Cart" > href ng-cloak My Cart ()</a>
</div>
Description The pintrest board directive provides a way to provide a
view of a specific pentrest board. Sample Code Sample 1: Definition
Implements the default pintrest board view Code
<cef-pintrest-board></cef-pintrest-board>
The basic code block can be inserted to your Product Details template
NA ?
Description The product details directive loads the product information
into a template based on the SEO URL provided. Sample Code Sample 1:
Definition Implements a product details view Code
<cef-product-details role="main" ng-cloak>
<h1>
</h1>
<div class="col-md-12 clearfix">
<h4 ng-show="pdc.product.Price" class="productDetailsPrice">
</h4>
<h4 ng-hide="pdc.product.Price" class="productDetailsPrice">
</h4>
</div>
</cef-product-details> Result
Description The ratings directive is intended to provide a user rating
control for products and categories based off the ratings type name.
Sample Code Sample 1: Definition Implements the default ratings control.
Code <cef-rating scale="5"></cef-rating>
Description The shipping estimator directive ties into.the cart
directive. It provides a convenient way to estimate shipping of the
current cart items. Sample Code Sample 1: Definition Implements the cart
shipping estimator Code
<cef-cart-shipping-estimator></cef-cart-shipping-estimator> Result
cef-account-nav Add 'active="somePage"' to specify the current page
(which adds the class 'current' to the corresponding li). By default,
this can be accountDashboard, accountDetail, accountOrderHistory,
accountInvoiceHistory, accoundDownloadHistory, accountAddressBook, or
accountWishlist. You will have to override the template to add your own
URLs and specify your own nav items, and that is also where you specify
the available values for the 'active' attribute. Look in
Clarity.Ecommerce.UI/framework/store/userdashboard/accountNav.html for
the default template to see how to do this. Example:
<cef-account-nav active="accountOrderHistory"></cef-account-nav>
cef-order-history Add the attribute ’paginate’ to paginate the data. By
default, it will show 5 items per page. You can override this by adding
‘page-size=“x”’. You can also control how many choices are shown in the
paginator control by adding ‘page-choices=“x”’. By default, it will
retrieve the orders connected to the current user. To retrieve the
orders connected to the current account instead, add ‘type=“account”’.
This directive links to the order detail page. By default, it will
assume the URL is "/Order-Detail”. To override this, add
‘order-detail-url=“/Custom-URL”’. Example:
<cef-order-history paginate page-size="10" page-choices="7" type="account" order-detail-url="/Custom-URL"></cef-order-history>
cef-order-detail Pagination works the same way as cef-order-history. It
assumes that the order ID is the last part of the URL. Example:
<cef-order-detail paginate></cef-order-detail> cef-invoice-history Same
as cef-order-history, but it accepts ‘invoice-detail-url’. Example:
<cef-invoice-history paginate invoice-detail-url="/Custom-URL"></cef-invoice-history>
cef-invoice-detail Same as cef-order-detail. Example:
<cef-invoice-detail paginate></cef-invoice-detail> cef-download-history
Not yet implemented in the database, but the directive works the same
way as cef-order-history and cef-invoice-history, but it accepts
‘download-detail-url’. Example:
<cef-download-history paginate download-detail-url="/Custom-URL"></cef-download-history>
cef-address-book Pagination works the same way as the other directives.
Example: <cef-address-book paginate></cef-address-book> cef-user-profile
No attributes. Example: <cef-user-profile></cef-user-profile>
cef-password-reset <cef-password-reset></cef-password-reset>
Description The password reset directive provides a way for the current
user to reset their password. Sample Code Sample 1: Definition
Implements the default password reset template Code
<cef-password-reset></cef-password-reset> Result
CEF Admin Includes the specifications for the CEF Admin UI and
functionality. Pages: Discounts Discount Detail Discount Management
Browse Discounts Search Discounts Users User Account Detail User Account
Management Add Users Browse Users Search Users
Discounts Includes the specifications for the CEF Admin - Discounts UI
and functionality. Pages: Discount Detail Discount Management Browse
Discounts Search Discounts Preliminary Documentation
ClarityeCommerceDiscountsPromotionsGiftCertificates.docx
Goal Allow admin users to manage discount details including functions
like view, add, edit, delete.
User Stories Priority Title Must Have Stories 1 New Discount Admin user
must be able to enter the details for a new discount. 1 Load Discount
Admin user must be able to load the details for an existing discount. 1
Edit Details Admin user must be able to edit the details of a discount.
1 Save Discount Admin user must be able to save the details they have
added or updated on a discount. 1 Discount Code Management Admin user
must be able manage discount codes including functions like list, add,
edit, delete. 1 Discount Criteria Management Admin user must be able
manage discount criteria including functions like list, add, edit,
delete. 1. 2. 2 Preview Qualifying Products Admin user must be able to
preview a list of products that qualify for the discount.
Goal Allow admin users to manage discount including functions like list,
browse, search, add, edit, delete.
User Stories Priority Title Must Have Stories 1 Browse Discounts Admin
user must be able to browse a list of discounts. The admin user must at
least be able to see the following user data; Name, Value, Dates, Scope,
Code, and Criteria in the list. 1 Search for Discount Admin user must be
able to search for discounts by the following user data; Name and Code.
1 Filter Discounts on Active Status Admin user must be able to filter
the displayed list of discounts by Active Status (All, Active,
Inactive). 1 Add Discount Admin user must be able to initiate the
process of adding a new discount. 1 Edit Discount Admin user must be
able to initiate the process of editing a specific existing discount
from the list. 1 Disable/Enable Discount Admin user must be able to
initiate the process of deleting a specific existing discou from the
list.nt Browse Discounts User Story Description Admin user must be able
to browse a list of discounts. The admin user must at least be able to
see the following user data; Name, Value, Dates, Scope, Code, and
Criteria in the list. JIRA Issues Key Summary Type Created Updated Due
Assignee Reporter Priority Status Resolution CEF-83 Discount Admin Phase
1 Aug 13, 2014 Oct 31, 2014 Andrew Hawes
Resolved
Done CEF-42 Discount & Gift Cards Aug 04, 2014 Apr 23, 2015 Aug 07, 2014
Andrew Hawes Tim Heimsoth
Open
Unresolved 2 issues Mock-up Requirements Display discount list using
standard grid control. 2. 3. 1. 2. 3. Column Headings: Name, Value,
Dates, Scope, Code, Criteria, and Actions Data source: Table:
SalesDiscounts Implementation Notes FE Controller: ??? Template: ??? BE
API Endpoint: ???
Search Discounts User Story Description Admin user must be able to
search for discounts by the following user data; Name and Code. JIRA
Issues Key Summary Type Created Updated Due Assignee Reporter Priority
Status Resolution CEF-83 Discount Admin Phase 1 Aug 13, 2014 Oct 31,
2014 Andrew Hawes
Resolved
Done CEF-42 Discount & Gift Cards Aug 04, 2014 Apr 23, 2015 Aug 07, 2014
Andrew Hawes Tim Heimsoth
Open
Unresolved 2 issues Mock-up Requirements Enter a search term in a
textbox. User clicks a button to initiate search. Displayed discounts
are filtered by the entered search term. Implementation Notes FE
Controller: ??? Template: ??? BE API Endpoint: ???
Includes the specifications for the CEF Admin - Users UI and
functionality. Pages: User Account Detail User Account Management Add
Users Browse Users Search Users
Goal Allow admin users to manage user account details including
functions like view, add, edit, delete.
User Stories Priority Title Must Have Stories 1 Add User Admin user must
be able to initiate the process of adding a new user. 1 Edit User Admin
user must be able to initiate the process of editing a specific existing
user from the list. 1 Delete User Admin user must be able to initiate
the process of deleting a specific existing user from the list.
Goal Allow admin users to manage user accounts including functions like
list, browse, search, add, edit, delete.
User Stories Priority Title Must Have Stories 1 Browse Users Admin user
must be able to browse a list of users. The admin user must at least be
able to see the following user data; ID, First Name, Last Name, Email,
Phone, State, and Country in the list. 1 Search for User Admin user must
be able to search for users by the following user data; ID, First Name,
Last Name, Email, Phone, State, and Country. 1 Add User Admin user must
be able to initiate the process of adding a new user. 1 Edit User Admin
user must be able to initiate the process of editing a specific existing
user from the list. 1 Delete User Admin user must be able to initiate
the process of deleting a specific existing user from the list. 2 Show
Deleted Users Admin user must be able to display deleted users. 2
Undelete User Admin user must be able to initiate the process of
undeleting a user. Add Users User Story Description 1. 2. 3. Admin user
must be able to initiate the process of adding a new user. JIRA Issues
- ( )CEF-45 User Account Management Open
Mock-up Requirements Implementation Notes FE Controller: ??? Template:
??? BE API Endpoint: ???
Browse Users User Story Description Admin user must be able to browse a
list of users. The admin user must at least be able to see the following
user data; ID, First Name, Last Name, Email, Phone, State, and Country
in the list. JIRA Issues
- ( )CEF-45 User Account Management Open
Mock-up Requirements Display user list using standard grid control.
Column Headings: Id, First, Last, Email, Phone, State, Country, and
Actions Data source: Table: Users -> Contacts Implementation Notes FE
Controller: ??? Template: ??? BE API Endpoint: ???
Search Users User Story Description Admin user must be able to search
for users by the following user data; ID, First Name, Last Name, Email,
Phone, State, and Country. JIRA Issues
- ( )CEF-45 User Account Management Open
Mock-up Requirements Implementation Notes FE Controller: ??? Template:
??? BE API Endpoint: ???
This content has been replicated to the new documentation section under
07. User Documentation (R4) Documentation for Developer and End User
audiences will be completed on the MadCap Flare software for publishing
the documentation source to PDF and online user documentation with
minimal time and effort after authorship. Flare allows for multiple
output types, and tracks of publishing using conditionals to steer the
audience type and targets to steer the publication to the web or print
documentation environment for the end user. For Clarity's purpose, the
tracks will be per Version number and the conditionals will be used for
delivering content to the audience types. More information can be found
in the software documentation here: .
http://webhelp.madcapsoftware.com/flare10/ The authoring file(Flare
Project) can be found on Dev B here:
C:\Data\Projects\ClarityInternal\Libraries\Documentation\V21\Clarity
eCommerce Framework.flprj The folder located at:
C:\Data\Projects\ClarityInternal\Libraries\Documentation\V21\ is
backed up into Stash so make sure to pull down, before you publish out
your new files with Flare, then push back into Stash. The menu structure
for the documentation will be broken down between the Framework, API,
Connect and Web UI. Development comments should be marked with
conditionals towards development and end user comments should be marked
with conditionals towards UI. Comments for both can be marked with both.
Purpose The product import spreadsheet will allow the Client team to use
a standard format to send their information to the Clarity team to
initially populate their eCommerce system with data. This can be for
development purposes only, or it can be the "master" set of data
expected to be used for the production site. It's possible, once the
import is completed to "wipe" the database as well and re-import if they
want to use the spreadsheet to massage the data and see how it comes
over. In other words, the import tool is a heavily automated process to
enable ease of import of data into the system. Getting the Latest Import
File We've attached the import file here. However, you can also access
the latest file at:
\\10.10.30.74\data\Documents\Clients\_Clarity_eCommerce\Documents\Project
Planning Using the File Note that not all the fields a Client may need
are included in the import file. Typically these additional fields are
perfectly fine for us to import for them and they would need to be
included at the end of the listing of columns within the import
spreadsheet. Typically these would be referred to as "attributes" - they
are typically a collection of labels, open text or "pre-selected" (think
drop down list) fields. The attributes can be things like colors, sizes,
options, etc. and they can be variant based on the category, subcategory
or product itself. The attributes can also drive sku and price data
dynamically if needed. Of course, this is just an intro to the import
file process - for more information feel free to review with the Clarity
eCommerce Framework team and they can facilitate complex requests.
File Modified
ABC_Product_Import_v01.xlsx Sep 01, 2015 by Chris Reddick
productimport.xlsx Jul 20, 2015 by Timothy Scott Heimsoth
Drag and drop to upload or browse for files
Download All
The documentation for Clarity Connect
File Modified
ClarityConnectDocumentation.docx Sep 03, 2015 by James Gray
Service providers are defined as any API or service that is necessary to
provide functionality for core ecommerce functions.
Payment Providers
Authorize.NET
Configuration Values
systemValues.Payment.AuthorizeNet.Login:
3S25T7vCAp5
SystemValues.Payment.AuthorizeNet.TransactionKey: 3p9dV2Jt8495M53M
Testing Information
- American Express Test Card: 370000000000002
- Discover Test Card: 6011000000000012 - Visa Test Card: 4007000000027
BNG
Configuration Values
SystemValues.Payment.BNG.Login:
885YzAEvL
SystemValues.Payment.BNG.Password:
9743s8Pss7PJZcvt
Testing Information
- Visa: 4111111111111111
- MasterCard: 5431111111111111
- Discover: 6011601160116611
- American Express: 341111111111111
- Credit Card Expiration: 10/25
- account (ACH): 123123123
- routing (ACH): 123123123
Litle / Vantiv
Configuration Values
SystemValues.Payment.Litle.URL
https://www.testlitle.com/sandbox/communicator/online
SystemValues.Payment.Litle.ReportGroup
Default Report Group
SystemValues.Payment.Litle.Username
JoesStore
SystemValues.Payment.Litle.Host
demo.cef.com
SystemValues.Payment.Litle.Version
8.10
SystemValues.Payment.Litle.Timeout
65
SystemValues.Payment.Litle.MerchantId
default
SystemValues.Payment.Litle.Password
JoeyIsTheBe$t
SystemValues.Payment.Litle.Printxml
true
SystemValues.Payment.Litle.Port
80
Testing Information
000: Approved 4470330769941000
010: Partially Approved 4658512425423010 100: Processing Network
Unavailable 4886883711815100 101: Issuer Unavailable 4215176886320101
110: Insufficient Funds 4488282659650110
Shipping Providers
FedEx
SystemValues.Shipping.FedEx.AccountNumber
510087984
SystemValues.Shipping.FedEx.MeterNumber
118681677
SystemValues.Shipping.FedEx.Username
a4NyFokkcUdkDJep
SystemValues.Shipping.FedEx.Password
pjqbKIUGlTwwExGqiLgmetdyw
UPS
SystemValues.Shipping.UPS.AccessLicenseNumber
2CF4B451E1EAF296
SystemValues.Shipping.UPS.Username
ClarityTim
SystemValues.Shipping.UPS.Password
Thedoor7
SystemValues.Shipping.UPS.ShipperNumber
85953Y
Tax Providers
Avalara
SystemValues.Tax.Avalara.AccountNumber
1100110323
SystemValues.Tax.Avalara.LicenseKey
3C54CD9A2E842863
SystemValues.Tax.Avalara.ServiceURL
https://development.avalara.net/
SystemValues.Tax.Avalara.CompanyCode
01
SystemValues.Tax.Avalara.EnableDevelopmentMode
True
This page is due to retire and it's contents have been replicated to the
new documentation section under Development Lifecycle & Processes
Overview This document is intended to provide guidelines for the
development processes of the ecommerce platform. The process is designed
to be light weight and efficient while adhering to current industry
standards. Although this document may not capture 100% of the scenarios
that may be encountered throughout the development process, this
document is to be considered a living document that may be updated in
the future to document and unforeseen. The format of this document will
focus on the high level processes initially then explore the details of
each process in sequential order. Any miscellaneous, but relevant
processes will be amended towards the end unless another logic order is
more ideal. Lifecycle The development lifecycle is modelled after agile
product development practices with a scrum management process. In the
figure below, 10 key high level processes are identified for managing
the development processes of the ecommerce platform starting with
platform road mapping. For each key process, the roles that are involved
in that process are identified in the figure below. Roles Sales The
sales role is filled by either the active Vice President of Sales or a
sales team member tasked with providing input for the direction the
platform from the sales team. The primary function of this role is to
provide feedback in the product development process that will help shape
the platform into the ideal product to sell in the target market. Sales
also follows up with the client currently which will provide feedback
for the improvements on existing features that are needed. Marketing The
marketing role is filled by the active executive from the marketing
department. This role is intended to provide insight on the competitive
landscape and the ideal target market to develop feature or to fill
voids in certain market areas. Firm Partners Firm partners are roles
that have equity interest in the firm, such as the CEO. The partner
roles are required for the platform development process to ensure firm
resources are used efficiently and the product direction is in line with
the vision for the firm. Platform Lead The role of the platform lead is
to be the deciding factor in the technical direction of the platform.
This role also manages the key parts of the development process to
ensure quality, consistency, and technical support or guidance to other
development members. This role is intended to help knock down
development roadblocks to help ensure progress. Management Management
includes development managers for the front and backend to ensure
adequate resources are allocated to meet timelines. Project Management
The project management role is to ensure timelines and expectations are
within reason. Senior Development Senior development roles are any
developer positions containing senior titles. These roles are vital in
the process to provide key architectural and technical insights for the
products technical direction. These roles also help in the development
the features of the platform and improve development processes.
Developers Developers provide the technical skill sets to create the
product features. QA Members QA members review the finish development of
all features to ensure product issues do not make it to clients.
Stakeholders The stakeholders are responsible for providing insight and
details for specific tasks. This role could be comprised of either an
internal employee or designated customer. Key Process Platform
Development Road Mapping The road mapping process is designed to
identify all features need for a commercially viable product and
prioritize them based off business and technical needs. This process
takes the form of a quarterly meeting between all roles involved. Prior
to the meeting each individual is required to compose a list of newly
identified features and send them to all participants. Each newly
identified feature should contain a short description of the business
needs, a priority, and a description of the functionality required by
each feature. During each meeting the group reviews, discusses, and
approves new features. The group will also review existing features and
decide whether to demote them from the roadmap. Once the list is
approved each road mapping iteration the top priority features will be
grouped in to 2 or 3 sequential releases in which the releases will be
developed. Release Cycle A release cycle is the development process to
complete a group of features from the roadmap that has already been
defined for the release by the road mapping committee. Each release
starts off with reviewing the individual features assigned to the
release and then defined into tasks with functional and technical
details in Jira, the release management tool. Once all features of the
release have been broken into concise and manageable tasks, the task are
then organized into two or more sprints, about two weeks long each,
which make up the release. Based on the amount of effort and resources
available a timeline will be determined for the series of sprints to be
completed by to calculate a release date. After the sprints and timeline
are solidified a sprint cycle may begin. Sprint Cycle The sprint cycle
is the actual development process of the tasks assigned to a sprint. The
cycle starts off with a planning meeting to finalize the details of the
sprint then moves into a setup of the sprint and feature development.
After each feature has been developed, a QA member or stakeholder will
review the wok completed to make sure it functionally satisfies the
business needs. Once the business needs have been met for a feature, the
code developed is reviewed by peers to ensure quality and best
practices. When all the features have been completed, the new features
developed in the sprint will be reviewed one more time prior to updating
the release branch with the latest. After the sprint development has
been completed, a sprint retrospect is performed to assess what worked
well, what didn't work well, and what needs to change for the next
sprint. Planning During the sprint planning tasks are reviewed to make
sure the timeline is realistic. Any adjustments to the sprint are made
at this time. The only exceptions to adjusting the items being worked on
in a sprint are if urgent business needs have been submitted to crash
the development schedule or sprint items have been completed ahead of
time. When reviewing the sprint items, there are several things that
need to be reviewed or provided. Below is a validation list for the
sprint items in Jira. Sprint Item Validation Check List Brief summary of
the task is provided A subsystem is identified Priority is established A
detailed description or sub tasks that make up the task are provided
Estimate (Original Estimate in Jira) Stakeholder must be provided that
is the business expert for the requested feature Sprint assigned Epic
link provided After all items have been reviewed and pass the criteria,
the time required to develop each item of the sprint and available
resources should be reviewed to verify enough resources have been
allocated to the sprint. When all the details have been solidified and
risks have been identified then the sprint may begin. Pre-Sprint Setup
The sprint set up is composed of a few tasks that need to be performed
prior to each sprint. Below is a list that details the tasks need prior
to starting a sprint. Pre-Sprint Setup Start JIRA sprint Verify current
release state is buildable and tagged Create new release branch if start
of new release Verify environments need are set up prior (DB, Dev
servers) Development Features Feature developers are responsible for the
actual development and implementation of the requested feature. In order
to start developing a feature, the sprint must be started and an item
must be assigned. QA / UAT During the QA process, a QA member or
stakeholder will review the newly completed feature and verify that the
expected functionality is working correctly. Ideally a separate
environment is set up for this review for the QA member or stakeholder
to review the feature. During this time, adjustments may be needed in
order for the feature to be acceptable for a completed status. Peer
Review / Sign off When the JIRA task has been marked for completion, the
developer of the feature will need to send an email to one or more peers
detailing the change and files. If the peer, approves of the
implementation then the code can be merged into the sprint. If the peer
does not approve, then the peer needs to detail a more ideal
implementation or note any adjustments. Once the code has been deemed to
be in good standing then it can be merged back into the release branch.
Retrospect After all tasks have been completed or the sprint timeline
has finish, then a sprint retrospect needs to be completed. This can
take the form of a meeting or an email, but the following items need to
be detailed out by the team prior to starting another sprint cycle.
Retrospect items What worked well? What didn't work well? What do we
need to change? Or how can we fix what did not go well. Tag Release
Branch After each sprint is completed, the platform development lead
needs to ensure all features of a sprint have been merged into the
release branch. If the sprint is the last sprint of a release then the
platform lead needs to merge the release branch into the trunk. At this
time, a tag needs to label the completion of each release and sprint in
source control to easily identify it for future reference. The Platform
lead needs to ensure each merge into release or trunk is buildable. All
trunk merges must be production ready.
This page is due to retire and it's contents have been replicated to the
new documentation section under Work with Visual Studio Online (VSO)
Please use this process below to document any "bugs" with the CEF
platform. Step-by-step guide to add a bug to VSO Login to : VSO
https://clarity-ventures.visualstudio.com/ Find the project and go
into the tab within the project Work For the you can click this link to
be taken directly to the backlog: CEF-Product
https://clarity-ventures.visualstudio.com/DefaultCollection/CEF-Product/_backlogs
Click and change the type to New Item Bug Type the of your new and press
Title Bug Enter Open your new by double-clicking on the new row in the
and perform the following modifications to the Bug: Bug Backlog Assign
to Dustin Grant Add the project name as a using the auto-complete
feature to match associated items: eg- , Tag Protech UMC Select the best
fitting in the field Area Area Set the of this as it pertains to your
project. If it is blocking the ability to implement a critical site
feature, mark it as Severity Bug .1 - Critical That will be handled by
Dustin. NOTE: DO NOT SET PRIORITY. Write the reproduction steps with any
pertinent information to the field Repro Steps Best Practices Provide
detailed steps to replicate the bug being sure to include any
information that might be relevant. Provide full urls where applicable
to any web pages referenced. Provide full log in information if it is
needed to replicate your bug. Include any steps you have taken to
attempt to remedy or work around the problem. If it's a very higher
priority for you, explain why in your bug report. If anyone has special
knowledge of this bug, or has worked on it in the past mention them so
it can be assigned appropriately.
Related articles (R) CEF Website Quality Assurance Steps (R) Bug
Prioritization (R) How To Submit a VSO Bug CEF Website QA Checklist Bug
Prioritization Showing first 5 of 6 results
This page is due to retire and it's contents have been replicated to the
new documentation section under Work with Visual Studio Online (VSO) The
following key factors should be considered when prioritizing or ranking
bug fixes. A bug report that meets any of the following criteria should
typically be treated with urgency: Is it a bug that effects multiple
concurrent installations of the store? Is it a bug that prevents a user
from purchasing an item? Is it a bug that prevents an administrator from
performing fundamental store functions such as: updating products,
changing payment information or viewing transactions? Does this bug
prevent development in other (or all) key areas of a project or
projects? Will this bug have an immediate effect on an important client
deadline? Was this bug submitted or sponsored by a team lead? There are
detailed fields you can edit within the bug ticket to incorporate the
project the bug applies to, the severity (NOT PRIORITY) and other
details that will help with quickly identifying/replicating and
resolving the issue! 1. a. 2. a. i. b. i. ii. iii. iv. v. vi. c. i. ii.
iii. iv. v. d. i. ii. iii. e. i. ii. f. i. 3. a. b. i. ii. iii. iv. v.
c. i. d. i. ii. iii. iv. e. i. f. i. Some Notes on Project Resolution
Time How long a bug fix is expected to take should be considered along
with other factors. For example, a bug fix that meets the criteria for
urgent intervention and that can be resolved very quickly should almost
always be near the very top of the list. Alternately, an issue that is
not particularly urgent and that will furthermore take a long time to
address should be near the bottom of any list. Lower Priority Factors
Most of these can be readily inferred from the urgent list. The bug only
effects a single instance. The bug can be worked around, other work can
continue while it is in the dock. The bug relates to a feature that does
not prevent item purchase or basic store administration.
This page is due to retire and it's contents have been replicated to the
new documentation section under Quality Assurance The below guide will
help team members with the eCommerce Website QA process Step-by-step
guide Recommended areas to confirm eCommerce Site functionality: API Can
you access the API URL / endpoints - for example
www.devsite.us/DesktopModules/ClarityeCommerce/API Storefront Sample
Data Does the product page show demo products Catalog Is there a working
product catalog page Does the category selector work Can you link
directly to a product category from the nav Can you click on a product
and be taken to the product detail page Does the page selector work Do
the Items per page work Product Detail Does the product detail page show
the correct price and product attribute selectors Does the product zoom
work Do the related products appear Does the product gallery work Does
the add to cart button work Cart Does the view cart template work and
update when an Item is added Can you increase quantity and clear the
cart Does the go to checkout link work Checkout Can you complete the
checkout process Can you log back in with the user used for checkout
User Dashboard Can you login and see the user dashboard after logging in
Admin Can you access the CEF admin dashboard Product Can you add a
product Can you associate to a category/categories Can you add related
products Can you assign product attributes Can you add product images
Category Can you create a category Sales Order Can you view past sales
orders Can you update a sales order Can you modify the payment status or
process payment Can you add new line items or process an RMA Accounts
Can you add/remove accounts Reports Can you access the reports 3. f. i.
4. a. b. i. Do the reports provide meaningful/accurate data Bug
Reporting Use the bug reporting standards to issue bug reports using the
tools for that particular project Note that typically the more
information provided the better someone can debug quickly Key items are
browser version, dimensions, page url, IP and date/time, highlight of
the screen / screenshot, and notes Related articles (R) CEF Website
Quality Assurance Steps CEF Website QA Checklist
productimport.xlsx Create from Template Title Creator Modified Product
Import Spreadsheet Timothy Scott Heimsoth Sep 01, 2015 Clarity Connect
Timothy Scott Heimsoth Jan 29, 2015 Specification Timothy Scott Heimsoth
Dec 02, 2014
(R) Sprint Planning
This content has been replicated to the new documentation section under
Work with Visual Studio Online In , the sprint planning meeting is
attended by the product owner, ScrumMaster and the entire Scrum team.
Outside stakeholders may Scrum attend by invitation of the team,
although this is rare in most companies. During the sprint planning
meeting, the product owner describes the highest priority features to
the team. The team asks enough questions that they can turn a high-level
user story of the product backlog into the more detailed tasks of the
sprint backlog. The product owner doesn't have to describe every item
being tracked on the product backlog. A good guideline is for the
product owner to come to the sprint planning meeting prepared to talk
about two sprint's worth of product backlog items. To make an example
really simple, suppose a team always finishes five product backlog
items. Their product owner should enter the meeting prepared to talk
about the top 10 priorities. There are two defined artifacts that result
from a sprint planning meeting: A sprint goal A sprint backlog A sprint
goal is a short, one- or two-sentence, description of what the team
plans to achieve during the sprint. It is written collaboratively by the
team and the product owner. The following are example sprint goals on an
eCommerce application: Implement basic shopping cart functionality
including add, remove, and update quantities. Develop the checkout
process: pay for an order, pick shipping, order gift wrapping, etc. The
sprint goal can be used for quick reporting to those outside the sprint.
There are always stakeholders who want to know what the team is working
on, but who do not need to hear about each product backlog item (user
story) in detail. The success of the sprint will later be assessed
during the sprint review meeting against the sprint goal, rather than
against each specific item selected from the product backlog. The sprint
backlog is the other output of sprint planning. A sprint backlog is a
list of the product backlog items the team commits to delivering plus
the list of tasks necessary to delivering those product backlog items.
Each task on the sprint backlog is also usually estimated. An important
point to reiterate here is that it's the team that selects how much work
they can do in the coming sprint. The product owner does not get to say,
"We have four sprints left so you need to do one-fourth of everything I
need." We can hope the team does that much (or more), but it's up to the
team to determine how much they can do in the sprint.
CREDIT FOR CONTENT ABOVE:
http://www.mountaingoatsoftware.com/agile/scrum/sprint-planning-meeting
Create from Template Title Creator Modified (R) Install Clarity
eCommerce v4.X Chris Reddick Oct 06, 2015 (R) CEF Website Quality
Assurance Steps Ken Beckstead Oct 06, 2015 (R) How To Submit a VSO Bug
Chris Reddick Oct 06, 2015 CEF Website QA Checklist James Gray Oct 06,
2015 How To Submit a VSO Bug James Gray Oct 06, 2015 Installation Guide
for Clarity eCommerce Mar 05, 2014 2.x Michael Angstadt
See child pages for updated documentation templates. These will be
fleshed out and replace existing documentation in the proper formats.
Dependency Map The following map shows a diagram of the current system
and how each project related to one another. You can see that the core
functional projects are tightly coupled together. The User Interface
projects do not directly require the back end except the presence of the
Services layer to communicate with the API. What languages do we use?
C# ASP.NET 4.5 T-SQL JavaScript TypeScript What Technologies do we use?
MS SQL C# .NET EntityFramework StructureMap ServiceStack log4net
OpenXML xUnit TypeLite Google Docs Lucene Newtonsoft.json Angular
TypeScript Kendo UI (by Telerik) Owin DotNetNuke SiteFinity WordPress
Where will data live? MS SQL Server 2012 R2 Accessible by
EntityFramework calls (no direct SQL queries) What Patterns do we use? A
specific pattern could not be identified for the solution as a whole,
the following short notation of the 5 primary layers indicates a pattern
similar to Repository, thought Repository was not followed. Db (Code
first) <-> DAL (EF) <-> Business Logic (Workflows) <->
Services (ServiceStack) <-> UI (Angular) In each layer, code was
written to perform the best possible outcome with the least amount of
writing. The process has been very organically driven by customer
requests over several years and worked by multiple core team developers.
The following map shows a diagram of the current system and how each
project related to one another. You can see that the core functional
projects are tightly coupled together. The User Interface projects do
not directly require the back end except the presence of the Services
layer to communicate with the API. Clarity.Ecommerce: Contains core
Utilities code, Enums and Interfaces Clarity.Ecommerce.DataModel:
Contains the Code-First Schema for the Database
Clarity.Ecommerce.Models: Contains Data Transfer Models (Concretes)
AuthorizeNET: Contains code for communicating with the Authorize.NET
payment processor API Clarity.Ecommerce.Integration: Contains code for
communicating with Tax Providers (such as Avalara), Payment Processors
(such as BNG) and Shipping Providers (such as UPS, FedEx)
Clarity.Ecommerce.Workflow: Contains the core business logic for the
solution, such as retrieving Products that meet certain criteria,
calculating their prices and sending it off for use by the Services
layer Clarity.Ecommerce.Workflow.Test: Unit Testing for the Business
Logic, also contains other unit tests Clarity.Ecommerce.Service:
ServiceStack services layer for communication between the UI and the
Business Logic ServiceStack.CodeGenerator.TypeScript: A TypeScript
Generator that reads the ServiceStack Services set up and creates
TypeScript ready code for convenient use of the Services API
Clarity.Ecommerce.UI: The Core User Interface Angular Code, common html
templates and core CSS Clarity.Ecommerce.DNN: A DNN-specific CMS
Installer for the platform Clarity.Ecommerce.Demos: A SPA website which
demonstrates the functionality of the solution in a segregated
environment (non-CMS) Clarity.Ecommerce.Demo.DNN: A DNN website which
demonstrates the functionality of the solution in a DNN CMS environment
Back End C# .NET 4.5 T-SQL JSON XML Front End HTML 5 CSS 3 LESS
Bootstrap 3.x Syntax JavaScript jQuery Syntax AngularJS Syntax
TypeScript
Back End Services Technologies MS SQL 2012 R2 EntityFramework 6.1.3 C#
.NET 4.5 LINQ log4net StructureMap 3.x Lucene ServiceStack 4.0.38
Newtonsoft.json 4.5 xUnit 2 TypeLite MS OpenXML API Google Docs API
Front End Web Technologies C# .NET 4.5 Kendo UI (by Telerik) 2015.x
JSON JavaScript TypeScript JQuery AngularJS Owin NPM Gulp Bower LESS 1.
a. 2. a. 3. a. 4. a. 5. a. b. c. 6. a. 7. a. b. 8. a. b. i. c. d. CSS 3
HTML 5 Bootstrap 3.x Karma Jasmine Content Management Systems (CMS)
DotNetNuke 7+ SiteFinity 8.1+ WordPress
Database and Access Technologies MS SQL Server 2012 R2 Accessible by
EntityFramework 6.1.3 calls (no direct SQL queries) EF is available free
via NuGet EF Code First is used to generate a database schema from C#
code Schema Quick Reference Products are stored under Catalog.Product.
This expands out to Catalog.ProductXXXX where XXXX are things like
Attributes, Associations, Price Points, Variants, Media, Types.
Categories are stored under Catalog.Category. This expands out to
Catalog.CategoryXXXX where XXXX are things like Attributes, Price
Points, Variants, Media, Types.
Coding Standards How does CEF meet the Architecture? Projects Outline
Code must pass analysis with 0 warnings StyleCop Exceptions on a
Case-by-Case basis Code must pass with 0 warnings Microsoft Managed
Rules Exceptions on a Case-by-Case basis Code must pass analysis with 0
errors ReSharper Error Exceptions on a Case-by-Case basis Code must pass
analysis with 0 warnings ReSharper Warning Exceptions on a Case-by-Case
basis Code must pass all written for it Unit Tests The Business
Workflows Layer must have 98% Unit Test Coverage as this is the most
critical area to cover All other Layers must have 80% coverage Any valid
Bug submitted for the platform must have a Unit Test created that tests
the expected result, to prevent regression by future code Code must
follow the Naming, Formatting, Layout, styles as specified by the
Clarity Shared ReSharper Settings See James G for a copy of these
settings Code must not surpass a threshold of Cyclomatic Complexity 25
In layman terms this means don't make any one function too big as that
is more difficult to maintain. Try to break the function up into smaller
functions called by a main in order if possible Exceptions on a
Case-by-Case basis All code Properties, Fields, Enumerations, Classes,
Functions, etc must have full Summary Information Tags The tags may be
generated by Atomineer as a minimum. Complex functions should have
Remarks tags which explain difficult to read or understand workflows,
e.g.- code that can't self-document what it is doing very well Tags
should be compile-able by an external system such as GhostDoc for
creating Platform Documentation Exceptions on a Case-by-Case basis CEF
Naming Conventions Cheat Sheet Abbreviation: CEF Name in Code:
ClarityEcommerce [] - Brackets indicate project or scenario specific
name Scenario Format Example Notes Database Name _CEF_[PROJECT]
_CEF_BIO, _CEF_PFH Version maintained in table System.Info Folder in
DNN \DesktopModules\ClarityEcomm erce
Angular Directives cef-[directive] cef-shopping-cart Namespaces
Clarity.Ecommerce Project Implementation Folder
C:\Data\Projects\[PROJECT] C:\Data\Projects\BIO Subfolders:
_Archives Data Framework Web Visual Studio Solution Folder
Clarity.Ecommerce.[Component] Clarity.Ecommerce.Services Marketing
space Clarity eCommerce Framework SQL User Names CEF_User CEF_User If
a specific user is needed other wise use the standard user HTML IDs
cef[Id] cefCart Use camelCase DNN Admin Skin Name
ClarityEcommerceAdmin
As the architecture does not currently define a strict pattern,
developers must at least adhere to the general guidelines of where to
put logic as defined by the Projects Outline. Core Schema code should be
present in the DataModel project, Business Logic in the Workflows
project, etc. For more specific details, please contact Tim.
Clarity.Ecommerce: Contains core Utilities code, Enums and Interfaces
Clarity.Ecommerce.DataModel: Contains the Code-First Schema for the
Database Clarity.Ecommerce.Models: Contains Data Transfer Models
(Concretes) AuthorizeNET: Contains code for communicating with the
Authorize.NET payment processor API Clarity.Ecommerce.Integration:
Contains code for communicating with Tax Providers (such as Avalara),
Payment Processors (such as BNG) and Shipping Providers (such as UPS,
FedEx) Clarity.Ecommerce.Workflow: Contains the core business logic for
the solution, such as retrieving Products that meet certain criteria,
calculating their prices and sending it off for use by the Services
layer Clarity.Ecommerce.Workflow.Test: Unit Testing for the Business
Logic, also contains other unit tests Clarity.Ecommerce.Service:
ServiceStack services layer for communication between the UI and the
Business Logic ServiceStack.CodeGenerator.TypeScript: A TypeScript
Generator that reads the ServiceStack Services set up and creates
TypeScript ready code for convenient use of the Services API
Clarity.Ecommerce.UI: The Core User Interface Angular Code, common html
templates and core CSS Clarity.Ecommerce.DNN: A DNN-specific CMS
Installer for the platform Clarity.Ecommerce.Demos: A SPA website which
demonstrates the functionality of the solution in a segregated
environment (non-CMS) Clarity.Ecommerce.Demo.DNN: A DNN website which
demonstrates the functionality of the solution in a DNN CMS environment
Code Reviews Coding in Each Project 01. Clarity.Ecommerce 02.
Clarity.Ecommerce.DataModel 03. Clarity.Ecommerce.Models 04.
Clarity.Ecommerce.Workflows 05. Clarity.Ecommerce.Services 06.
Clarity.Ecommerce.UI In-line Code Documentation Summary Tags with
Atomineer Other Projects Continuous Integration (CI) (Video) Continuous
Integration Continuous Integration with TeamCity Continuous Integration
with VSO-TFS Development Lifecycle & Processes (Video) Development & QA
Cycles During a Project Quality Assurance (Video) What A Good QA Testing
Plan Should Include CEF Website QA Checklist Work with Git Source
Control (Video) Creating a New Project or New Feature Repository (Video)
Source Control & Version Control for CEF (Video) Source Control for New
Features or New Projects Checking Out Code Pulling a Commit Which
Requires Upgrade Instructions Work with Visual Studio Online (VSO)
(Video) Create a Bug as a Client (Video) Reporting a Bug as a Clarity
Team Member Bug Prioritization How To Submit a VSO Bug Scrum Sprint
Planning Writing Software Change Notifications (SCNs)
What is a Code Review A Code Review is an action taken by a senior team
member to review code commits submitted by other team members, looking
to ensure that all code in the commit meets the Coding Standards. The
purpose of a Code Review is to ensure that no new code is accepted which
would go against the patterns, naming conventions and aesthetics of how
we want the solution code to appear. If a particular code commit does
not meet certain expectations, the commit can be pushed back to the
developer with notes to make specific corrections. Code Reviews play a
significant part of the Gated Checkin process, where the code actually
can't be pushed to the main branch without an approver signing off on
the code. Performing a Code Review CI process should handle the first
part of a Code Review, checking that the Unit Tests cover the new code
and that all Unit Tests pass. If a unit test fails, the Commit should be
automatically kicked back to the user. Additional points we can add to
the CI process include running StyleCop, FxCop and ReSharper analysis
with Rule-Sets to check for changes and provide a detailed report to the
user if any rule should fail. The last part should include the senior
team member either directly reviewing the new code if it is a simple
change or sitting with the developer for more complex changes. In the
code review, the reviewer should be checking the code for things that
don't coincide with the overall plan of the platform and/or the clients
that it is intended for.
We will be adding the step-by-step instrucitons for doing this in TortoiseGit, VS and VSO once the Gated Checkin process isNOTE: finalized. Until this time, you may review any and all code commits for any version via the CEF branch pages in Stash: http://stash:7990/projects/CEF/repos/framework/commits?until=refs%2Fheads%2FRelease4_1
Example Enum /// <summary>An enumerable of Cart Types</summary> public
enum CartType { /// <summary>The enumeration value representing Shopping
Carts</summary> [Description("Shopping Cart"] Shopping = 0,
/// <summary>The enumeration value representing Samples Carts</summary> [Description("Samples Cart"] Samples = 1,
/// <summary>The enumeration value representing Quote Requests</summary> [Description("Quote Request"] QuoteRequest = 2 }
======= Clarity.Ecommerce.DataModel ======= All code pertaining to the
CEF Database as generated by EntityFramework 6.1.3 must be stored in
this project. This project may not be dependent on any other project in
the solution except for the core Clarity.Ecommerce project, which will
contain Interfaces used by this project. Example Table // == File must
have a copyright tag by Clarity unless the code is from a third party ==
// <copyright file="Account.cs" company="clarityventures.com"> //
Copyright (c) 2015 Clarity Ventures, Inc. All rights reserved. //
</copyright> // <summary>Implements the account class</summary>
namespace Clarity.Ecommerce.DataModel { // == Usings must be inside the
namespace and sorted alphabetically, with System namespaces coming first
== using System; using System.Collections.Generic; using
System.ComponentModel.DataAnnotations; using
System.ComponentModel.DataAnnotations.Schema;
[Table("Accounts.Account")] // == Defines the Schema and the table name at once == public class Account // Future Versions would have this inherit from a shared entity base and an IAccount interface from Clarity.Ecommerce { public Account() { // Assigns default HashSets for use by EF AccountAddresses = new HashSet<AccountAddress>(); AccountPricePoints = new HashSet<AccountPricePoint>(); AccountReviews = new HashSet<AccountReview>(); AccountAttributes = new HashSet<AccountAttribute>(); ChildAccounts = new HashSet<Account>(); NotificationMessages = new HashSet<NotificationMessage>(); PurchaseOrders = new HashSet<PurchaseOrder>();
QuoteRequests = new HashSet<QuoteRequest>(); Users = new HashSet<User>(); }
// Future versions will inherit these properties from SharedEntityBase public int ID { get; set; }
[StringLength(100)] public string CustomKey { get; set; }
[Column(TypeName = "smalldatetime")] public DateTime CreatedDate { get; set; }
[Column(TypeName = "smalldatetime")] public DateTime? UpdatedDate { get; set; }
public bool Active { get; set; }
// Future versions will inherit these properties from NameableSharedEntityBase [StringLength(200)] public string Name { get; set; }
public string Description { get; set; }
// Future versions will inherit these properties from ContactableSharedEntityBase [StringLength(50)] public string Phone { get; set; }
[StringLength(50)] public string Fax { get; set; }
[StringLength(1000)] public string Email { get; set; }
// Account Specific Properties [StringLength(1000)] public string Website { get; set; }
[StringLength(1000)] public string SeoKeywords { get; set; }
[StringLength(1000)] public string SeoUrl { get; set; }
// Related Objects == Group them together with their foreign key identifiers public int? ParentAccountID { get; set; } public virtual Account ParentAccount { get; set; } public virtual Company Company { get; set; } // Note: Company.ID will match this.ID public int AccountTypeID { get; set; } public virtual AccountType AccountType { get; set; }
// Associated Objects public virtual ICollection<Account> ChildAccounts { get; set; } // ChildAccounts[0].ParentID is how this is associated public virtual ICollection<AccountAddress> AccountAddresses { get; set; } public virtual ICollection<AccountPricePoint> AccountPricePoints { get; set; } public virtual ICollection<AccountReview> AccountReviews { get; set; }
public virtual ICollection<AccountAttribute> AccountAttributes { get; set; } public virtual ICollection<NotificationMessage> NotificationMessages { get; set; } public virtual ICollection<PurchaseOrder> PurchaseOrders { get; set; } public virtual ICollection<QuoteRequest> QuoteRequests { get; set; } public virtual ICollection<User> Users { get; set; } }
} ======= Clarity.Ecommerce.Models ======= This project will contain all
the Concrete models for transferring data between EntityFramework's
output and the Services Layer. ServiceStack provides DTOs which will
inherit from these to maintain property matching with easy maintenance.
Example Model namespace Clarity.Ecommerce.Models.Account { using System;
using Clarity.Ecommerce.Models.Address; using
Clarity.Ecommerce.Models.Attribute; using System.Collections.Generic;
using System.Linq; using System.Linq.Expressions; using
Clarity.Ecommerce.Models.Generic;
public class AccountModel { public int? ID { get; set; } public int? ParentID { get; set; } public string Name { get; set; } public int AccountTypeID { get; set; } public string CustomKey { get; set; } public string Description { get; set; } public string Phone { get; set; } public string Fax { get; set; } public string Email { get; set; } public string Website { get; set; } public string SEOUrl { get; set; } public List<AddressModel> Addresses { get; set; } public List<AttributeModel> Attributes { get; set; } public List<FileModel> Images { get; set; }
#region Mappings public static readonly Func<DataModel.Account, AccountModel> Map = a => new AccountModel { ID = a.ID, Name = a.Name, AccountTypeID = a.AccountTypeID, CustomKey = a.CustomKey, Description = a.Description, Phone = a.Phone, Fax = a.Fax, Email = a.Email, Website = a.Website, ParentID = a.ParentID, SEOUrl = a.SeoUrl, Addresses = a.AccountAddresses.Where(AddressModel.ActiveAccountAddressesOnly).Select(AddressModel. Map).ToList(),
Attributes = a.AccountAttributes.Where(AttributeModel.ActiveAccountAttributesOnly).Select(Attribute Model.AccountAttributeMap).ToList(), Images = a.Company != null?a.Company.CompanyImages.Where(FileModel.ActiveCompanyImagesOnly).Select(FileModel .CompanyImageMap).ToList():new List<FileModel>() }; internal Func<DataModel.Account, AccountModel> MapLite = a => new AccountModel { ID = a.ID, Name = a.Name, AccountTypeID = a.AccountTypeID, CustomKey = a.CustomKey, Description = a.Description, Phone = a.Phone, Fax = a.Fax, Email = a.Email, Website = a.Website, ParentID = a.ParentID, SEOUrl = a.SeoUrl, Addresses = a.AccountAddresses.Where(AddressModel.ActiveAccountAddressesOnly).Select(AddressModel. Map).ToList(), }; #endregion }
public static class AccountExtensions { public static IQueryable<DataModel.Account> FilterByActive(this IQueryable<DataModel.Account> query) { return query.Where(p => p.Active); } public static IQueryable<DataModel.Account> FilterByCustomKey(this IQueryable<DataModel.Account> query, string customKey) { return !string.IsNullOrWhiteSpace(customKey) ? query.Where(p => p.CustomKey.ToLower() == customKey.ToLower()) : query; } public static IQueryable<DataModel.Account> FilterByName(this IQueryable<DataModel.Account> query, string name) { return !string.IsNullOrWhiteSpace(name) ? query.Where(p => p.Name.ToLower().Contains(name.ToLower())) : query; } public static IQueryable<DataModel.Account> FilterByID(this IQueryable<DataModel.Account> query, int ID) { return query.Where(p => p.ID == ID);
} } }
======= Clarity.Ecommerce.Workflows ======= This project should contain
all the business logic for the platform.
Example Workflow namespace Clarity.Ecommerce.Workflow.AccountWorkflows {
using System; using System.Linq; using System.Collections.Generic; using
System.Data.Entity.Core.Objects.DataClasses; using
Clarity.Ecommerce.DataModel; using Clarity.Ecommerce.Models.Account;
public class AccountWorkflow : WorkflowBase { #region Read public AccountModel Get(int id) { return EntityContext.Accounts .FilterByActive() .FilterByID(id) .Select(AccountModel.Map) .FirstOrDefault(); }
public AccountModel Get(string customKey) { return EntityContext.Accounts .FilterByActive() .FilterByCustomKey(customKey) .Select(AccountModel.Map) .FirstOrDefault(); }
public List<AccountModel> Search(string customKey, string name) { return EntityContext.Accounts .FilterByActive() .FilterByCustomKey(customKey) .FilterByName(name) .Select(AccountModel.Map) .ToList(); } #endregion
#region Create public AccountModel Create(AccountModel model) {
var newAccount = new Account { Name = model.Name, AccountTypeID = model.AccountTypeID, CustomKey = model.CustomKey, Description = model.Description, Phone = model.Phone, Fax = model.Fax, Email = model.Email, Website = model.Website, ParentID = model.ParentID, SeoUrl = model.SEOUrl, CreatedDate = DateTime.Now, Active = true }; AssociateImages(newAccount, model); AssociateAddresses(newAccount, model); AssociateAttributes(newAccount, model); EntityContext.Accounts.Add(newAccount); EntityContext.SaveChanges(); return Get(newAccount.ID); } #endregion
#region Update public AccountModel Update(AccountModel model) { var curAccount = EntityContext.Accounts.FirstOrDefault(a => a.ID == model.ID && a.Active); if (curAccount == null) { return null; } curAccount.Name = model.Name; curAccount.AccountTypeID = model.AccountTypeID; curAccount.CustomKey = model.CustomKey; curAccount.Description = model.Description; curAccount.Phone = model.Phone; curAccount.Fax = model.Fax; curAccount.Email = model.Email; curAccount.Website = model.Website; curAccount.ParentID = model.ParentID; curAccount.SeoUrl = model.SEOUrl; AssociateImages(curAccount, model); AssociateAddresses(curAccount, model); AssociateAttributes(curAccount, model); EntityContext.SaveChanges(); return Get(curAccount.ID); } #endregion
#region Helpers private void AssociateImages(Account account, AccountModel model) { if (model.Images != null && model.Images.Any()) { // Update Existing Attributes var IDsToUpdate = model.Images.Where(i => i.ID.HasValue).Select(i => i.ID).ToList(); foreach (var image in account.Company.CompanyImages.Where(i => i.Active && IDsToUpdate.Contains(i.ID))) {
image.Library.Name = model.Images.Where(i => i.ID == image.ID).Select(i => i.Name).FirstOrDefault() ?? string.Empty; image.UpdatedDate = DateTime.Now; } // Remove Images foreach (var image in account.Company.CompanyImages.Where(i => i.Active && !IDsToUpdate.Contains(i.ID))) { image.UpdatedDate = DateTime.Now; image.Active = false; } // Add New Attributes if (model.Images.Any(i => !i.ID.HasValue) && account.Company.CompanyImages == null) { account.Company.CompanyImages = new EntityCollection<CompanyImage>(); } foreach (var image in model.Images.Where(i => !i.ID.HasValue).ToList()) { account.Company.CompanyImages.Add( new CompanyImage { Library = new Library { MediaTypeID = 1, //Default value Name = image.Name ?? string.Empty, Image = new Image { ImageFormatID = 1, //Default value // ReSharper disable once PossibleInvalidOperationException FullImageFileID = image.FileID.Value, ThumbImageFileID = image.FileID.Value, CreatedDate = DateTime.Now, Active = true }, CreatedDate = DateTime.Now, Active = true }, CreatedDate = DateTime.Now, Active = true }); } } else { if (account.Company?.CompanyImages != null) { //Remove All Attributes If None Where Passed in that exists foreach (var image in account.Company.CompanyImages.Where(a => a.Active)) { image.UpdatedDate = DateTime.Now; image.Active = false; } } }
}
private void AssociateAddresses(Account account, AccountModel model) { if (model.Addresses != null && model.Addresses.Any()) { //Update Existing Addresses var IDsToUpdate = model.Addresses.Where(i => i.ID.HasValue).Select(i => i.ID).ToList(); foreach (var address in account.AccountAddresses.Where(i => i.Active && IDsToUpdate.Contains(i.Address.ID))) { address.Address.Name = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.Name).FirstOrDefault() ?? string.Empty; address.Address.Street1 = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.Street1).FirstOrDefault() ?? string.Empty; address.Address.Street2 = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.Street2).FirstOrDefault() ?? string.Empty; address.Address.City = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.City).FirstOrDefault() ?? string.Empty; address.Address.DistrictID = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.DistrictID).FirstOrDefault(); address.Address.RegionID = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.RegionID).FirstOrDefault(); address.Address.RegionCustom = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.RegionCustom).FirstOrDefault() ?? string.Empty; address.Address.CountryID = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.CountryID).FirstOrDefault(); address.Address.CountryCustom = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.CountryCustom).FirstOrDefault() ?? string.Empty; address.Address.PostalCode = model.Addresses.Where(a => a.ID == address.Address.ID).Select(a => a.PostalCode).FirstOrDefault() ?? string.Empty; address.Address.UpdatedDate = DateTime.Now; address.IsPrimary = address.IsPrimary; address.IsBilling = address.IsBilling; address.UpdatedDate = DateTime.Now; } // Remove Address foreach (var address in account.AccountAddresses.Where(i => i.Active && !IDsToUpdate.Contains(i.Address.ID))) { address.Address.UpdatedDate = DateTime.Now; address.Address.Active = false; address.UpdatedDate = DateTime.Now; address.Active = false; } // Add New Address if (model.Addresses.Any(i => !i.ID.HasValue) && account.AccountAddresses == null) { account.AccountAddresses = new EntityCollection<AccountAddress>(); } foreach (var address in model.Addresses.Where(a=>!a.ID.HasValue)) { account.AccountAddresses.Add(new AccountAddress { Address = new Address { Name = address.Name,
Street1 = address.Street1, Street2 = address.Street2, City = address.City, DistrictID = address.DistrictID, RegionID = address.RegionID, RegionCustom = address.RegionCustom, CountryID = address.CountryID, CountryCustom = address.CountryCustom, PostalCode = address.PostalCode, CreatedDate = DateTime.Now, Active = true }, IsPrimary = address.IsPrimary, IsBilling = address.IsBilling, CreatedDate = DateTime.Now, Active = true }); } } else { foreach (var address in account.AccountAddresses) { //Remove Associated Addresses address.Address.UpdatedDate = DateTime.Now; address.Address.Active = false; //Remove Address address.UpdatedDate = DateTime.Now; address.Active = false; } } }
private void AssociateAttributes(Account account, AccountModel model) { if (model.Attributes != null && model.Attributes.Any()) { if (account.AccountAttributes == null) { account.AccountAttributes = new List<AccountAttribute>(); } var IDsToUpdate = model.Attributes.Where(a => a.ID.HasValue).Select(i => i.ID).ToList(); // Remove Images foreach (var attribute in account.AccountAttributes.Where(i => i.Active && !IDsToUpdate.Contains(i.ID))) { attribute.UpdatedDate = DateTime.Now; attribute.Active = false; } foreach (var attribute in model.Attributes) { if (attribute.ID.HasValue) { var ID = attribute.ID.Value; var attributeValue = account.AccountAttributes.Where(pa => pa.ID == ID).Select(av => av.AttributeValue).FirstOrDefault(); if (attributeValue == null || !attribute.AttributeID.HasValue) continue; attributeValue.AttributeID = attribute.AttributeID.Value; attributeValue.Value = attribute.Value;
attributeValue.UpdatedDate = DateTime.Now; } else if (attribute.ValueID.HasValue) { account.AccountAttributes.Add(new AccountAttribute { AttributeValueID = attribute.ValueID.Value, CreatedDate = DateTime.Now, Active = true }); } else if (!attribute.ValueID.HasValue && attribute.AttributeID.HasValue && !string.IsNullOrWhiteSpace(attribute.Value)) { account.AccountAttributes.Add(new AccountAttribute { AttributeValue = new AttributeValue { AttributeID = attribute.AttributeID.Value, Value = attribute.Value, CreatedDate = DateTime.Now, UpdatedDate = DateTime.Now, Active = true }, CreatedDate = DateTime.Now, UpdatedDate = DateTime.Now, Active = true }); } } } else if (model.ID.HasValue && account.AccountAttributes != null) { foreach (var attribute in account.AccountAttributes.Where(pa => pa.Active)) { attribute.UpdatedDate = DateTime.Now; attribute.Active = false; } } } #endregion
#region Deactivate public void Deactivate(int id) { var account = EntityContext.Accounts.FilterByID(id).FirstOrDefault(); if (account == null) throw new NullReferenceException($"No account found with ID: {id}"); account.UpdatedDate = DateTime.Now; account.Active = false; EntityContext.SaveChanges(); }
#endregion } }
======= Clarity.Ecommerce.Services ======= This project contains all the
ServiceStack code to generate an API for communication between the UI
and Business Workflows. This project's folder is referenced as a virtual
application in the website and a configuration setting in the web.config
must be updated to the path where the virtual application full path is
set. This VA allows the website to directly access all the services
endpoints here without having to move them into a particular website
folder, create a symbolic link using Windows itself, or create a
separate IIS instance with a different subdomain. Example Routes
namespace Clarity.Ecommerce.Framework.Accounts { using System; using
System.Collections.Generic; using Models.Account; using
Models.Attribute; using Models.Generic; using ServiceStack;
[Route("/AccountTypes/", "GET", Summary = @"Use to get a account types")] public class GetAccountTypes : IReturn<AccountTypeModel> { }
[Route("/Account/Create", "POST", Summary = @"Use to create a new account")] public class CreateAccount : AccountModel, IReturn<AccountModel> { } [Route("/Account/{ID}", "GET", Summary = @"Use to get a specific account")] public class GetAccount : IReturn<AccountModel> { [ApiMember(Name = "ID", Description = "Account System Identification", IsRequired = true)] public int ID { get; set; } }
[Authenticate] [Route("/Account/Accounts/", "GET", Summary = @"Get All Accounts")] public class GetAccounts : IReturn<List<AccountModel>> { [ApiMember(Name = "CustomKey", Description = "Account Key", IsRequired = false)] public string CustomKey { get; set; } [ApiMember(Name = "Name", Description = "Account Name", IsRequired = false)] public string Name { get; set; } [ApiMember(Name = "AttributesToInclude", Description = "Attributes To Include", IsRequired = false)] public List<string> AttributesToInclude { get; set; } [ApiMember(Name = "ModifiedSince", Description = "Modified Since", IsRequired = false)] public DateTime? ModifiedSince { get; set; } }
[Authenticate] [Route("/Account/{ID}", "POST", Summary = @"Use to update a specific account")] public class UpdateAccount : AccountModel, IReturn<AccountModel> { }
[Authenticate] [Route("/Account/{ID}", "POST", Summary = @"Use to update the account associated to the user currently logged into the system")] public class UpdateCurrentAccount : IReturn<AccountModel> { [ApiMember(Name = "ID", Description = "Account System Identification", IsRequired = true)] public int ID { get; set; } [ApiMember(Name = "Name", Description = "Account Name", IsRequired = true)] public string Name { get; set; } [ApiMember(Name = "Email", Description = "Account Email", IsRequired = true)] public string Email { get; set; } [ApiMember(Name = "Website", Description = "Account Website", IsRequired = false)] public string Website { get; set; } [ApiMember(Name = "Fax", Description = "Main Fax For Account", IsRequired = false)] public string Fax { get; set; } [ApiMember(Name = "Phone", Description = "Main Phone Number For Account", IsRequired = false)] public string Phone { get; set; } [ApiMember(Name = "City", Description = "Account City", IsRequired = false)] public string City { get; set; } [ApiMember(Name = "PostalCode", Description = "Account PostalCode", IsRequired = false)] public string PostalCode { get; set; } [ApiMember(Name = "State", Description = "Account State", IsRequired = false)] public int State { get; set; } [ApiMember(Name = "Country", Description = "Account Country", IsRequired = false)] public int Country { get; set; } [ApiMember(Name = "Address1", Description = "Account Address 1", IsRequired = false)] public string Address1 { get; set; } [ApiMember(Name = "Address2", Description = "Account Address 2", IsRequired = false)] public string Address2 { get; set; } [ApiMember(Name = "ImageFileAttributes", Description = "Image File Attributes", IsRequired = false)] public List<FileModel> ImageFileAttributes { get; set; } [ApiMember(Name = "Attributes", Description = "Attributes", IsRequired = false)] public List<AttributeModel> Attributes { get; set; } }
[Authenticate] [Route("/Account/Current/", "GET", Summary = @"Get account for the current user logged in")] public class GetCurrentAccount : IReturn<AccountModel> { }
[Authenticate] [Route("/Account/Current/Remove", "POST", Summary = @"Remove account for the account of the user currently logged into the system")] public class RemoveCurrentAccount { }
[Authenticate] [Route("/Account/{ID}/Remove", "POST", Summary = @"Remove a specific account from the system")]
public class RemoveAccount { [ApiMember(Name = "ID", Description = "Account System Identification", IsRequired = true)] public int ID { get; set; } }
[Authenticate] [Route("/Account/Receivable/", "GET", Summary = @"Get All Accounts Receivable")] public class GetAccountsReceivable : IReturn<List<AccountsReceivableSearchResultModel>> { }
[Authenticate] [Route("/Account/Payable/", "GET", Summary = @"Get All Accounts Payable")] public class GetAccountsPayable : IReturn<List<AccountsPayableSearchResultModel>> { }
} Example Services namespace Clarity.Ecommerce.Framework.Accounts {
using System; using System.Collections.Generic; using System.Linq; using
Models.Account; using Models.Generic; using Shared; using ServiceStack;
public class AccountService : ClarityEcommerceServiceBase { #region Read public AccountModel Any(GetAccount request) { return Workflows.Accounts.Get(request.ID); }
public List<AccountModel> Any(GetAccounts request) { return Workflows.Accounts.Search(request.CustomKey,request.Name); }
public List<AccountTypeModel> Any(GetAccountTypes request) { return Workflows.AccountTypes.Search(); }
public AccountModel Any(GetCurrentAccount request) { return Workflows.Accounts.Get(CurrentUserName); }
public List<AccountsReceivableSearchResultModel> Any(GetAccountsPayable request) { return Workflows.AccountsReceivable.Search(new AccountsReceivableSearchModel()); }
public List<AccountsPayableSearchResultModel> Any(GetAccountsReceivable request) { return Workflows.AccountsPayable.Search(new AccountsPayableSearchModel()); } #endregion
#region Create public AccountModel Any(CreateAccount request) { return Workflows.Accounts.Create(request);
} #endregion
#region Update public AccountModel Any(UpdateAccount request) { return Workflows.Accounts.Update(request); }
public AccountModel Any(UpdateCurrentAccount request) { var currentUserName = CurrentUserName; if (!string.IsNullOrWhiteSpace(currentUserName)) { var account = Workflows.Accounts.Get(currentUserName); if (request.ImageFileAttributes == null) { request.ImageFileAttributes = new List<FileModel>(); } if (account == null) { var curAccount = new AccountModel { Name = request.Name, CustomKey = currentUserName, Attributes = request.Attributes, Images = request.ImageFileAttributes.Select(i => new FileModel { ID = i.ID, Name = i.Name, FileName = i.FileName, IsDefault = i.IsDefault }).ToList() }; List<FileModel> accountImages; lock (RecentUploadedFiles) { accountImages = RecentUploadedFiles.Where(f => f.Type == FileEntityType.AccountImage).ToList(); RecentUploadedFiles = RecentUploadedFiles.Where(f => f.Type != FileEntityType.AccountImage).ToList(); } curAccount.Images.AddRange(accountImages); Workflows.Accounts.Create(curAccount); } else { var curAccount = new AccountModel { ID = account.ID, Name = request.Name, Attributes = request.Attributes, Images = request.ImageFileAttributes.Select(i => new FileModel { ID = i.ID, Name = i.Name, FileName = i.FileName, IsDefault = i.IsDefault
}).ToList() }; List<FileModel> accountImages; lock (RecentUploadedFiles) { accountImages = RecentUploadedFiles.Where(f => f.Type == FileEntityType.AccountImage).ToList(); RecentUploadedFiles = RecentUploadedFiles.Where(f => f.Type != FileEntityType.AccountImage).ToList(); } curAccount.Images.AddRange(accountImages); return Workflows.Accounts.Update(curAccount); } } return null; } #endregion
#region Deactivate public void Any(RemoveAccount request) { Workflows.Accounts.Delete(request.ID); }
public void Any(RemoveCurrentAccount request) { throw new NotImplementedException(); } #endregion
======= Clarity.Ecommerce.UI ======= This project contains the core UI
code for both the store and admin portals and their related Angular
directives. This project's folder is referenced as a virtual directory
in the website and a configuration setting in the web.config must be
updated to the path where the virtual directory is set. This VD allows
the website to directly access all the files here without having to move
them into a particular website folder or create a symbolic link using
Windows itself. Client specific code should not be input to this
project, instead all storefront controls have a Transclude process
where-in the front end developer can specify a different location to
pull the HTML layout content file which overrides the base path. The
base path file must contain only the bare minimum content of what tags
are available, though not in any particular order or layout.
What is a Summary Tag? A requirement in the is that all C# code must
have Summary Information Tags. A Summary Information Tag (Summary Tag)
is Coding Standards a form of formal documentation used by developers to
outline what a piece of code (file, property, class or function) is for.
These tags are readable by various IDEs like VS's Intellisense feature
and are often compiled into external resources to assist with creating
Help documentation. What is Atomineer? Atomineer is one of several
plugins that assist developers with the tedium of documenting their
code. The difference between Atomineer and several of their competitors
is that Atomineer uses strong, customizable language heuristics to
generate summary tags for you, as well as ensuring that the existing
tags are uniformly formatted throughout your full solution. While
Clarity only utilizes Atomineer for the DocXml standard of documenting
C# code, they support a variety of languages and a variety of
standards. Atomineer is a Licensed product meaning that each developer
which needs a license to use it (after a 30 day trial) will need to
purchase a license. Clarity will order licenses for all Back End
developers and ensure that the licensing subscription is maintained.
Please contact Chris or James G. for assistance with getting a license
after your 30 day trial is over. Example Summary Tag Open a C# solution
in Visual Studio and create a new C# class file. Paste the following
contents in that file: namespace
RepositoryPattern.BusinessWorkflows.Authors { using System; using
System.Collections.Generic; using System.Linq; using
Interfaces.BusinessWorkflows; using Interfaces.DataModels; using
Interfaces.Mappers; using Interfaces.Models; using
Interfaces.Repositories; using Interfaces.SearchModels;
public class AuthorsBusinessWorkflow : IAuthorsBusinessWorkflow { public AuthorsBusinessWorkflow(IAuthorsRepository authorsRepository, IAuthorMapper authorMapper) { AuthorsRepository = authorsRepository; AuthorMapper = authorMapper; } #region Private Variables private IAuthorMapper AuthorMapper { get; } private IAuthorsRepository AuthorsRepository { get; } #endregion
#region Read public IAuthorModel Get(int id) { BusinessWorkflowBase.ValidateRequiredID(id); return AuthorMapper.MapToModel(AuthorsRepository.Get(id)); } public IAuthorModel Get(string key) { BusinessWorkflowBase.ValidateRequiredKey(key); return AuthorMapper.MapToModel(AuthorsRepository.Get(key)); } public List<IAuthorModel> Search(IAuthorSearchModel searchModel, bool asListing = false) { var results = AuthorsRepository.Search(searchModel); return asListing ? results.Select(AuthorMapper.MapToModelListing).ToList() : results.Select(AuthorMapper.MapToModelLite).ToList(); } #endregion #region Create public IAuthorModel Create(IAuthorModel model) { // Validate model BusinessWorkflowBase.ValidateIDIsNull(model.ID); BusinessWorkflowBase.ValidateRequiredString(model.Name, nameof(model.Name)); // Search for an Existing Record (Don't allow Duplicates var results = Search(AuthorMapper.MapToSearchModel(model)); if (results.Any()) { return results.First(); } // Return the first that matches // Map model to a new entity var newEntity = AuthorMapper.MapToEntity(model); newEntity.CreatedDate = BusinessWorkflowBase.GenDateTime; newEntity.UpdatedDate = null; newEntity.Active = true; // Add it AuthorsRepository.Add(newEntity); // Try to Save Changes AuthorsRepository.SaveChanges(); // Return the new value return Get(newEntity.ID); } #endregion #region Update public IAuthorModel Update(IAuthorModel model) { // Validate model BusinessWorkflowBase.ValidateRequiredNullableID(model.ID); BusinessWorkflowBase.ValidateRequiredString(model.Name, nameof(model.Name)); // Find existing entity // ReSharper disable once PossibleInvalidOperationException var existingEntity = AuthorsRepository.Get(model.ID.Value); // Check if we would be applying identical information, if we are, just return the original // ReSharper disable once SuspiciousTypeConversion.Global if (AuthorMapper.AreEqual(model, existingEntity)) {
return AuthorMapper.MapToModel(existingEntity); } // Map model to an existing entity AuthorMapper.MapToEntity(model, ref existingEntity); existingEntity.UpdatedDate = BusinessWorkflowBase.GenDateTime; // Update it AuthorsRepository.Update(AuthorMapper.MapToEntity(model)); // Try to Save Changes AuthorsRepository.SaveChanges(); // Return the new value return Get(existingEntity.ID); } #endregion #region Deactivate public bool Deactivate(int id) { BusinessWorkflowBase.ValidateRequiredID(id); // Find existing Entity var existingEntity = AuthorsRepository.Get(id); if (existingEntity == null) { throw new InvalidOperationException($"Could not find an entity with id {id} to deactivate it"); } // Do the Deactivate return Deactivate(existingEntity); } public bool Deactivate(string key) { BusinessWorkflowBase.ValidateRequiredKey(key); // Find existing Entity var existingEntity = AuthorsRepository.Get(key); if (existingEntity == null) { throw new InvalidOperationException($"Could not find an entity with key {key} to deactivate it"); } // Do the Deactivate return Deactivate(existingEntity); } protected bool Deactivate(IAuthor entity) { // Deactivate it AuthorsRepository.Deactivate(entity); // Try to Save Changes AuthorsRepository.SaveChanges(); // Finished! return true; } #endregion #region Remove public bool Remove(int id) { BusinessWorkflowBase.ValidateRequiredID(id); // Find existing Entity var existingEntity = AuthorsRepository.Get(id); // Do the Remove return Remove(existingEntity); }
public bool Remove(string key) { BusinessWorkflowBase.ValidateRequiredKey(key); // Find existing Entity var existingEntity = AuthorsRepository.Get(key); // Do the Remove return Remove(existingEntity); } protected bool Remove(IAuthor entity) { if (entity == null) { return true; } // No entity found to remove, consider it passed // Remove it AuthorsRepository.Remove(entity); // Try to Save Changes AuthorsRepository.SaveChanges(); // Finished! return true; }
#endregion } }
Don't worry about all the unrecognizable symbols, they don't impact this
example. You can see here we have some comments inside the functions but
no summary tags. Though this code is well-formed and appears
well-documented, it would actually fail Code Review because there are no
Summary Tags. To go about adding the first Summary Tag. Click on line
12, where there is a blank space between the Usings and the Class
declaration. Press Enter to make a new line and then press / three times
in a row. By default, without Atomineer, the following text will be
created by Visual Studio: /// <summary> /// /// </summary> public class
AuthorsBusinessWorkflow : IAuthorsBusinessWorkflow You can see that this
is just an empty summary tag. You would now need to type in a summary of
what this class is for between the <summary> and </summary> tags like
this. /// <summary> /// A business logic layer for Authors. ///
</summary> public class AuthorsBusinessWorkflow :
IAuthorsBusinessWorkflow Now, imagine you need to do this for every
Class, Property, Function, Enum, etc in the entire code-base when there
are none. That would be tedious and time-consuming. In fact, a lot of
what you would write is really just an expanded form of what the item's
name is. It's really only where there is special logic happening that
you need to expand the documentation. With Atomineer installed, you
could click on the Class name (or anywhere on that line) and instead of
pressing / three times in a row, you would press Ctrl+Shift+D. This
would trigger Atomineer to document the line using it's heuristics
instead. Here is what Atomineer writes if I remove the summary tag we
just made and let it do it itself: /// <summary>The authors business
workflow.</summary> ///
<seealso cref="T:RepositoryPattern.Interfaces.BusinessWorkflows.IAuthorsBusinessWorkflow"/>
public class AuthorsBusinessWorkflow : IAuthorsBusinessWorkflow Ok, so
not the same as what we would have written in the summary tag itself but
you can see it directly relates to what the class name is. Also, it's
telling you in documentation that this class implements a specific
interface and where tho find that information with a <seealso/> tag. If
you go to another place in the code and start typing var w = new
AuthorsBusinessWorkflow(); in Visual Studio, the Intellisense would come
up automatically and provide a tooltip that says "The authors business
workflow." with a second part of the tooltip that would like over to the
documentation coming from the Interface that this is implementing and
summary tag's content. its So now we see more information getting
pre-populated by Atomineer than we would have done or even known to do
on our own. However, that just tagged this one item of thousands
throughout the solution. To document more, Atomineer has friendly
functions for doing more at the same time. To document the entirety of
the current file, press Ctrl+Shift+A then Ctrl+Shift+F. Suddenly, this
entire file is now documented with summary tags. We can review the tags
to make sure there's nothing extra we need to add and save the file.
There are additional commands which can be run from the Tools >
Atomineer Pro Documentation menu such as deleting all the tags from a
file and documenting an entire project or solution at once (these can
take a few minutes). Atomineer provides this functionality as well as
other customizations like an entire dictionary of abbreviations to
expand, such as Dnn to DotNetNuke. Atomineer uses a set of settings
files to maintain all of the customized documentation setups. To get a
copy of these settings, please see James G.
Other projects in the solution must be handled on a case-by-case basis.
The AuthorizeNET project is solely third party code and should not be
modified. Clarity.Ecommerce.Integrations will be soon renamed to
Clarity.Ecommerce.Providers and it's contents are only specific to
certain providers of information or calculations like Taxes or Shipping.
Clarity.Ecommerce.DNN is the DNN installer and is due to be retired in
favor of a better process. Clarity.Ecommerce.Demos is the SPA demos
website and should only be modified to demonstrate new features for the
Sales team Clarity.Ecommerce.Demos.DNN is a client project and should
only be modified to the Client's requirements. The selected client may
rotate based on key platform features currently in development.
Continuous integration (CI) is the practice, in software engineering, of
merging all developer working copies to a shared mainline several times
a day. It was first named and proposed by Grady Booch in his 1991
method, although Booch did not advocate integrating several times a day.
It was adopted as part of extreme programming (XP), which did advocate
integrating more than once per day, perhaps as many as tens of times per
day. The main aim of CI is to prevent integration problems, referred to
as "integration hell" in early descriptions of XP. CI isn't universally
accepted as an improvement over frequent integration, so it is important
to distinguish between the two as there is disagreement about the
virtues of each. In XP, CI was intended to be used in combination with
automated unit tests written through the practices of test-driven
development. Initially this was conceived of as running all unit tests
in the developer's local environment and verifying they all passed
before committing to the mainline. This helps avoid one developer's
work-in-progress breaking another developer's copy. If necessary,
partially complete features can be disabled before committing using
feature toggles. Later elaborations of the concept introduced build
servers, which automatically ran the unit tests periodically or even
after every commit and report the results to the developers. The use of
build servers (not necessarily running unit tests) had already been
practiced by some teams outside the XP community. Nowadays, many
organisations have adopted CI without adopting all of XP. In addition to
automated unit tests, organisations using CI typically use a build
server to implement continuous processes of applying quality control in
general - small pieces of effort, applied frequently. In addition to
running the unit and integration tests, such processes run additional
static and dynamic tests, measure and profile performance, extract and
format documentation from the source code and facilitate manual QA
processes. This continuous application of quality control aims to
improve the quality of software, and to reduce the time taken to deliver
it, by replacing the traditional practice of applying quality control
after completing all development. This is very similar to the original
idea of integrating more frequently to make integration easier, only
applied to QA processes. In the same vein, the practice of continuous
delivery further extends CI by making sure the software checked in on
the mainline is always in a state that can be deployed to users and
makes the actual deployment process very rapid. The following child
pages outline CI process instructions for TeamCity, Visual Studio Online
(VSO) and Team Foundation Server (TFS): (Video) Continuous Integration
Continuous Integration with TeamCity Continuous Integration with VSO-TFS
ContinuousIntegration Part I
Automated Build Process Logging Into TeamCity We use to manage the
automated building of our code repositories. TeamCity To log into
TeamCity, navigate to on builda. our TeamCity server
Once you login, you'll see something like this: 1. 2. Here you'll be
able to view when the last build occurred for your specific project,
kick-off an ad-hoc build, view changes since a last build, and much
more. The objects are organized into Projects - Projects own builds and
are a helpful way to organize multiple build configurations. You should
have a 1 to 1 mapping of Projects to Clients. Projects also own Build
Configuration Templates - which are a helpful way to get started.
Projects on TeamCity's wiki Build Configurations - These are the nuts &
bolts of the builds & typically relate to a specific repository in
Stash. In the Configuration Settings for these objects you can add extra
steps to the build such as migrating the successfully built code onto a
staging server. This also controls the unit testing, dependency
controls, and branch logic for kicking off extra processes during the
build. Here's what TeamCity has to say Build Agents - These are
individual build worker threads that can consume one build configuration
at a time. For more info here's TeamCity's wiki page on Build Agents
Adding a New DNN Website Build Configuration coming soon! Adding a New
eCommerce Platform Build Configuration coming soon! Starting the
TeamCity Server Remote Desktop in to our TeamCity server currently at
http://10.10.30.81:8080/ Open a command prompt and navigate to
C:\TeamCity\bin by typing cd\teamcity\bin type and hit Enter. Two
Java command windows should open and initiate the TomCat server &
TeamCity instance. runAll.bat start
Set up a CI build Your team can minimize errors and increase quality by
integrating the code as frequently as possible and then building and
testing the result. You can define a build process to support this
strategy, known as continuous integration (CI). After this is done, you
and your team can determine as quickly as possible that a check-in has
broken the build or caused a test to fail. Define a build process to
support continuous integration Improve the function and performance of
the build process Take next steps Dig deeper Define a Build Process to
Support Continuous Integration In , make sure you are (Keyboard: Ctrl +
0, C), and then open the page (Keyboard: Team Explorer connected to the
team project Builds Ctrl + 0, B). Choose the link or select a build,
open its context menu, and choose . New Build Definition Edit Build
Definition 2. 3. 4. 5. 6. 7. 8.
Tip
If a TF225001 error message appears, . configure a build controller On
the tab, choose . Trigger Continuous Integration
Tip
If your developers have to wait too long for their check-ins to build,
you might want to choose instead. This trigger Rolling builds causes the
build system to build multiple check-ins together. See . Use the Rolling
builds trigger On the tab: Source Settings
In the table, specify the version-control folders that contain the files that your build process requires. TFVC: Working folders
Tip
To ensure that your build process functions correctly and to improve
performance, include all folders, and only these folders, that contain
files that your build process requires. For more information about how
to specify these folders, see Work with .build workspaces
In the list, specify the repository and the branches that contain the files that your build process Git: Monitored branches requires. You can use wildcards. For example, you could specify to monitor the and refs/heads/feature* refs/heads/featureA refs/ branches.heads/featureB To improve performance, on the tab, choose . Build Defaults This build does not copy output files to a drop folder On the tab, in the table under , specify the solutions or code projects that you want to build. Process Build process parameters Build On the tab, set the build process parameters to ensure that check-ins meet the specific standards of code quality for your team Process without delaying your developers unnecessarily.
For more information, see later in this topic. Improve build process
function and performance Specify build process options on the other
tabs. For more information, see . Create or edit a build definition
Improve build process function and performance To minimize the time that
is required to process the build, you should consider following these
guidelines when you specify values for the build process parameters on
the tab. Process TF Version Control or Git Clean workspace or : For
faster performance, set this value to . This setting might cause your
team to miss some Clean repository False types of defects, such as those
introduced during refactoring. Build
Configurations If you leave this parameter empty, the default platform
and configuration is used for each solution and project. To optimize
performance, adhere to the following guidelines: If a
platform-configuration pair builds more quickly than other pairs,
specify it in this parameter. Specify as few platform-configuration
pairs as possible. Clean build For faster performance, set this
parameter to False. This setting might cause your team to miss some
types of defects, such as those introduced during refactoring.
Build, Advanced
Perform Code Analysis For faster performance, set this value to . Never
Test, Advanced
Disable tests For faster performance, select . True If your code must
pass certain tests, select , and then define a set of tests to run in
the build. You can improve performance False by running only the tests
that you require. To designate those tests, filter them by either
category or priority. For more information, see . Run tests in your
build process
Publish Symbols
Path to publish symbols For faster performance, leave this value empty.
Advanced Agent Settings Name Filter –or– Use either a build agent name
or a tag to bind this build definition to a build agent that is designed
:Tags Filter specifically for running this build. The build agent should
run on hardware that is sufficiently powerful to process this build
quickly enough to meet your team's performance expectations.
Maximum Execution Time Set this value to a reasonably small number. For
example, 15 minutes might work for your team, but eight hours is
probably too long.
For more information about Default Template build process parameters,
see . Use the Default Template for your build process
Try this next
Make sure everyone on your team or early and often. checks in (TFVC)
pushes (Git version control) Run tests in your build process
Dig deeper
Set up build notifications if you want to be notified when a CI build is
completed. Use a gated check-in build process to validate changes if you
want to block check-ins that would break the build or fail your tests.
Overview This document is intended to provide guidelines for the
development processes of the eCommerce platform. The process is designed
to be light weight and efficient while adhering to current industry
standards. Although this document may not capture 100% of the scenarios
that may be encountered throughout the development process, this
document is to be considered a living document that may be updated in
the future to document and unforeseen. The format of this document will
focus on the high level processes initially then explore the details of
each process in sequential order. Any miscellaneous, but relevant
processes will be amended towards the end unless another logic order is
more ideal. Life-cycle The development lifecycle is modeled after agile
product development practices with a scrum management process. In the
figure below, 10 key high level processes are identified for managing
the development processes of the eCommerce platform starting with
platform road mapping. For each key process, the roles that are involved
in that process are identified in the figure below. Roles Sales The
sales role is filled by either the active Vice President of Sales or a
sales team member tasked with providing input for the direction the
platform from the sales team. The primary function of this role is to
provide feedback in the product development process that will help shape
the platform into the ideal product to sell in the target market. Sales
also follows up with the client currently which will provide feedback
for the improvements on existing features that are needed. Marketing The
marketing role is filled by the active executive from the marketing
department. This role is intended to provide insight on the competitive
landscape and the ideal target market to develop feature or to fill
voids in certain market areas. Firm Partners Firm partners are roles
that have equity interest in the firm, such as the CEO. The partner
roles are required for the platform development process to ensure firm
resources are used efficiently and the product direction is in line with
the vision for the firm. Platform Lead The role of the platform lead is
to be the deciding factor in the technical direction of the platform.
This role also manages the key parts of the development process to
ensure quality, consistency, and technical support or guidance to other
development members. This role is intended to help knock down
development roadblocks to help ensure progress. Management Management
includes development managers for the front and backend to ensure
adequate resources are allocated to meet timelines. Project Management
The project management role is to ensure timelines and expectations are
within reason. Senior Development Senior development roles are any
developer positions containing senior titles. These roles are vital in
the process to provide key architectural and technical insights for the
products technical direction. These roles also help in the development
the features of the platform and improve development processes.
Developers Developers provide the technical skill sets to create the
product features. QA Members QA members review the finish development of
all features to ensure product issues do not make it to clients.
Stakeholders The stakeholders are responsible for providing insight and
details for specific tasks. This role could be comprised of either an
internal employee or designated customer. Key Process Platform
Development Road Mapping The road mapping process is designed to
identify all features need for a commercially viable product and
prioritize them based off business and technical needs. This process
takes the form of a quarterly meeting between all roles involved. Prior
to the meeting each individual is required to compose a list of newly
identified features and send them to all participants. Each newly
identified feature should contain a short description of the business
needs, a priority, and a description of the functionality required by
each feature. During each meeting the group reviews, discusses, and
approves new features. The group will also review existing features and
decide whether to demote them from the roadmap. Once the list is
approved each road mapping iteration the top priority features will be
grouped in to 2 or 3 sequential releases in which the releases will be
developed. Release Cycle A release cycle is the development process to
complete a group of features from the roadmap that has already been
defined for the release by the road mapping committee. Each release
starts off with reviewing the individual features assigned to the
release and then defined into tasks with functional and technical
details in VSO, the release management tool. Once all features of the
release have been broken into concise and manageable tasks, the task are
then organized into two or more sprints, about two weeks long each,
which make up the release. Based on the amount of effort and resources
available a timeline will be determined for the series of sprints to be
completed by to calculate a release date. After the sprints and timeline
are solidified a sprint cycle may begin. Sprint Cycle The sprint cycle
is the actual development process of the tasks assigned to a sprint. The
cycle starts off with a planning meeting to finalize the details of the
sprint then moves into a setup of the sprint and feature development.
After each feature has been developed, a QA member or stakeholder will
review the wok completed to make sure it functionally satisfies the
business needs. Once the business needs have been met for a feature, the
code developed is reviewed by peers to ensure quality and best
practices. When all the features have been completed, the new features
developed in the sprint will be reviewed one more time prior to updating
the release branch with the latest. After the sprint development has
been completed, a sprint retrospect is performed to assess what worked
well, what didn't work well, and what needs to change for the next
sprint. Planning During the sprint planning tasks are reviewed to make
sure the timeline is realistic. Any adjustments to the sprint are made
at this time. The only exceptions to adjusting the items being worked on
in a sprint are if urgent business needs have been submitted to crash
the development schedule or sprint items have been completed ahead of
time. When reviewing the sprint items, there are several things that
need to be reviewed or provided. Below is a validation list for the
sprint items in VSO. Sprint Item Validation Check List Brief summary of
the task is provided A subsystem is identified Priority is established A
detailed description or sub tasks that make up the task are provided
Estimate (Original Estimate in VSO) Stakeholder must be provided that is
the business expert for the requested feature Sprint assigned Epic link
provided After all items have been reviewed and pass the criteria, the
time required to develop each item of the sprint and available resources
should be reviewed to verify enough resources have been allocated to the
sprint. When all the details have been solidified and risks have been
identified then the sprint may begin. Pre-Sprint Setup The sprint set up
is composed of a few tasks that need to be performed prior to each
sprint. Below is a list that details the tasks need prior to starting a
sprint. Pre-Sprint Setup Start Sprint Verify current release state is
build-able and tagged Create new release branch if start of new release
Verify environments need are set up prior (DB, Dev servers) Development
Features Feature developers are responsible for the actual development
and implementation of the requested feature. In order to start
developing a feature, the sprint must be started and an item must be
assigned. QA / UAT During the QA process, a QA member or stakeholder
will review the newly completed feature and verify that the expected
functionality is working correctly. Ideally a separate environment is
set up for this review for the QA member or stakeholder to review the
feature. During this time, adjustments may be needed in order for the
feature to be acceptable for a completed status. Peer Review / Sign off
When the Task has been marked for completion, the developer of the
feature will need to send an email to one or more peers detailing the
change and files. If the peer, approves of the implementation then the
code can be merged into the sprint. If the peer does not approve, then
the peer needs to detail a more ideal implementation or note any
adjustments. Once the code has been deemed to be in good standing then
it can be merged back into the release branch. Retrospect After all
tasks have been completed or the sprint timeline has finish, then a
sprint retrospect needs to be completed. This can take the form of a
meeting or an email, but the following items need to be detailed out by
the team prior to starting another sprint cycle. Retrospect items What
worked well? What didn't work well? What do we need to change? Or how
can we fix what did not go well. Tag Release Branch 1. a. 2. a. i. b. i.
ii. iii. iv. v. vi. c. i. ii. iii. iv. v. d. i. ii. iii. e. i. ii. f. i.
3. a. b. i. ii. iii. iv. v. c. i. d. i. ii. iii. iv. e. i. f. i. 4.
After each sprint is completed, the platform development lead needs to
ensure all features of a sprint have been merged into the release
branch. If the sprint is the last sprint of a release then the platform
lead needs to merge the release branch into the trunk. At this time, a
tag needs to label the completion of each release and sprint in source
control to easily identify it for future reference. The Platform lead
needs to ensure each merge into release or trunk is buildable. All trunk
merges must be production ready.
NA ?
(Video) What A Good QA Testing Plan Should Include CEF Website QA
Checklist
NA ?
The below guide will help team members with the eCommerce Website QA
process Step-by-step guide Recommended areas to confirm eCommerce Site
functionality: API Can you access the API URL / endpoints - for example
www.devsite.us/DesktopModules/ClarityeCommerce/API Storefront Sample
Data Does the product page show demo products Catalog Is there a working
product catalog page Does the category selector work Can you link
directly to a product category from the nav Can you click on a product
and be taken to the product detail page Does the page selector work Do
the Items per page work Product Detail Does the product detail page show
the correct price and product attribute selectors Does the product zoom
work Do the related products appear Does the product gallery work Does
the add to cart button work Cart Does the view cart template work and
update when an Item is added Can you increase quantity and clear the
cart Does the go to checkout link work Checkout Can you complete the
checkout process Can you log back in with the user used for checkout
User Dashboard Can you login and see the user dashboard after logging in
Admin Can you access the CEF admin dashboard Product Can you add a
product Can you associate to a category/categories Can you add related
products Can you assign product attributes Can you add product images
Category Can you create a category Sales Order Can you view past sales
orders Can you update a sales order Can you modify the payment status or
process payment Can you add new line items or process an RMA Accounts
Can you add/remove accounts Reports Can you access the reports Do the
reports provide meaningful/accurate data 4. a. b. i. Bug Reporting Use
the bug reporting standards to issue bug reports using the tools for
that particular project Note that typically the more information
provided the better someone can debug quickly Key items are browser
version, dimensions, page url, IP and date/time, highlight of the screen
/ screenshot, and notes Related articles (R) CEF Website Quality
Assurance Steps CEF Website QA Checklist
Clone Cloning is really the default behavior you'd expect from SVN. This
is how you'll create your local working copy. You don't need permission
via pull request to merge back (assuming you have r+w to the parent
repository). You should clone a repository if you plan to push your
changes back to the same repository where you have read+write access
privileges. You should also clone a repository if you are building a new
repository that is unique. Fork If you want to contribute code
enhancements to an existing repository, you should create a new
repository by creating a fork of the original. For example, if you want
to contribute minor bug fixes, enhancements, or new features to another
git project, the easiest way for those changes to be merged into the
original repository is with a Pull Request from a forked repository. See
Make a Pull Request on GitHub. Fork Documentation from Atlassian Note:
When you fork a repository, all metadata associated with the repository
such as commit messages, branches, tags, etc. are copied over to the new
repository so that it's an exhaustive duplicate of the repository and
all of its contents. Commits Recommended Resources: How Usability Works
Check out more about our software development processes here
NA ?
NA ?
Define Understanding Setting up environment
Select Team Explorer At the top, hover over the grey text to the right
of Home. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 1. 2. 3. 4. Select Projects
and My Teams Select Connect to Team Projects… Click Select Team
Projects… Select the project you want to connect to. Click Connect
Double-click the project name in the list under
clarity-ventures.visualstudio.com Click the link in the yellow banner to
clone the project. When done, double-click the appropriate solution from
the Solutions list. The solutions tab will populate with the local copy
of your file structure. Yes. It IS that easy. ;P
Pulling down When should someone pull down the branch?
When setting up initial clone. When code is ready to be sync'd with
branch (aka no breaks & ready to be merged onto other people's systems)
Steps for pulling down a branch
Save your work (if any) Commit your work (if any) Click on Sync in the
yellow banner after commit completes After reviewing Outgoing Commits,
click the Pull button
Commits How often should I make a commit? Any time you would hit the
save button. Really, you can't have too many of these How should I label
my commit? Don't worry about dates. Git takes care of that for us, but
do tell us what you're doing short and sweet… but not too short. Good
note implementing javascript fixes on MegaMenu mobile toggles' Bad note
"I did stuff to make things happen" Bad note "It little profits that an
idle king, By this still hearth, among these barren crags, Match'd with
an aged wife, I mete and dole Unequal laws unto a savage race, That
hoard, and sleep, and feed, and know not me. I cannot rest from travel:
I will drink Life to the lees: All times I have enjoy'd Greatly, have
suffer'd greatly, both with those That loved me, and alone, on shore,
and when Thro' scudding drifts the rainy Hyades Vext the dim sea: I am
become a name; For always roaming with a hungry heart Much have I seen
and known; cities of men And manners, climates, councils, governments,
Myself not least, but honour'd of them all; And drunk delight of battle
with my peers, Far on the ringing plains of windy Troy. I am a part of
all that I have met; Yet all experience is an arch wherethro' Gleams
that untravell'd world whose margin fades For ever and forever when I
move. How dull it is to pause, to make an end, To rust unburnish'd, not
to shine in use! As tho' to breathe were life! Life piled on life Were
all too little, and of one to me Little remains: but every hour is saved
From that eternal silence, something more, A bringer of new things; and
vile it were For some three suns to store and hoard myself, And this
gray spirit yearning in desire To follow knowledge like a sinking star,
Beyond the utmost bound of human thought. This is my son, mine own
Telemachus, To whom I leave the sceptre and the isle,— Well-loved of me,
discerning to fulfil This labour, by slow prudence to make mild A rugged
people, and thro' soft degrees Subdue them to the useful and the good.
Most blameless is he, centred in the sphere Of common duties, decent not
to fail In offices of tenderness, and pay Meet adoration to my household
gods, When I am gone. He works his work, I mine. There lies the port;
the vessel puffs her sail: There gloom the dark, broad seas. My
mariners, Souls that have toil'd, and wrought, and thought with me— That
ever with a frolic welcome took The thunder and the sunshine, and
opposed Free hearts, free foreheads—you and I are old; Old age hath yet
his honour and his toil; Death closes all: but something ere the end,
Some work of noble note, may yet be done, Not unbecoming men that strove
with Gods. The lights begin to twinkle from the rocks: The long day
wanes: the slow moon climbs: the deep Moans round with many voices.
Come, my friends, 'T is not too late to seek a newer world. Push off,
and sitting well in order smite The sounding furrows; for my purpose
holds To sail beyond the sunset, and the baths Of all the western stars,
until I die. It may be that the gulfs will wash us down: It may be we
shall touch the Happy Isles, And see the great Achilles, whom we knew.
Tho' much is taken, much abides; and tho' We are not now that strength
which in old days Moved earth and heaven, that which we are, we are; One
equal temper of heroic hearts, Made weak by time and fate, but strong in
will To strive, to seek, to find, and not to yield." Don't be like
Ulysses . It sucks to be Ulysses. Pushing When to push? Pushing code
should only happen when it is complete and ready to go to live. This
means you have tested it on your system and it works as expected. When
not to push When you're just wanting to save your work or someone wants
to see it. Commits are for saving and deadlines are for show (this part
may be argued, but legit serious about the commit part). Branching What
branch to work off of? Your branch should be a copy of main. When to
create a new branch? If you want to create your own sub-branches, you
are welcome to do so. This is usually done if you're working on multiple
features/functions and you want to have the ability to push one at a
time to main. It helps elminate merge conflicts. Thank Eric for that
suggestion. Why branches are used? So everyone can break their own
stuff. It's like the lock that keeps your sister's out of your room so
they can't break your toys. How to resolve conflicts When 2 developers
work on the same file, probably for different reasons, sometimes to fix
the same bug, eventually both persons will try to commit that file's
changes. The first person which gets it in will succeed normally, and
the second will be forced to pull the other commit down and Resolve a
Conflict. Various tools exist which can allow conflict resolution. In
most cases, if the two developers didn't alter the same set of lines
(dev A could have edited the top part while dev B did the bottom part),
then the conflict will basically resolve itself. You may even not have
to use the Conflict Merge tool in some of those cases. However, when 2
people have worked on the same part of the same file in different ways,
it must be manually merged. This is called Resolving a Conflict. 1. 2.
3. 4. You can see in the image above a common conflict merge tool and
the views it displays: The top left is 'Their' file, the file as it came
from the Git server The top right is 'My' file, with my local changes
The bottom shows the 'Merged Result' file, you will see a red area with
a ton of ?'s. It's telling you it doesn't know what to do with that area
of a file. You can review both the left and right files to figure out an
appropriate solution. You can either: Pick the left side's code and call
it done Pick the right side's code and call it done Pick both with
either side being first Write a totally different answer in the bottom
file When all the Conflicts in a file have been resolved (the bottom
file should have no red in it), you can now save the file and 'Mark the
file Resolved'. This tells Git the file is ready to be pushed back up to
the server with a Resolved Conflict. From here, make your commit
normally and push it to the server.
Sometimes when coding you need to make a change that will affect how
other developers need to pull this change into their environments beyond
the standard pull-merge-continue method. When this happens, clear
documentation must be included on what actions must be taken to perform
the upgrade at the time of pull-down and steps must be taken to share
this information with the team. Example Steven makes a commit that
includes a new EF Code-First Database Migration because he added a
column to the table schema for Products. His local copy of the database
has already been upgraded to the new schema but no other copy of the
database, such as the Staging environment or Emily's local copy has been
updated. When Stephen makes his commit, he needs to add the following to
his Commit Notes:
(Video) Create a Bug as a Client (Video) Reporting a Bug as a Clarity
Team Member Bug Prioritization How To Submit a VSO Bug Scrum Sprint
Planning
NA ?
The following key factors should be considered when prioritizing or
ranking bug fixes. A bug report that meets any of the following criteria
should typically be treated with urgency: Is it a bug that effects
multiple concurrent installations of the store? Is it a bug that
prevents a user from purchasing an item? Is it a bug that prevents an
administrator from performing fundamental store functions such as:
updating products, changing payment information or viewing transactions?
Does this bug prevent development in other (or all) key areas of a
project or projects? Will this bug have an immediate effect on an
important client deadline? Was this bug submitted or sponsored by a team
lead? Some Notes on Project Resolution Time How long a bug fix is
expected to take should be considered along with other factors. For
example, a bug fix that meets the criteria for urgent intervention and
that can be resolved very quickly should almost always be near the very
top of the list. Alternately, an issue that is not particularly urgent
and that will furthermore take a long time to address should be near the
bottom of any list. Lower Priority Factors Most of these can be readily
inferred from the urgent list. The bug only effects a single instance.
The bug can be worked around, other work can continue while it is in the
dock. The bug relates to a feature that does not prevent item purchase
or basic store administration.
Please use this process below to document any "bugs" with the CEF
platform. Step-by-step guide to add a bug to VSO Login to : VSO
https://clarity-ventures.visualstudio.com/ Find the project and go
into the tab within the project Work For the you can click this link to
be taken directly to the backlog: CEF-Product
https://clarity-ventures.visualstudio.com/DefaultCollection/CEF-Product/_backlogs
Click and change the type to New Item Bug Type the of your new and press
Title Bug Enter Open your new by double-clicking on the new row in the
and perform the following modifications to the Bug: Bug Backlog Assign
to Dustin Grant Add the project name as a using the auto-complete
feature to match associated items: eg- , Tag Protech UMC Select the best
fitting in the field Area Area Set the of this as it pertains to your
project. If it is blocking the ability to implement a critical site
feature, mark it as Severity Bug .1 - Critical That will be handled by
Dustin. NOTE: DO NOT SET PRIORITY. Write the reproduction steps with any
pertinent information to the field Repro Steps Best Practices 1. 2.
Provide detailed steps to replicate the bug being sure to include any
information that might be relevant. Provide full urls where applicable
to any web pages referenced. Provide full log in information if it is
needed to replicate your bug. Include any steps you have taken to
attempt to remedy or work around the problem. If it's a very higher
priority for you, explain why in your bug report. If anyone has special
knowledge of this bug, or has worked on it in the past mention them so
it can be assigned appropriately. Related articles (R) CEF Website
Quality Assurance Steps (R) Bug Prioritization (R) How To Submit a VSO
Bug CEF Website QA Checklist Bug Prioritization Showing first 5 of 6
results
In , the sprint planning meeting is attended by the product owner,
ScrumMaster and the entire Scrum team. Outside stakeholders may Scrum
attend by invitation of the team, although this is rare in most
companies. During the sprint planning meeting, the product owner
describes the highest priority features to the team. The team asks
enough questions that they can turn a high-level user story of the
product backlog into the more detailed tasks of the sprint backlog. The
product owner doesn't have to describe every item being tracked on the
product backlog. A good guideline is for the product owner to come to
the sprint planning meeting prepared to talk about two sprint's worth of
product backlog items. To make an example really simple, suppose a team
always finishes five product backlog items. Their product owner should
enter the meeting prepared to talk about the top 10 priorities. There
are two defined artifacts that result from a sprint planning meeting: A
sprint goal A sprint backlog A sprint goal is a short, one- or
two-sentence, description of what the team plans to achieve during the
sprint. It is written collaboratively by the team and the product owner.
The following are example sprint goals on an eCommerce application:
Implement basic shopping cart functionality including add, remove, and
update quantities. Develop the checkout process: pay for an order, pick
shipping, order gift wrapping, etc. The sprint goal can be used for
quick reporting to those outside the sprint. There are always
stakeholders who want to know what the team is working on, but who do
not need to hear about each product backlog item (user story) in detail.
The success of the sprint will later be assessed during the sprint
review meeting against the sprint goal, rather than against each
specific item selected from the product backlog. The sprint backlog is
the other output of sprint planning. A sprint backlog is a list of the
product backlog items the team commits to delivering plus the list of
tasks necessary to delivering those product backlog items. Each task on
the sprint backlog is also usually estimated. An important point to
reiterate here is that it's the team that selects how much work they can
do in the coming sprint. The product owner does not get to say, "We have
four sprints left so you need to do one-fourth of everything I need." We
can hope the team does that much (or more), but it's up to the team to
determine how much they can do in the sprint.
CREDIT FOR CONTENT ABOVE:
http://www.mountaingoatsoftware.com/agile/scrum/sprint-planning-meeting
What is it? A (SCN), or , is a document which records or authorizes a
change to a specific design. The reasons for Software Change Notice
change notice the change should also be recorded. Following sound
principles, control and documentation are necessary to ensure that
changes are built upon a known foundation and engineering approved by
relevant authorities. "[A] document approved by the design activity
that describes and authorizes the implementation of an engineering
change to the product and its approved configuration documentation".
There are detailed fields you can edit within the bug ticket to
incorporate the project the bug applies to, the severity (NOT PRIORITY)
and other details that will help with quickly identifying/replicating
and resolving the issue! 1. 2. 3. An SCN must contain at least this
information: Identification of what needs to be changed. This should
include the part number and name of the component and reference to the
drawings that show the component in detail or assembly. Reason(s) for
the change. Description of the change. This includes a drawing of the
component before and after the change. Generally, these drawings are
only of the detail affected by the change. List of documents and
departments affected by the change. The most important part of making a
change is to see that all pertinent groups are notified and all
documents updated. Approval of the change. As with the detail and
assembly drawings, the changes must be approved by management.
Instruction about when to introduce the change—immediately (scrapping
current inventory), during the next production run, or at some other
milestone. The term “change” includes changes to hardware, software, and
firmware that occur over the entire life of a product. Product changes
include those considered report-able and non-report-able. These changes
may be applied by a supplier, a customer, or a contractor retained by
the customer, depending on negotiated agreements. Fundamentally, the
customer’s goal is to ensure there is a process by which there is
accurate and efficient tracking and reporting of changes to products.
Changes are considered report-able when they affect the performance or
life span of a product. Such changes include any that affect the form,
fit, function, or the product technical specification (i.e.,
documentation) of the product. The desire for supplier or customer
trace-ability may result in a report-able change. Example SCN Note: The
following is just an example and not part of a real change notification
Simple Note for Release Change-log: Product schema now stores kit
information and relationship with a Kit Parent Product Full Details: To
support Product Kits as designed by Microsoft Dynamics GP's ERP system
which Clarity Connect supports pulling product and kit information from,
some changes needed to occur in the CEF schema and workflows. Three data
points have been added to the Product table: KitParentId: The identifier
of the core item that will be part of this kit. For instance if the kit
is 2 T-Shirts, one red, one white. This value would point at the Red One
as sold individually (if sold ind., if not then a product record would
still exist just not visible as part of the store for users). A second
record would point at the White one KitQuantityOfParent: How many of the
product that KitParentId points to would be included in this kit. For
instance a kit of 4 hard drives would specify 4 here. KitUnitOfMeasure:
The GP specified Unit of Measure, such as Each or Case. If the UofM is
Case and the Quantity is 4, then the kit contains 4 cases of the product
specified by KitParentId instead of 4 Units Workflows now support
pulling the product kit information from GP to CEF and creating the
appropriate relationships between the records. The store should display
the Kit item with specialized UI for stating that child items are part
of the Kit. Only the Kit item should be added to the cart as the ERP
system will assign the quantities of the kit parts for distribution
after sale. This schema and workflows change requires a Database update
which must be issued via EntityFramework Code First Update-Database
method, state a Target of GPAdjustments02 to specifically implement
these changes.
NA ?
Roadmap Contents Roadmap Contents Definitions Releases E: Stabilize
Product Sprint 1 – Baseline Product and turn off unstable features
Sprint 2 – Create testing and documentation Sprint 3 – Bug fixes and
product clean-up Sprint 4 - Stabilize Product while adding in
‘turned-off’ features Sprint 5 – Initiate and define roadmap and
development process. Sprint 6 – [Identified as an output from Sprint
5] ARCHIVE Release 04.02 – Mar. 2 - Apr. 17 , 2015 nd th Release 04.03
– Apr. 20 - Jun. 5 , 2015 th th Release 04.04 – Jun. 8 - Jul. 17 , 2015
(subject to change) th th Release 04.05 – Jul. 20 - Aug. 28 , 2015
(subject to change) th th Archive/Completed Release 04.01 – Nov. 24 –
Mar. 1 , 2015 th st Documents Definitions Releases – Targeting for 3
sprints per release. Noting that this isn’t set in stone but an
objective from the team. If this will not occur there will need to be a
separate meeting with the CEF business owners to review the adjustments
necessary if this requirement isn’t met. Format will be XX.XX for
release numbers. Sprints – By definition each sprint will have the
objective of a demonstrable set of code that is committed, tested and
available on the demo site at the end of each sprint. If this will not
occur there will need to be a separate meeting with the CEF business
owners to review the adjustments necessary if this requirement isn’t
met. Product Requirements Document (PRD) – requires a minimum of a
sitemap (per function), design wireframe (ideally graphical design),
functional bullet list of requirements and use cases/user stories for
validation. Business owner (and designer) produced item(s). Functional
Specification (FS) – detailed architectural requirements and plan for
where code/logic will live and how it will be formatting/setup. CEF
architect or developer produced item(s).
Releases Project Breakdown E = Epic, , R = Requirement, T = Task, , Q/C
= Questions/Comments F = Feature D = Deliverable E: Stabilize Product
Sprint 1 – Baseline Product and turn off unstable features F: Product
Demonstrable R: Implement functional Demonstrable from master branch T:
D: We hold a 2 hour long Demo to review ALL functioning features at
length C: Require Tim, Zach, Chris, Ron, James, Andy (observe), Dustin
for this meeting R: While pushing demo site Document all process from
Branch to Release D: Release Management Process for Demo site R: Remove
all non-functional UI feature from Admin access (leave code but comment
out) C: Add specific "TODO@Person" tags to these locations to determine
who is responsible for getting it working later, easier for that person
to find it in the code R: Document all features that are turned-off due
to instability D: Beginnings of new “Redo” Backlog List C: Document
projects where that feature is functional and could copy code from R:
Create Upgrade Plan D: Upgrade Instruction document R: Create Unit
Testing for all storefront controls D: 70% code coverage for all
storefront controls F: Solidify testing plans and core documentation R:
Complete a round of Functional (Click Through) testing documenting each
test and screen D: Use Cases and Test Cases Document D: Functional
Design Document R: Complete full QA (Code Review) of OOTB product D:
Full QA Checklist D: Technical Design Document F: Log and record Product
Bugs R: Add Existing Bugs to Sprint 3 Backlog D: Identified Bugs are
entered in detail to Sprint 3 R: Create Unit Testing for all Admin
controls and Sales Order and Product Workflows D: Tools identified and
Unit Testing document created F: Product Bug Fixes R: Fix Existing Bugs
found in Sprint 2 Backlog D: Identified Bugs are entered in detail to
Sprint 2 R: Create Unit Testing for Workflows D: Tools identified and
Unit Testing document created 1. a. i. 1. 2. 3. 4. 5. ii. 1. iii. 1. 2.
a. iv. 1. 2. b. c. d. 2. a. b. 3. a. F: Adding back previously unstable
features R: Using the Sprint 1 Redo Backlog list, take the
non-functional UI that was hidden and make each item visible as it
becomes functional D: Added features are added to Functional and
Technical Design Document v2 F: QA Release Management Process R: Merge
branch back to Master as up-to-date OOTB Product D: Validate and update
release management process F: Product Development Process definition R:
Strategic Projects are identified and prioritized R: Product Management
Process is defined T: Steven and Gray move time towards Product for
Feature Integration D: Create agreed upon guidelines for
cross-departmental involvement R: Features from Projects once released
for Clients are added to New Product Release Backlog. Here the Product
Team integrates the feature into the master branch R: Centralized
Documentation D: Functional Design Document v5 D: Technical Design
Document v5 D: Functional Testing Document v5 D: QA Checklist v5 D:
Release Management SOP v5 D: Use Cases v5 D: Test Cases v5 D: Sprint 6
Project Summary v5 Sprint 2 – Create testing and documentation Sprint 3
– Bug fixes and product clean-up Sprint 4 - Stabilize Product while
adding in ‘turned-off’ features Sprint 5 – Initiate and define roadmap
and development process. Sprint 6 – [Identified as an output from
Sprint 5]
ARCHIVE
Release 04.02 – Mar. 2 - Apr. 17 , 2015 nd th Admin All remaining
features built out from P4H Client project. Accounts Accounts Payable
Accounts Receivable Ratings and Reviews Account Management User Accounts
Sales Packing Slips Shipments Carrier Account Management Add shipping
providers prioritize based off client needs System Configuration screens
System collection management Finalize UI Designs Begin implementing the
new UI designs Testing and validation against these new features Connect
Finalize AX integration Begin Belle (Informix) integration Demo site 3.
a. b. c. d. i. ii. iii. iv. 4. a. b. c. d. 5. a. b. i. ii. iii. iv. v.
6. a. 7. a. b. 8. a. 1. a. b. 2. a. 3. a. 4. a. b. i. ii. iii. iv. 5. a.
b. 6. a. b. c. d. 7. a. 8. a. i. ii. iii. iv. v. b. i. ii. 9. a. b. c.
10. a. Inventory and move functionality from existing demo site into
core PRD/FS validation and initial location of the sites Ensure updated
with latest release items and validated by business owners Chris and Ron
QA and validate Functional spec docs and use cases Test cases Template
discovery documentation Implementation manageable items Documentation
Evaluate readthedocs.org Development process Extensibility Core Client
admin functionality Features Multi-linqual/Multi-currency Extend feature
set and fully validate: Reviews Recommended and similar
products/categories Improved filtering management User dashboard
Tracking and analytics integration Functional design documentation
Update with items for current and next release SEO Prerender.io Core
integration to Google Analytics Unit testing coverage C# coverage only
– target of 20% coverage Release 04.03 – Apr. 20 - Jun. 5 , 2015 th th
Automation Web deploy for local -> dev -> qa -> stage ->
prod initially in place for demo site. Note that some steps can be
removed for the time being. Needs to be “push of a button” simple deploy
for web app and data Run initial validation against the sandbox/demo
sites Admin Stand-alone capability – this ties closely with the item
“SAAS research” below Configurations Pull configuration related items
into the database. Settings, variables, etc. Demo site Ensure updated
with latest release items and validated by business owners. Chris and
Ron QA and validate Functional spec docs and use cases Test cases
Template discovery documentation Implementation managable items
Documentation Ensure coding standards documented for each key area of
the platform coding Upgrade process fully documented (manual process for
this release) Features Shipping providers Payment providers Tax
providers Customs/Duties providers (international) Functional design
documentation Update with items for current and next release Integration
Clarity Connect definition and restructuring Microsoft Dynamics GP
connector Netsuite connector SAGE connector Oracle connector SAP
connector Configuration and management screens Demo capability for an
integration Demo capability for API listing of the eComm and an
integration Refactoring Architecture updates completed merged and
validated C# Refactoring Work Caching mechanism Testing 10. a. b. c. 1.
a. b. 2. a. 3. a. b. c. d. 4. a. 5. a. 6. 7. a. b. c. 8. a. i. b. i. c.
i. d. e. 9. 1. a. 2. a. 3. a. b. c. i. ii. 1. a. b. c. 2. a. b. 3. a. 4.
a. b. c. Unit testing to 50% coverage Initial Client Side Framework
testing in place with 5% coverage Begin running stress testing and load
testing – very initial runs Release 04.04 – Jun. 8 - Jul. 17 , 2015
(subject to change) th th Connect CRM Prioritzation based on marketing
research (validate market size) Demo site Ensure updated with latest
release items and validated by business owners Documentation Developer
documentation – how to use the platform – modules, client side layer,
C# customization, etc System documentation and diagrams – where things
go and how they work. Best practices for integration and data
migration/storage for standard entities Help documentation – embedding
within the admin UI Demos/how-tos Functional design documentation Update
with items for current and next release Licensing and access control
Ability to control access to functionality that’s in place via licensing
controls (instead of via physical file changes) Maintenance Reporting/BI
Advanced reporting Advanced notifications and event based integration
points Improved UI for building and customizing event based BI and
advanced reporting Research SAAS research Enable initial demos with
capability for different domains for API/Service layer vs.
implementation layer and validate. Likely will require adjustment to
CORS or JSONP “Automated” upgrade Initial updates to upgrade process to
enable upgrade in under 30 minutes following standard steps between
releases 04.02 and 04.03 and further releases (i.e. this is an example
of two different releases) Storefront Stand-alone capability – this ties
closely with the item “SAAS research” below Begin proactively
researching for ways to build developer community Plan for/attend
development conference(s) Security Audit Release 04.05 – Jul. 20 - Aug.
28 , 2015 (subject to change) th th Demo site Ensure updated with latest
release items and validated by business owners Functional design
documentation Update with items for current and next release SAAS
implementation More mature implementation Validation and demos in place
Scalable model Possibly a "free" model if they use our payment processor
and up to X transactions Further cost buckets beyond that - etc.
Archive/Completed Release 04.01 – Nov. 24 – Mar. 1 , 2015 th st Demo
site Inventory and move functionality from existing demo site into core
PRD/FS validation and initial location of the sites Ensure updated with
latest release items and validated by business owners Architecture
updates completed merged and validated C# Refactoring JS updates: type
script, require Unit testing coverage C# coverage only – target of 20%
coverage Documentation Development process Extensibility 4. c. 5. a. b.
c. i. 6. a. 7. a. b. c. d. 8. a. 1. a. i. b. i. 2. Core Client admin
functionality Connect POC research and functional build Document
architecture Specific integration Microsoft AX Admin Mockups for new UI
SEO Prerender.io Friendly URLs for all default instances Per category
and product titles Core integration to Google Analytics Functional
design documentation Update with items for current and next release
eCommerce Pipeline Immediate Bottleneck Items Date Feature Hours (est.)
Client Category Notes 2015-05-02 AX MEF 50 MOB Connect Broken into
phases 1. Push data from AX to CEF, 2. Push data from CEF to AX, 3.
Final validation 2015-05-02 Demo Site 80 ALL Storefront Work with Noah
and Zach to enable MOB, BELLE, and other storefront ready implementation
of core catalog functionality 2015-05-09 SEO 35 ALL Storefront Implement
urls, unique per cat, subcat, product meta data (title, description,
keywords, h1), auto-generated sitemap 2015-05-16 Cart, Checkout, User
Dash. 80 MOB Storefront Work with Noah and Zach to enable MOB storefront
ready implementation of cart, checkout and core user dashboard
Brainstorm Latest Version Mobile Tech Connect AX MEF Storefront
SEO/Prerender 2. a. i. b. i. 1. ii. 1. 2. 3. iii. 1. 2. 3. 4. iv. v. c.
i. 1. 2. 3. a. i. b. i. 1. ii. 1. 2. 3. iii. 1. a. 2. c. i. 1. 4. a. i.
NA ?
Documentation for Developer and End User audiences will be completed on
the MadCap Flare software for publishing the documentation source to PDF
and online user documentation with minimal time and effort after
authorship. Flare allows for multiple output types, and tracks of
publishing using conditionals to steer the audience type and targets to
steer the publication to the web or print documentation environment for
the end user. For Clarity's purpose, the tracks will be per Version
number and the conditionals wi be used for delivering content to the
audience types. More information can be found in the software
documentation here: http://webhelp.madcapsoftware.com/flare10/ . The
authoring file(Flare Project) can be found on Dev B here:
C:\Data\Projects\ClarityInternal\Libraries\Documentation\V21\Clarity
eCommerce Framework.flprj The folder located at:
C:\Data\Projects\ClarityInternal\Libraries\Documentation\V21\ is
backed up into Stash so make sure to pull down, before you publish out
your new files with Flare, then push back into Stash. The menu structure
for the documentation will be broken down between the Framework, API,
Connect and Web UI. Development comments should be marked with
conditionals towards development and end user comments should be marked
with conditionals towards UI. Comments for both can be marked with both.
There are multiple methods of price calculations in the CEF platform,
depending on the customer's requirements. Please note that this is
independent of the Discounts section The Simple Method Most Clients
don't utilize an ERP system or other system to pull products in. They
just want a simple "this is my price, I might have a temporary Sale on
specific products every now and then". To meet those requirements we
have the following three fields: 1.PriceMsrp: Some websites also display
a 'Manufacturer's Suggested Retail Price'. This price is almost never
used in calculations but instead gives the illusion of a discount to the
customer. 2.PriceBase: The base price of the product, almost always used
in normal (not-in-a-current-sale) products and viewed on the product
details, catalog, carts and checkouts. 3.PriceSale: The sale price of
the product, when set with a value and with the IsSale flag for the
product turned on, this price will be displayed instead of the PriceBase
value. Example of how these three relate For example, you go to Kohl's
and on a pair of pants you see a tag that says the MSRP $49.99
(PriceMsrp), but Kohl's never charges you $49.9 they start their own
pricing at $29.99 (PriceBase). Kohl's is also having a sale that says
50% off so the sale price is $14.99 (PriceSale). What gets used in the
'Shopping Cart' is $14.99. We also had one client which also wanted what
they called a Reduction Price, this will not be part of the normal
platform but the Reduction price had the same relationship with Base
that MSRP did with base, it was a flat starting point for price
calculations (causing Price Base to be ignored). The Tiered Method
Other, especially larger, Clients will use an ERP system that allows
them to coordinate pricing levels across departments, knowledge of the
product transferring throughout the entire sales process. Some of these
clients still use the Simple Method as seen above and their data will be
transported as such. However the rest will use some form of Tiered
Pricing System. The Tiered Method covers this more advanced scenario
along with several others by proxy. There are four main components to
this method: the Price Tiers, the Account Price Points, the Product
Price Points and the Product Price Roundings. Note: In a future version,
this will be expanded to cover additional scenarios for tighter control
of the resulting prices. The Price Tier The Price Tier, also known as
the Price Level or the Price Key or Price Rule, is a simple table that
states the names of the different tiers. It does not contain any actual
price or cost modification rules and serves as a relationship point. The
Account Price Point Accounts are assigned a specific price tier which
they have access to, so there would be an Account Price Point record
that contains both the Price Tier's identifier and the Account's
identifier. Note: In a future version, Account Price Point will also
include a global % off value to used in all price calculations for the
account. Product Price Point The meat of the Tiered Method is handled in
the Product Price Points table. Each Product will be assigned one or
more Price Tiers with the following information: The Product Identifier
The Price Tier Identifier The % Markup from the Price Base (from the
Simple Method) The specific $ amount increased or decreased (can use
negative numbers) against the Price base A flag determining if the
change is % or $ based 2 Quantity values, a minimum and a maximum, to
specify that this price point is for a specific volume of units (default
1-2147483647) Product Price Rounding Tells the price calculator how to
round the price when there are too many decimal digits. How these three
work together to calculate a price Scenario 1, the Client offers special
reduced pricing to customers that they have built a relationship with.
Anyone that they have not only sees the full pricing on the website,
same for anonymous (not logged in) users. User "Anon E. Mouse" is not
logged in, the price of a wine bottle he sees on the website is $17.84.
That price was calculated by:
Product Price Base: $12.00 No Account as not logged in, so defaults to
Price Tier "WEB" The Product Price Point for "WEB" says Min-1 to
Max-2147483647 (basically any quantity) the Markup should be 32.72% The
price is calculated as 12.00 / (1 - 0.3272) = 17.8359096313912 The
Product Price Rounding for this product against "WEB" says Round Up to 2
Decimal Places Math.Cieling(17.835909631912 *100) / 100 = 17.84 Final
price is $17.84 User "Mybe St. Friend" is logged in and he has access to
the special LTL pricing, which has reduced markups. He sees $16.79 for
the same product that "Anon E. Mouse" saw. That price was calculated by:
Product Price Base: $12.00 Account is logged in, so pulling the Account
Price Point which said to use "LTL" The Product Price Point for "LTL"
says Min-1 to Max-119 (so there's different values for quantities 120+)
the Markup should be 28.5% The price is calculated as 12.00 / (1 -
0.285) = 16.78321678321678 The Product Price Rounding for this product
against "LTL" also says Round Up to 2 Decimal Places
Math.Cieling(16.78321678321678 *100) / 100 = 16.79 Final price is
$16.79 Now hold on, "Mybe" says he actually wants to buy 500 of these
bottles, does he get a bulk discount? On the product details page he
puts in 500 and sees a Volume price come out of $14.59 per bottle. That
price was calculated by: Product Price Base: $12.00 Account is logged
in, so pulling the Account Price Point which said to use "LTL" The
Product Price Point for "LTL" says Min-240 to Max-1439 (the one that
contains 500 in it's range) the Markup should be 17.75% The price is
calculated as 12.00 / (1 - 0.1775) = 14.58966565349544 The Product Price
Rounding for this product against "LTL" also says Round Up to 2 Decimal
Places Math.Cieling(14.58966565349544 * 100) / 100 = 14.59 Final price
is $14.59 per bottle