I'm creating a site to manage a sports league. At the beginning of each season, there's a draft during which captains choose their teams. Currently, I'm considering using Organic Groups and/or a user reference field on the Team type. (Which one? Both?)
I'd like to provide a clean interface for managing the draft where an admin would have a bucket of users and could drag them into buckets for each team. Or between tables or via a dropdown interface or whatever. I'm less concerned about the interface at the moment than I am that:
the admin can see and edit all the users
grouped by team
with an ungrouped group
easily move them between the groups
I imagine I might be able to use views bulk operations to whip something up, but before I do, is there anything like this out there?
It sounds like a good scenario for organic groups, as you suspected. You can make a private group per team, and only allow administrators or 'team captains' to add people to a given team. A views query can allow you to show a page of players who don't belong to any group. We do something similar for project teams.
Yup, perfect scenario for Organic Groups! That's exactly what that module was meant to do.
Related
I want to create multiple online shops for selling merchandise products for companies. The products are basically identical but should be personalized in dependence of the company I am building the shop for. Because I do not want to build a new shop every time a new company joins the program I am looking for something like that:
www.myshop.com : One shop with the underlying product database and checkout system - not showing any products, just as a parent structure
www.company1.myshop.com : A slightly personalized shop where only a selection of the product catalogue is available
www.company2.myshop.com : A slightly personalized shop where a different selection of the product catalogue is available
Do you get it?
Does anybody know a tool for that?
Thanks in advance!
I already looked into WooCommerce, Shopify and even WiX. As far as I understood what I am looking for is not supported.
Since your example is based off of subdomains, you can choose to assign a Shopify store to each subdomain. Each store feeds from your inventory and accounting, giving your customers the illusion of a custom experience. Or you can just simplify your life, have one store, and assign your customers to view collections specific to them. That is the smart move. You may not like that, but it would work a peach for you. You just tag customers to see their specific collections, of products specific to those collections. Simple.
I can also think of a dozen other ways to pull this off with Shopify, but that is me, not you. For an opinion question like this, SO is not the right place to ask these kinds of questions, but I answered anyway. Your mileage may vary of course.
We want to move our entire IT side of the business onto firebase but need to find the right architectural approach before we do so.
Here's our company and business setup:
one company with one domain i.e. example.com
several business areas independent from each other. For example: one sells bananas, another one is about facility services, yet another one about local transport services & repair
the same customer can be customer to one or more of those business areas i.e. we have centralized billing, centralized auth with SSO, centralized customer relation management etc.
every business area (e.g. selling bananas) has a web as well as it's mobile versions of the app (iOS/Android) aiding that particular business area
How do I map that company with its many business areas onto firebase?
Do I have one project per business area (e.g. selling bananas) containing the three app versions (two mobile, one web) of the specific area and one project that has all the stuff needed for central user management (#3 from above)?
What are my limitations regarding number of projects? If every business area has a staging project for its App then we'll have twice as many projects as we have business areas...
Do I pay per project or per account usage i.e. we would have one account with at least four projects I guess?
Can I have my domains laid out like this
example.com/bananas
example.com/facility-services
example.com/local-transport-and-repair
Thanks a lot for some insight in advance! :)
There's really no direct way to answer this question but Firebase is more than capable of handling this use case within a single project. Doing it that way allows for one user base and if needed, resources can be easily shared between 'departments'
Conceptually, it's pretty straight forward; but we don't have a lot of specific info to go on in the question so here's one example.
Supposed this is a fictuous company that distributes bananas as well as offers banana services for facilities and repairs and maintains banana trucks. We'll call this company; Real Ap-Peel.
real-apPeel
sell_banana_div
//here we store all data about selling bananas
facility_services_div
//here we store the data about facility services
services_repair_div
//here we store service and repair data
users //all users
uid_0:
div:
sell_banana_div: true
uid_1:
div:
facility_services_div: true
uid_2:
div:
sell_banana_div: true
services_repair_div: true
In the above setup for our company, we have three separate divisions with their own subset of data. We also have one unified users node to track the users and a child called 'div' which will determine what division that user belongs to.
The last user, uid_2 belongs to two divisions and can therefore access data in the sell_bananas_div as well as the services_repair_div. Handling accessing data in both divisions is done through code and enforced through Firebase Rules.
If you NEVER need to share ANY data between any of the divisions, then there's no reason to have a combined structure like this so go ahead and split it out into separate apps.
However...
Combining data lets you have one app, one code base and one set of users which makes it considerably more maintainable and expandable.
You asked the following:
Do I have one project per business area (e.g. selling bananas)
containing the three app versions (two mobile, one web) of the
specific area and one project that has all the stuff needed for
central user management (#3 from above)?
All of that is combined into one app, per my above example, and can be any combo or mobile or web.
What are my limitations regarding number of projects? If every
business area has a staging project for its App then we'll have twice
as many projects as we have business areas...
Issue eliminated as it's just one project
Do I pay per project or per account usage i.e. we would have one
account with at least four projects I guess?
This is more of a direct question to Firebase if you choose this path. Contact support#firebase.com
Can I have my domains laid out like this example.com/bananas
example.com/facility-services example.com/local-transport-and-repair
My above example pretty much does that - a single realappeel.com and then the references to the child nodes are realappeel.com/sell_banana_div etc.
I hope this isn't too far off the question. If so, post and comment and I will update (or delete if its waaaaaay off base!)
I need to build a secure web application that allows sports coaches to go in and add points (numerical values) to each of their own sport players.
Each coach should only have access to their own information (through their email and a password) and an area that lets them update only their player's points.
There is a total of 4,000 coaches and 10,000 players that have to allocated to their appropriate coaches.
I have attached an image of how that would work through a crappy hand drawing.
What would be the best web application to develop this on?
Web Map of Coaches and Players relationship
Well, this is highly subjective. The world is your oyster. It sounds like your webapp is essentially a nice UI layer over a database.
Personally, because I work in these a lot, I'd use Yii (PHP) as a backend and set up models to match my tables in a SQL database. I'd create a controller as an API to expose those models to AJAX calls.
In the SQL database itself, I'd set up the coach/player relationships, as well as access rights for the different coach login profiles and admin rights for the admin profiles.
Then I'd set up an AngularJS frontend to display it all. With Angular, and other frameworks, it'd be really easy to rig up a table using filters to make player info searchable and filterable on things like name, score, player number, etc. I'd also want an interface to add coaches, and you'd want to give coaches the ability to add players.
It's so subjective though. You could do a noSQL database, java backend, c++ backend, scala, nodeJS, react.js, etc, etc. There's no one "right" solution. It basically comes down to your own programming preferences.
Seth pretty much summed up the very broadness this question brings for answers, but I actually created something very similar to this in Drupal. This website/app was used to run a multi-day fishing tournament.
The quick and dirty answer here (when using Drupal anyway) would be to restrict access through creatively setting up Roles and Taxonomy Terms for the coaches and players and only allowing Coaches to see players that have a certain term attached to them (when I say Coaches and Players, Coaches could be Drupal 'Users' and Players could be a content type, for example). You could then create another content type (entity) to hold the Points and then attach the Points to each player.
Another solution would be using Organic Groups and making the coaches group admins and putting their players in their own groups... So many different ways to handle this.
The reason I suggested Drupal was because a lot of the grunt work is already done for you. It already has the options to create/manage Users, restrict access to content and set up entities and tie them all together. This could totally be built from the ground up, as Seth suggested or it could be built on a framework or an existing content management system.
I'm sorry if this is not within the acceptable question guidelines for Stack Overflow, but I am feeling stumped, and I feel that what I'm trying to do might just be incredibly simple for some of the veterans here.
I've set up an Ubercart on a Drupal installation for a small gym website. What they are wanting is to allow a customer to register and pay for various memberships for their children (youth flag football, teeball, etc.). One person may come back and sign up multiple times throughout the year, and each customer may have multiple children who can each participate in multiple programs.
What I'm thinking is to disable anonymous checkout on Ubercart. The customer billing address will be the saved information for the "parent." I'm thinking that the parents could create Members (their children) which could be stored in a content type called Members and the Members could be linked to the programs of which they are a member via entity reference. The children could maintain their relationship to their parents by authorship.
I've been trying to work through this for the last few hours. Does anyone know of a way the I can accomplish this--maybe with rules? I'm thinking some kind of credit system in which for each quantity of a membership (per program) that they pay for, they get one "credit" to create one entity reference between a member and a program.
Any brainstorming and help on this topic would be majorly appreciated. Thanks.
Your use case sounds more like event registration than selling memberships. Each class would be an event that parents would register their children for. It may seem like overkill here, but I would use something like CiviCRM or RedHen CRM for this. Both support the concept of relationships between members and provide event management tools. You could make each class an event that people would sign up for, pay (they could even register multiple children at the same time) and get a receipt. The event history information would be stored so parents could sign in and see what each child has done. You could even make the list of kids in the class public so parents could see who else is in the class.
Afterward, it would be easy to put together a survey to send to the "attendees" to get feedback on the event/class and notify them about future events. I can think of a dozen different things that these systems cover that you may need in the future (early bird event registration, special pricing for returning parents/children, activity reports to email to parents every year so they can see what their children did...).
You may be able to pull together modules and custom content types (Ubercart Event Registration module as a starting point), but a CRM would provide the things you are looking for now, and the features your customer will be asking for in the future.
it seems like alot of ecommerce sites these days are providing products filters to search for items. For example you can search items by WIDTH,HEIGHT,TV SIZE, Furniture Type etc.
now if it was a simple website with just a few searchable filters then its easy to do, but I am managing a website which sells furniture,appliance & electronics and every category has alot of sub categories as well. for example:
Appliance:
Laundry
Searchable Attributes (Washer,Dryer,Washer Type..Microwave,Width, Height)
Electronics
Tv(Tv Size, Width)
Games (ps3, Genre,Sale Date)
I am sure you get the idea. an ecomerece sites offers basic categoies and then every category could have sub categories OR Searable filters to drill down your search.
what would be the best way to do this using MS SQL Server & Asp.net. I am interested in creating a optimized searchable schema in SQL.
any Hints, Suggestions will be welcome.
Thanks
You can use the Entity-Attribute-Value model.
The simple concept is that instead of having a column for each of your model's attributes (such a genre, sale date, etc for a ps3 game), youll have another table, named Attributes, where the attributes and their types will be listed, and a third table, where your main model instances (ps3 game) will be linked with attributes via 3 columns:
Model Id (the id of the ps3 game)
Attribute Id
Attribute Value
This concept might be harder to manage, and require more complicated queries, but it will alow addition of new products / categorites in the easiest way.
Of course, with this model, if few products share a common attribute (sugh as pc game and ps3 game sharing a genre), you'll have the attribute defined only once, and both model will be linked to it, allowing a common search query on different products.
Too much for a single question. Look for a book on database design. For a drill down you can have a table with as many PK columns as drill downs. But when it comes to details you will need separate tables as TV does not have the same details as a stereo.