These are just a join between a customer and a artist, with a specific date.

When an artist is created by a shop, they should get an email asking them to set a password.

I bought the dot com, but I haven't pointed it at heroku yet.

   No Procfile detected, using the default web server (webrick)

😭 😱

appointments customer_id has a constraint that the id must exist in a user table so delete fails silently for all users with appointments.

this is basically the case for all relations.

wontfix ftm

They shouldn't be able to make new artists for the shop.

They shouldn't see other artists' customers in their search results.

They shouldn't be able to edit other artist's customers.

They shouldn't see other artists's customers in their listings.

They shouldn't see other artist's show pages.

Currently, any customer can be edited by any shop. That's bad.

Artists should be able to log in, not just shops.

This should be the last thing that gets implemented. This will also need a payments implementation, for which I'll be using Balanced.

When we migrate the real app to this code, it'll need to have the data imported from the old app. This will take some schema changes and such.

Using flash[:notice], flash[:success], flash[:error], and flash[:alert] does not work.

The code from the original app:

 @customers = %w[name phone email credit want notes location].collect do |col|
    Customer.all(:conditions => ["#{col} ILIKE ?","%#{params[:q]}%"])
end.inject([], &:|)

https://www.dropbox.com/s/m265cfzudg4je3p/Screenshot%202015-07-06%2012.25.40.png?dl=0

when i type in npm start i get ^ that error. am I doing something wrong?

Nothing complicated. Original implementation:

    @customers = %w[name phone email credit want notes location].collect do |col|
      Customer.all(:conditions => ["#{col} ILIKE ?","%#{params[:q]}%"])
    end.inject([], &:|)

Postgres supports the ILIKE, but I don't think sqlite does?

301db4a

as @bmac mentioned to @ashleygwilliams , ember-data currently expects keys to be dasherized. /cc emberjs/data#3455

It's probably simplest to just dasherize the key rather than worry about trying to patch data

Hi Steve, how open are you to PRs, especially to features not related directly to the core app? I'd like to have an RSS or ATOM feed of the blog posts so that I don't need to follow the whole github RSS feed for the whole project and I'd be willing to contribute that.

This needs to happen before Jason can use AA.

this is the result of some shitty copy pasta from the mozilla publish api implementation in hapi where i implement a base route class, passing the schema to Joi. i need to fix it to work with Endpoints.

discovered by @steveklabnik when he was implementing error flashes on the frontend and saw the errors hit the db.

https://twitter.com/SunnyRJuneja/status/476426248550244352

Lots of people aren't familiar with the AGPL, so this is a good idea.

Seems that one of the pitfalls of using the file system approach is that there's no way to store the created_at in a way that's accessible by Rails. I see you used ctime, but that's based off of when the file is written to the filesystem, not it's actual creation date. My assumption is that every time you deploy it will clobber the ctime of the file with the deploy time. (Note this is completely unsubstantiated and a complete guess).

I worry about not having a proper creation time and how that will affect RSS (Spoiler: maybe not at all).

Overall, this is generally a non-issue, but I think it's an interesting situation to think about. One solution I have would be a pattern similar to this:

http://harpjs.com/recipes/wrap-markdown-posts

Couldn't find a direct rails based parallel, but I think the idea would translate. Also, might be a bit heavier than what you want to deal with for solving a bogus created_at :P

EDIT: Had the thought that a lightweight solution would be to put a timestamp in the filename generated by to_s(:number)

irb(main):010:0> Time.now.to_s(:number)
=> "20140618002121"

You could then parse that out via regex or filename.to_s.last(14)

If they're going to be able to log in, they'll need a password. At first, I will set them for the artists at Artisan.

because foreign key constraints

wontfix for now

Each customer should have their own page.

so creating customers works, but updating them doesn't.

Each appointment should have its own page.