Re: Visit#arrived_at/start_at/end_at

[Alon Salant]

Bringing this GitHub conversation to the mailing list...

Thav sent you a message.

--------------------
Basically, people would get signed in with "arrived_at" as soon as
they got to the shop. Since stands are inevitably full, the time they
start working on a project would be different than when they actually
arrive. It's important (for us at least) to have the distinction to
keep the order of the queue and accurately track hours volunteered
toward a membership. If it's not clear hopefully I get a chance to add
some functionality to the visits summary page soon that makes it so!
--------------------

I'd prefer to pull these changes in two steps.

1. The datetime -> arrived_at refactor
2. the start_at, end_at columns with the features they are there to support

The start_at, end_at changes really go with a feature or set of
features that are yet to be developed and that may or may not be
useful to all users of Freehub. There's probably some discussion to
have there.

Aside from the migration, all the changes in the Thav fork are for #1.
If the migration were modified (okay in this case) to only have the
column rename, I'd be psyched to pull in these changes.

Alon

[Tony Olivo]

So it looks like we've got #1 in. Maybe that's the first non-sfbk (or even non-Alon) change? :]

#2 I'm working on. I have added start_at and end_at as columns that can be viewed and changed from the visits index, as well as visit edit. I need to add some tests for them now I suppose. I will also add column headers to the visits index to differentiate between the three times now possibly listed there.

If that's something that would be of interest to other co-ops, we might have to add an organization setting before it gets merged in.. I don't have an idea of how that would be implemented.

-Tony

--
You received this message because you are subscribed to the Google Groups "Freehub Users" group.
To post to this group, send email to freehu...@googlegroups.com.
To unsubscribe from this group, send email to freehub-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/freehub-users?hl=en.

[Tony Olivo]

I have added tests, they pass and fail when I expect them too, I added some column headers and merged in changes from asalant/master. That turned out to be the hard part.

When I forked, there was no migration for start/end_at (obviously), and I added them sometime in my history. Alon merged some of those changes, leaving the start/end_at migration out. So when I merged from asalant/master, it would delete the start/end_at migration. I thought maybe it was because Alon didn't keep that when he merged, so I tried merging from asalant/master before Alon merged, still deleted the file.

Solution for me ended up being...
> git merge upstream/master
> git checkout HEAD^1 db/migrate/2010....start_at_end_at.rb
> git commit -am; git push

to get it back. Took me a while to figure it out though.

-Tony

[Alon Salant]

I think that may have been because of the way I merged your changes
in. I was not able to cherry pick arrived_at without start/end_at
because you added both as parts of the same commit. So I merged, got
both, and removed start/end_at which is why when you merged they were
gone. If they had been separate commits and I had just merged in
arrived_at, then things would have worked as you expected without
having to jump through hoops as you did. It looks like you got some
good git learning in though!

[Tony Olivo]

Some days I spend more time with git than rails :]

Today I'll look at wrapping the start_at, end_at business up in a organization setting. Will be hanging out in freenode/#dbc again

-Tony

[Tony Olivo]

Pull requests are in. If they get accepted in full, I should probably restart my stuff from asalant/master. That will be another git thing to learn. A merge will possibly make it look right in the network graph.

-Tony