Commission Revision Page

[Bejoty]

Updates needed for the Commission Revision page:

• Umm.... the creation of the Commission Revision page (Due 11.27)
• Pull old commission request object from the database
• Pull artist revision suggestions from the server
• Display current commission information
• Text input area for customer to submit revisions
• Submit to the server (all hail the server)

Settings Request Review Revision (Payment) Progress

[japacible]

Making a note that scaffolding for this should be done by tonight, per team meeting.

[Bejoty]

Yup, definitely pushing for it.

[Bejoty]

Super basic scaffolding is up: 9e0d657eb741cce739e1cdf7dda768447f1775ab

I can't do much more (easily at least) until it's stitched in so I can see active changes. But the form is in place, so the submit button will send the value in the text area back to the server.

Now is the time where @jbrodhacker and I will probably need to push quick iterations. Let me know when you have time this weekend where we can both be online!

[jbrodhacker]

I'm a bit confused as to the "pull artist revision suggestions from server" note. From our meeting back when we discussed the storage of commissions and commission requests, we only had a previous commission state and a current commission state, not both as well as an artist revision state. Are we now adding artist revision suggestion state to commission requests as well? I'll need to add another column to the table for commission requests if so.

[Bejoty]

I don't remember how we chose to transfer the revision suggestion back to the customer. Should we discuss the design and flow again?

1. Artist specifies commission settings
   • retrieves prior/default commission template object
   • stores commission template object (by overwriting)
2. Customer sends commission request
   • retrieves artist's commission template object
   • stores commission request object
3. Artist reviews commission request and suggests revision (final step)
   • retrieves customer's commission request object
   • stores/sends revision suggestion by __?
4. Customer revises commission (final step)
   • retrieves artist's revision suggestion (and commission request object for reference)
   • stores/sends new commission request by __?
5. Artist accepts commission
   • retrieves customer's commission request object (plus old final step?)
   • commission object goes to 'next stage' (?)
6. (payment processing)

That's how I've been thinking about it at least. Let's knock out the inconsistencies and assumptions tonight so we both know exactly how this thing's evolving.

[jbrodhacker]

When we were talking about it before, steps 1 and 2 were the same, but step 3 would store the "artist's revision" as just a new commission json; so in the commission request there is a current commission json and a previous commission json. The current one would have revisions from the artist in step 3 while the previous one would have the original commission. Then at step 4, the comparison the commissioner would be between those two jsons, and they would have their own revision which would then be stored as the current commission, and the artist's old revisions would be stored as the previous commission. At step 5, the artist would see a comparison between their revisions and the commissioner's revisions, accept the commission, and the commission request object is deleted while the commission object contains the current commission json.

[japacible]

I understood the commissions flow as @jbrodhacker outlined it. We'd only keep the latest two (or only version+null) jsons for comparison, regardless of who changed it.

Of course, things may have changed since I haven't been focusing on commissions for the past few weeks.

[Bejoty]

Sorry, didn't intend to leave this hanging.

Okay then I'm most definitely lost with the data storage side of things. But that's okay! It should be pretty quick to clear up. So far my pages through client-side code 'save' the following information (just the logical progression, not actually objects to be stored).

Settings:

COMMISSION TEMPLATE
categories {
  steps {
    options
  }
  final step prompt
}

Request:

COMMISSION REQUEST
category {
  steps {
    options
  }
  final step
}

Review:

[commission request]
revision suggestion (how to change final step)

Revision:

[commission request]
new final step

The above doesn't focus on how the info is stored, merely just what information needs to be stored. Is that much off, or are we on sort of the same page there?

[Bejoty]

Oh, and I'll throw a mention in case @jbrodhacker isn't actively browsing this issue.

Followup note, I realize my response doesn't address your response. I'm basically taking another step back because we're definitely not meshing on something, but it's the much broader flow.

I don't think our explanations are mutually exclusive... I'm willing to bet it's just my ignorance on the storage side of things.

[jbrodhacker]

@Bejoty So the commission request stores two jsons... so in your above example, it's going to store two of those category { steps { options } final step } objects rather than just one. When the review occurs, one of those objects will be the one the commissioner submitted, the other one will have the final step changed to the revision suggestion. On the revision step, the original step the commissioner submitted will be dropped, the changes suggested by the artist will become the "old" version, and a new object with the new final step will become the latest version.

That doesn't have to be how it is, it's just the way we had originally decided on a few weeks ago when we were hashing it out. Back then we didn't have the optimization of only changing the final step.

[Bejoty]

When the review occurs, one of those objects will be the one the commissioner submitted, the other one will have the final step changed to the revision suggestion.

OOOOOHHHH, okay cool, I thought that might be what you meant. So ultimately, it can definitely be stored like this, or by another method, and the front-end stays the same.

[Bejoty]

Put another way, that process makes sense, and my lack of knowledge regarding data storage prevents me from proposing an alternative scheme, especially with our schedule. :)

[jbrodhacker]

Just wanted to make sure we were on the same page, since it means that the front end is dealing with two json objects :)

[Bejoty]

Oh, yeah so as far as forms go, no real changes. However, I'm not even quite sure how the code works to retrieve the objects, so as long as someone knows that much, I've got the object traversals down.

[Bejoty]

And @jbrodhacker, do you have a solid string of hours that you'll be reliably open to finalize functionality in these pages? I'm thinking we work in flow order to make sure everything is being passed successfully.

Settings -> Request -> Review -> Revision -> Progress (super simplified) -> Complete (probably just the progress page with different object status)

I'm going to be unavailable most of this evening unfortunately (I really can't get away or I would). I might be able to work at the ungodly hours of about 1am-4am tonight, but almost all of tomorrow is open for me as well outside of classes.

[jbrodhacker]

I'm not really sure what my OS group wants to do tomorrow, but I should have some time tomorrow. Does around 7 or 8 p.m. tomorrow work for you? I know that we technically have the code freeze at midnight tomorrow, but that seems to be the only time between now and then that we both have available.

[Bejoty]

I'm definitely available to start hauling on it at 7 tomorrow. I'll do what I can to streamline the process before we connect.

[jbrodhacker]

Great, I'll try to do the same :)

[jbrodhacker]

Currently settled back at my dorm and standing by :)

[Bejoty]

Awesome! I'm still cranking code on the settings page, but I can do that in between other stuff. Let's see.. That's probably a good place to start. To issue #222!

[quanc]

How is the status on this?

[jbrodhacker]

@Bejoty how goes this?

[Bejoty]

If we're going to make the review page act as the revision page for the commissioner, it'll need some simple conditional statements in the html. I'm trying to find the comment I made about it, but it's alluding me.

Essentially, the review page will have the same request object pull, but the form at the bottom will be different dependent on the person viewing it AND the current commission status.

[jbrodhacker]

It's on issue #229. Do you want me to make the conditionals for you or?

[Bejoty]

Oh haha, I forgot we kept talking on an unrelated and closed issue. If you could cover that, I'll finish prepping the progress page.

[jbrodhacker]

Okay :)

[Bejoty]

I also had a thought a bit ago.. I don't think this code needs to be in JS. The settings page needs it because all the parts have buttons that manipulate the page on the client side.

But everything else has just been injecting server data. Sooooo, as long as I know the syntax for grabbing the object fields with Ruby, we can eliminate many of the JS files (and the heroku issues related to them). I'm pretty sure at least.

[jbrodhacker]

We can do this if we have time after we get everything linked up, since I'd rather us not break anything :)

[Bejoty]

Yeah, but since I caught it now, I'll build the progress page all in the HTML file. That will be oh so much faster.

[Bejoty]

Assuming you can tell me how to parse the JSON object with Ruby. I'll just have placeholders for now.

[japacible]

@Bejoty Let's finish everything else before going back to this.

[Bejoty]

What? I'm constructing the progress page. Is there something else I should be looking at?

[japacible]

Can you let us know the status of all the other commission issues? They're kind of hanging at the moment. The status may have been mentioned in other threads, but it's not time efficient for people to read through every comment at this point.

Also, once commissions is done.. we still have to redo the welcome/index and users/show pages to actually pull commission work to those pages.

[jbrodhacker]

2837fe0 Added those if statements for you in review.html.erb

[Bejoty]

Awesome! Not sure how to test it, but I'll put make the reviews and revisions show up via the JS file. After that this page is done enough for this release.

[Bejoty]

If you can work on filling in those conditionals, that would be great

To be clear, what do you mean by filling them in? The ifs take care of most of it, and I was just going to add the review array items, since the revision

[jbrodhacker]

Text input for revision should not be accessible for the commissioner while waiting on the artist and vice versa.

[Bejoty]

Is that being covered by the commission status switching between "Review" and "Revision"?

[jbrodhacker]

Currently I have it such that there are conditionals that compare the size of the spec and review arrays (because the state of a commission is displayed to users). It should be covered by these conditionals, but I did not move the front end code to be in them.

[Bejoty]

Ah, alright, I'll take a look and see if I can make it work.

[Bejoty]

The textarea is there now, but it's catching an error on one of the status checks.

It also looks like there isn't a restriction on the artists submitting multiple calls for reviewing in a row before the customer responds in specification. This could cause some confusion if the customer revises more than one comment at one time, then still hangs in the revision stage. Is the artist restricted in a way I'm not aware?

[jbrodhacker]

That was one of the things I was talking about being outside of the conditional created for it. I'll see about fixing it.

[Bejoty]

Okay, planning to regroup after a bite to eat. I somehow forgot about the whole food thing for about 12 hours. I can stay up until probably ~2 and keep a somewhat sane mind.

[jbrodhacker]

73827de has updated the controller to successfully update the blobs in commission_current to have the price and revision. This may have been answered before but do we want to keep the reason for declining separate in the json object? It makes more sense to me that way.

[jbrodhacker]

Makes it easier for the front end to differentiate between just another revision and the reason for declining.

[Bejoty]

Works for me, yeah.

[jbrodhacker]

Okay, added it in 7afad0a :)

[Bejoty]

Woot woot! Okay, where's the current block?

[jbrodhacker]

The progress.html.erb has some commented spots that I made that need filling in

[Bejoty]

Ah yes. I'm not totally confident on what that loop does, haha.