I have an MVC 4 based web app. Where I provide 2 login types, 1. Employee and 2. Customer. With Customer login, I present a dashboard and other stuff, about his orders, etc. With Employee login, I allow the employee to search for his customers and provide the ability to carry out certain customer specific tasks.
It is possible that, an employee after login can seach for a number of customers and fetch each of their details in multiple browser tab(s).
I am having difficulty in maintaining state for each tab, if I put the unique identifier of the customer in session, as the next subsequent request will overwrite the session!
To solve this, I have relied on a (dirty) viewbag based solution, where I set the customer number in viewbag in every view.
Is there an elegant solution to solve this? a known design pattern?
Related
What is the suggested approach to restrict a customer viewing a PLP, based on the user group assigned to the CategoryModel?
For example, let's say a category with code "c012345" is assigned to the user group "promoPreviewCustomers". I have two registered customers who are a part of the customergroup but only one customer is in the promoPreviewCustomers group.
Only the customer who is in a promoPreviewCustomers group, should be able to see the PLP of the category page c012345.
Our initial thought was to drive this through a personalisation rule within Commerce.
What are other people's thoughts on how this should be implemented within Spartacus, given that the product search API does not take into account the logged in customer?
Any restriction done only in Spartacus will be only for the UX as true restriction can only be done in the backend. Therefore, the best approach would be to drive this behavior with personalization within Commerce
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
How can I have access to bigcommerce's %%GLOBAL_CustomerId%% variable?
I create a sample template and logged in with as a user. That variable doesn't show up. Isn't it suppose to be a Global variable?
Background: I want to create an app for bigcommerce that can identify a user base on their customerID. If I can't grab that variable, you guys see any other way to work around this?
It's not immediately clear in the docs, but you can use %%GLOBAL_CurrentCustomerEmail%% anywhere on the template to get the email address of the currently logged in user.
If you need the customer's ID, then you can query the API with the email as a parameter.
Personally, I'd rather "trust" the customer's email as a point of identification, because you never know if the Bigcommerce ID's may get changed or not (example: Customers are deleted and then reimported, now having brand new ID's).
On a subject of security though, you cannot trust client side data, and should attempt to mitigate fraudulent requests through the use of a CSRF token or some similar measure. Otherwise, anyone can send you an email address and receive back a list of that person's favorite products -- golden information for say, a targeted advertising company, or just your suspicious next-door neighbor Joe who seems to always be conveniently checking his mail right when you get home from work, but never says anything when you walk by, not even a wave or a smile, despite the fact that you all have been neighbors for quite some time now. Like, should I say something? Hahaha, I kid I kid.
The issue I'm having in Dynamics CRM 2013 is the ability to assign activities or appointments to a team and have those cascade downward into individual users. The end goal here would be after assigning a lead or activity to a team, the users within that team would receive notifications, emails, etc. and those records would integrate with their 'my' sections of CRM.
The issue I see with this is that only 1 'Owner' can be set for a new record in all areas of CRM, and the 'my' sections are based off of the Owner. Therefore the users within the team won't be notified.
We are currently using a service to pull from an existing database and populate CRM, assigning new leads to a Team which contains multiple users.
Does anyone have a recommended method to do this?
Thanks for your time.
Either give the users a view of "Leads owned by Teams of which I am a member" or possibly use Queues, which are pretty much designed for the scenario you describe.
New items assigned to a Team will be added to the Team's Queue. Users can see all Queue Items not yet being worked on (from all Queues they have access to, including all Teams they are members of). A user can "work on" an item to show they are dealing with it so it no longer appears in this list of items to be worked on, and instead appears in their own list of items they are working on. A user can either complete the item or 'release' it back into the queue.
Queues can contain items of different types, eg Leads, Tasks, Cases etc.
I am building a system with 2 types of users. Buyers and Sellers. After some thought i decided to make completely separated models for these(dont know yet if that was good idea)
I now need to build a session controller and thinking these should be separate as well. One for each model.
BUT then im thinking. If a logged in Buyer by accident hits part of the Seller area, the seller controller would check if logged in (and since the user is not seller it would be no), then redirect to the login for the seller, which would be very confusing for the buyer. (did that make sense?)
Should it be split up to 2 separate applications sharing the same database?
Any recommendations?