I have a question for a project I am working on. I am working on a RoR project in which a site is selling a single type of item, a book. The person I am creating this for does not want to deal with users creating user account to check out as the sales season is very short for this product, the purchases are done once per year, and the site only sells a single item.
I am wondering if there is something wrong with the implementation I am thinking of. What I was envisioning was a single database class called Orders. visitors to the site would simple fill out an order form with payment details through stripe and click submit. If they payment clears, the order with all the Orders information would be persisted to the DB. If the payment fails then it is not persisted and the relevant error information is displayed in using flash.
I suppose the meat of my question is; is there anything inherently 'wrong' about implementing this model without a users class and just having visitors to the site place orders?
I am a fairly new developer and this is my first big project so any feedback is appreciated!
If your requirements say that it is okay, then it is okay, if your requirements say it is not okay, then it is not okay.
There's not more to say, since only you know what your requirements are.
Related
There is a lot of changing with Data Protection and GDPR. I am not sure which is the right method for me to develop it.
The reason I was looking for advice because of the new Apply policy on account of deletion requirements extended https://developer.apple.com/news/?id=i71db0mv
We are using ROR API. and we have mobile App but we don’t have deletion account, only Deactivate Account cos we need to keep a record on booking history.
I was thinking something like that.
Create a new table “old_user_table” with old user_id, first name, second name, email, and booking slug.
It will allow keep all users who did previous booking. And deleted their user ID in the app. We need to keep all records for booking for audit purpose in the last 5-10 years in the app.
The user setup with this app, the user but never booking, then the user will not transfer to “old_user_table” cos the user booking nothing.
Does it make sense? Something like that? Or do you have a better alternative?
(FYI I’m not RoR Developer but I want to make sure I have better knowledge or better case before meeting with Ruby developers & IOS developer).
That approach won't be GDPR compliant since you are keeping PII in the old_ table.
If you want to keep the old bookings I would replace the user_id for some new random generated UUID that has no link with the real user, and then remove the user from the database.
I am have been using rails for about a week now and have created a website/app which for simplicity's sake we can call a job board. Users can create listings which other users can then apply for. Everything is working as desired. The next thing that I want to set up is the ability to charge users to create the listings.
After extensive searching, I can't find any tutorials that explain this process, just the typical cart and checkout for selling physical products.
I have been pondering solutions but I wanted to consult here for pro advice.
For the payment process (at least for now) I will most likely use active merchant and Paypal as I am based in Europe.
My current doubts are with setting up the modeling.
Would it be better to create a new model eg. 'credits', have users purchase 'credits', then run a variable when trying to create a 'job', eg. if_user_has_credits post the job else link to buy_credits_path, or is there a more direct way of achieving this through the already functional user and jobs models?
Any advice on setting up this functionality would be greatly appreciated.
Thanks.
I would try to create a credit system, so users just have to purchase credits and you can just drive the user to purchase credits in case they do not have enough for create a listing:
Simple one: Store the user' credit as balance field in the database, and all actions ("add", "deduct") are logged but not used to compute the latest balance. The balance-based way gives you fast access to the current amount
History based: Don't store the balance in database. The balance is computed by looking at the history of transactions, e.g. ("add", "deduct"). The history-based way gives you auditing. The history table should store the transaction, a timestamp, the balance before the transaction happened, and ideally a way to track the funds' source/destination.
You can use both. See the Ruby toolbox for bookeeping and Plutus
I recommend also using logging, and ideally read about secure log verification and provable timestamp chaining.
For logging details see techniques for ensuring verifiability of event log files
As an example, lets say I have 4 models: Product, Order, Customer, Store
When an order is placed by a customer in a store, the store's owner would get an email asking to confirm the UPC code on the product. Once confirmed, the customer would get an email with a code that when they enter it into their portal, it activates the product.
There is a lot of logic here, which spans several models. For example, when the order is completed, it creates a new inactive product with a confirmation key. The store owner accesses this product by its confirmation key and adds the upc information to it. Only then, once the product has upc information can the customer confirm it.
TL;DR - My question is, what is the best way to group a large process, which involves many models, into a central location? Instead of accessing several other models from within one model, it would make more sense to have it centralized. Is there a best-practice for this type of logic?
This case is typically going to result in a "Service Object" that would be placed in /lib.
This allows for testing the workflow in isolation and doesn't fatten up models unnecessarily.
You can find a good intro to Service Objects here:
https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services
http://multithreaded.stitchfix.com/blog/2015/06/02/anatomy-of-service-objects-in-rails/
I'm building a Rails 3.1 application that allows people to submit events. One of the fields for the event is a venue. On the create/edit form, the venue_name field has autocomplete functionality so it displays venues with a similar name, but the user is able to enter any name.
When the form is submitted, I'm using find_or_create_by_name when attaching the venue to the event model.
I'm doing this because it's not possible for us to maintain a complete list of venues and I don't want to prevent people from submitting an event because the venue isn't in the list.
The problem is that it's quite likely we'll get duplicates over time like "Venue Name" and "The Venue Name" or any number of other possibilities.
I was thinking that I probably just need to create an administrative tool that allows the admin to review recent venues and if he/she thinks they're duplicates to search/select a master record and have the duplicate record's association copied over to the master record and once successful to delete the duplicate record.
Is this a good approach? In terms of the data manipulation would it be best to handle this in a transaction? Would it be best to add this functionality in a sort of utility class - or directly in the Venue model?
Thanks for your time.
If I were going to put together a system like that, I'd probably try to find a unique identifier I could associate with each venue - perhaps an address or a phone number?
So, if I had "The Clubhouse" with a phone number 503-555-1212, and someone tried to input a new venue called "Clubhouse" with the phone number 503-555-1212, I might take them to an interstitial page where I ask them "Did you mean this location?"
Barring that, I might ask for a phone number or address first, then present a list of possible matches with the option to create a new venue.
Otherwise, you're introducing a lot of potential for error at the admin level, plus you run into a scalability problem. If your admin has to review 10 entries a month, maybe not so bad - but if your app takes off and that number goes to 1000, that becomes unmanageable fast!
I am using embedded documents in MongoDB for a Rails 3 app. I like that I can use embedded documents and the values are all returned with one query and there is less load on the database server. But what happens if I want my users to be able to update properties that really should be shared across documents. Is this sort of operation feasible with MongoDB or would I be better off using normal id based relations? If ID based relations are the way to go would it affect performance to a great degree?
If you need to know anything else about the application or data I would be happy to let you know what I am working with.
Document that has many properties that all documents share.
Person
name: string
description: string
Document that wants to use these properties:
Post
(references many people)
body: string
This all depends on what are you going to do with your Person model later. I know of at least one working example (blog using MongoDB) where its developer keeps user data inside comments they make and uses one collection for the entire blog. Well, ok, he uses second one for his "tag cloud" :) He just doesn't need to keep centralized list of all commenters, he doesn't care. His blog contains consolidated data from all his previous sites/blogs?, almost 6000 posts total. Posts contain comments, comments contain users, users have emails, he got "subscribe to comments" option for every user who comments some post, authorization is handled by the external OpenID service aggregator (Loginza), he keeps user email got from Loginza response and their "login token" in their cookies. So the functionality is pretty good.
So, the real question is - what are you going to do with your Users later? If really feel like you need a separate collection (you're going to let users have centralized control panels, have site-based registration, you're going to make user-centristic features and so on), make it separate. If not - keep it simple and have fun :)
It depends on what user info you want to share acrross documents. Lets say if you have user and user have emails. Does not make sence to move emails into separate collection since will be not more that 10, 20, 100 emails per user. But if user say have some big related information that always growing, like blog posts then make sence to move it into separate collection.
So answer depend on user document structure. If you show your user document structure and what you planning to move into separate collection i will help you make decision.