As part of my work I need to test several flows between multiple accounts.
For that I would like to create multiple Facebook accounts and define specific relationships between them.
I would like to know if this is possible (even manually) in order to not abuse Facebook systems, and if so, then how.
Related
Is there any way that we can collect data by asking the questions when someone wants to join the group. And we collect the data when we approve the joining request or sometimes programmatically?
Could you please elaborate on how we can use Facebook GRAPH API for fulfilling the above purpose?
Check out GroupTrack CRM...it's a CRM that is integrated into Facebook via a Chrome Extension. It does exactly what you asked (one click to approve individual or all pending members while also saving their answers to your questions and adding them to the CRM), along with a ton of other awesome stuff.
Keep notes and tags, track sales funnel stages, bookmark posts and comments, set follow up tasks with reminders, and more across unlimited Groups. Everything is synced in real time with a web app as well, so you can access your contact information from anywhere, plus it can be set up to integrate with external systems (Google Sheets, Streak, and Kartra at the moment, but many more to come).
Lastly, GroupTrack supports teams, so if you run a Group with other admins, you can share access to the CRM and have everything kept in sync. It's awesome!
I am working on system that will manage orders. Orders can be created via admin or via customer. Employee can take orders and change it's status.
My system should have three global types of users:
Admin - this type of users mostly uses WEB interface. Admins have different access levels, so some of them can only create orders, and others - edit core info about pricing and so on.
Customer - this type of users uses customer's mobile app. Main action is to add and cancel orders.
Employee - this type of users uses employee's mobile app. Employees can see open orders, assign themselves to orders and change order statuses.
Also, Customer and Employee can be authorised with phone number, that can be changed at some time (independently of each other). Admins can be authorised with uname + pword.
Current solution has one table for Admins, one for Customers and one for Employees.
So first part of question is how to structure database properly?
The second part is about authorising in REST api. In current solution I have three endpoints, that are authireses usertype independently.
admins/auth
customers/auth
employees/auth
And my thoughts is to keep three tables as is, because each usertype is slightly different concept and really independent. And keep authorisation as is, but add something like roles and privileges to auth token to restrict access for some resources.
I've been trying to find a way to store a piece of data relative to a customer in my store. Ideally I was hoping to be able to create a Metafield that would store a single numerical value and be retrievable by the customer's id or email.
Any thoughts or suggestions would be really appreciated. Ideally I'd like to be able to handle everything in the liquid layer by editing the html and css of the store directly. A custom app with API integration is another option but less desirable as it doesn't seem necessary and would appear to be a lot more work.
EDIT: Tried piggybacking the order (thinking orders are unique to users) but it doesn't appear that the order object is created until the checkout is complete so that isn't really useful since I want to be able to attribute the user to a session click that led them to the store.
Thanks,
Alex
You will want to use an App. First, off, that is the only way for you to alter any objects in Shopify. Secondly, you can easily store simple things like counter values on the Customer resource using metafields. Third, anything you do with metafields on the Customer would be easily visible to the customer, since you can expose those metafields using Liquid. Fourth, if you choose to use JS you must use the App Proxy pattern. Shopify will then send your JS XHR payload to your App endpoint in a secure fashion.
So your needs and how to do are not new, they are old skool in Shopify terms and very straightforward to implement.
In Google Apps, there is always a base/primary organization. But Google Apps can have subdomains and suborganizations both (or combination of those).
We want to be able to identify the currently logged-in user as being part of the overall organization, whether it be the primary org/domain or some subdomain or suborg. But when you get user info or license info, it returns the home domain of the currently logged in user as the ID for their organization. No ID is consistent across all subdomains or suborgs.
I've also tried listing all orgs using the organization apis, but that doesn't seem to work when trying to get the org info of the root org: https://developers.google.com/admin-sdk/directory/v1/guides/manage-org-units
Is there a way, given a particular Google Apps user, to determine what the primary organization is?
The only alternative we have is to treat every domain/subdomain in the Google Apps org as it's own independent org. This is less than ideal because now a Google Apps admin who manages all of their sub-orgs/subdomains in one place in Google will now have to manage a separate organization in our app for each domain in their overall org. This uses up extra resources in our system for creating these additional orgs, but more importantly creates a very confusing organization/user management model.
When you look at the Users resource for the two users, compare the customerId attribute. If they match, the two users are in the same Google Apps account. If they don't they're not.
Also, don't assume two logged in users are in the same Apps account. One could be an Apps account and one could be a consumer account even though they have the same SMTP domain.
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.