I’ve missed blogging here. After a long time, ages even, I’m writing this post. But that doesn’t mean I’ve changed one bit! My love for open source still remains strong and my love for Rails? Semper Idem ❤
Been kind of busy juggling my hectic college life so I haven’t been able to blog about the GREAT BIG THING THAT HAPPENED TWO WEEKS BACK! Both my pull requests got merged! 😀
The first person I informed was Monika, and my wasn’t she happy! She’s the one I have to thank for everything. Even thanking wouldn’t be enough for all the patience she’s showered on us.
I’ll keep posting little updates now and then! Stay tuned 🙂
RGSoC may have officially gotten over, but we’re not stopping here! We’ve absolutely loved the three months so why stop? Yes, we’re continuing for a bit more! 😀
Now, we’re working on save as drafts feature. Created a new model for applications, controllers, yada yada. But, the issue we’re facing now is that the “save” and “apply” buttons in our view does the same thing – create an application form and save to database. We want the “apply” to submit the form without being able to edit or view it again. Yes, we do have different actions and routes created for this, but we just need to make Rails understand that the two actions are different in the view.
We’re having a call with Monika tonight. Hope to get more clarity on this.
Honestly, I’ve run out of titles. Make up something on your own.
The pull request we made needed some major change we hadn’t thought of! Here’s explaining why :
Our feature was to make applicants form a team during the application process. We had a projects attribute belonging to a team model that should not be validated for presence when the user is an admin ( nah, the thread hash isn’t a good way to learn ) So, we had decided to make a different projects model itself and tweak the view to show this field to a team only and remove the projects attribute from a team model. Work done. But. But. But. Not yet. Monika brought to our notice that there are previous teams with projects attributes and when we run the migration to remove the projects attributes, the data would be lost! Oops. We definitely hadn’t thought of that. So, she suggested that we edit the migration file to make the transfer of the projects attribute values to a project model name attribute. Here again we faced some issues with the loop we were using. We asked for help on the lovely campfire and lucaspinto helped us out in the campfire! He figured that our loop statement Team.all do |team| *insert code to make transfer* wasn’t taking each team individually. The output was an entire list of teams and we definitely don’t want that! He suggested using Team.all.each do |team| *insert code to make transfer*. And wheeee! It was working! 😀
On a serious note, we really hope we could have figured out the stuff by ourselves. But these mistakes we make have opened up new ways of thinking about problems and issues. And now, we’re more confident of fixing stuff!
Here’s the link to our pull request – https://github.com/rails-girls-summer-of-code/rgsoc-teams/pull/121. Hoping for a review!
So. We just made another pull request! And the builds are passing! 😀
Remember our previous blog post in which we faced “NoMethodError: undefined method `with_indifferent_access’ for ..:Array” in our teams controller spec? Well, we went to Monika with this and she figured it out in no seconds. The association between team and project is a has_one. But in our spec, we were passing in an array of values of the name attribute of the project. So it was expecting many more project attributes which we weren’t passing in. Passing it as a hash, one key value pair, solved it!
And the next problem was that the project name wasn’t getting saved ( we assumed it wasn’t getting saved, you’ll know why, keep reading ) in the teams form inspite of us using the accepts nested attributes in the teams model and setting up the proper associations. We were drawing blanks everywhere! So, Pavan helped us out here. He suggested a cool awesome way to find out the bug! Write specs for how you would expect your code to behave. So he helped us write specs for the code we wanted to test. Turned out that the project name was in fact getting saved along with the team. Okay, works good. Next. Why weren’t we able to see the team name in the form after hitting save and going back to edit the same form, then? Hmmm, some bug in the controller. Test the controller. Write specs in the controller. Used the reload method to reload the form and then test if the project name comes up in the reloaded form. Nope! Aha, gotcha. So. We go to our edit method in the controller and then see what is happening. We used build_project. Which meant that each time the page is reloaded, this build method creates a new object in memory which the view takes and displays. We definitely don’t want object for the project everytime the page is reloaded! We just want this to happen only when a selected team is editing their form for the first time! Made some code changes there in the edit method and now it works!
Keeping fingers crossed and hoping our PR gets merged soon! 😀
Here’s our pull request https://github.com/rails-girls-summer-of-code/rgsoc-teams/pull/121
P.S. We HAD to create a new PR. Our previous WIP one, well, we made a lot of mistakes with git. Not saying anymore 😛
Sorry! We haven’t been blogging lately! We’ve been busy with tests from college the past week 😦
Right, so last week I messed up a LOT OF GIT! Used git revert for some 37 commits back! But uh-oh merge conflicts stayed with me like a loyal friend. Go away friend! I don’t like you! Don’t you get that? You make me tensed and I start typing faster, clicking faster, freaking out faster!
On a serious note, we realized the mistakes we made and will make sure to never repeat them, ever again. Lots of misconceptions got cleared too! It’s easy to read the git documentation and yes, you do feel you’ve understood everything. But, it’s hard to remember exactly what to use when you run into trouble! And this wisdom comes with practise.
We’re right now getting this error “NoMethodError: undefined method `with_indifferent_access’ for ..:Array” in my teams controller spec. I have a team model. And a project model. Team has one project and Project belongs to team ( so that’s the association ). The project is not getting saved in the team form after hitting the save button, inspite of using accepts_nested_attributes_for. Got to investigate! But, if you have any inputs on any of the above two problems I’m currently facing, please do comment below!
I accidently deleted my project on my local machine while using RubyMine. I did a restore but somehow, things were so messed up I cloned the project again. But this new project I cloned did not have my work from the past few weeks! Oops!
After spending hours on getting confused, messing up Git * again* , fixing merge conflicts, now I’ve finally got it up and running!
Getting back to work!
Wow, so we’ve missed Mavenhive so much for the past few weeks that we decided to take a day off and visit them!
We realize we don’t want to everrrrrrrr leave this place !
So, we sat them awesome folks and they gave us a feedback about our feature and how we’ve implemented it.
Turns out, the Thread.current hash is not what we need have done to get validations running for different users ( read more about it in our WIP pull request link we shared in our previous blog ) Usually this method is used by very experienced Rails developers who have complete control over their app and know the ins and outs of their project ( and we don’t come under this category 😛 )There were simpler more easier ways to make validations run based on whether the current user is an admin or not. We got a couple of options from them and we’re getting back to work!
To create a Save as draft for an application form, we did this :
1. Created a Save option in the form and set the value to ‘draft’.
2. Migration to add a column called status to application model.
3. In create method of controller we have this logic to check if we want to save as a draft : if params[:commit] == ‘Save’. If yes, then set the application status value to ‘draft’. Coming to why we have to do this. ( Commit is the name attribute of the submit button )
4. So. Next. When we want to view the half completed form, we need to make sure that we’re showing the right thing. So, in the show method of controller, we’re checking the value of the status column. If it is a draft, render the appropriate form.
But no, this isn’t working. The form is simply not getting saved as a draft. It’s just getting published. I’m probably missing something.
We are currently looking at implementing a “Save as Draft” for an application form.
Past couple of days : Made some mistakes, created a new edit form in the hope of implementing a save as draft for that form. Turns out, this doesn’t work. Because one, we already have an edit form viewable by only certain members. 2. We don’t want the form to be submitted at all. Nope, this doesn’t work.
Learnt a neat hack : To know about requests sent when you use your app, use this command : tail -f log/development.log. The development.log file contains Rails log info. This is really useful and this was what we used to investigate what was going wrong when we were an admin and set a team to “selected”. Remember our post about accessing the current user in a model? This log file told us the parameters that were being sent as a request and we came to know that it wasn’t the current user, i.e, admin, but the user whose name is included as a team member. And this command helped us figure that out – the tail command is a Unix command that read the last lines of the text file specified. Neat.
Ooops I realise that I haven’t structured our post today, so if you ended up getting confused after reading this post, fear not. We’ll write a nice post about everything in detail soon! 🙂
- Missed us? We’ve been having our fair share of assignments from college which is keeping us away from our blog 😦
- So we had some confusions about CanCan abilities and defining them. We got our doubts cleared and now we’ve hit our aim – only an admin should access a certain field! YaY! ^_^ You can find out more about it in our Work in Progress pull request here https://github.com/rails-girls-summer-of-code/rgsoc-teams/pull/117.
- This is freaking me out
Merge conflicts! *Sigh* there’s no running away from it.
4. Now we have to work on getting a team ( previously only a single user ) to use the application form. Which means there’s so much to do! Currently, our application model has attributes of a single user. We will have to change our models, views and controllers to reflect the changes we have done. Or should we create a completely new model, a corresponding new view and controller? Hmmm, requires some research and brainstorming.