Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uk/1316 ui grid reports #1547

Closed
wants to merge 63 commits into from
Closed

Uk/1316 ui grid reports #1547

wants to merge 63 commits into from

Conversation

jeronimo
Copy link
Contributor

@jeronimo jeronimo commented Apr 25, 2017

Order and Distributors, Bulk Coop, Orders and Fulfillments have UI grid design reports.
It is possible to switch to old version as well.

TODO:

  • UX and people using reports need to decide if this is appropriate approach, which columns should be visible or not needed. And if any additional functionality is needed.
  • Replace other reports with the same styling.
  • To get rid off old versions of reports and refactor the code.

RohanM and others added 30 commits October 27, 2016 11:57
@daniellemoorhead daniellemoorhead requested a review from oeoeaio May 3, 2017 02:59
@daniellemoorhead daniellemoorhead modified the milestones: Next small release (1.8.11 or 1.9.1), v1.8.10 - Cock & Hen May 3, 2017
@lin-d-hop
Copy link
Contributor

Looks like some merge conflicts.... Could you take a look please @jeronimo?

@jeronimo
Copy link
Contributor Author

jeronimo commented May 8, 2017

Fixed!

@daniellemoorhead
Copy link
Contributor

Still showing up with conflicts :(

@jeronimo
Copy link
Contributor Author

Ok, fixed conflicts again. But there is another test failing in Travis which is not related with the code and it fails only in Travis :(

@jeronimo
Copy link
Contributor Author

Ok, it passed!

@daniellemoorhead
Copy link
Contributor

Awesome! Over to you @oeoeaio

@daniellemoorhead
Copy link
Contributor

Hey @jeronimo, very big apologies that we haven't looked at this yet. @oeoeaio is working on your smaller PRs this week, and will dedicate a day next week to looking at this.

@oeoeaio
Copy link
Contributor

oeoeaio commented Jun 16, 2017

Hey @jeronimo, just a general comment: I would really like to avoid having merge commits clogging up the commit history (eg. fdb1c59, 954530b, c60182c, 097636e and a89a08f) especially when they are just being used keep the branch up to date. With feature branches like this, rebasing against the current version of master is a much better approach. Could you please make sure that you are rebasing rather than merging in future?

Copy link
Contributor

@oeoeaio oeoeaio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @jeronimo, thanks so much for all of your work on this! It's looking great! Ping me if you want anything clarified. :)

@@ -181,20 +189,37 @@ def sales_tax
end

def bulk_coop
# -- Prepare date parameters
prepare_date_params params
if request.format.json?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would anticipate that the structure of this controller would ultimately change completely, so that all html requests would be caught in a universal before_filter that simply rendered the relevant html UI. Then, all of the main controller logic would be written to cater for JSON API requests made from html UI. Does that sound about right @jeronimo? Would that be acceptable @enricostano, or are you concerned about having a single controller handling both standard and API requests?

products: @report.products_serialized,
distributors: @report.distributors_serialized,
variants: @report.variants_serialized }
render json: report_data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part looks good 👍

end
send_data csv_string, :filename => "orders_and_distributors_#{timestamp}.csv"
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am assuming that we will ultimately remove the html section right? We won't need the csv functionality and we don't need to load any data to render the form.

We'll need to load the date params in orders to render the form, but perhaps we can do that in a before_filter?

products: @report.products_serialized,
distributors: @report.distributors_serialized,
variants: @report.variants_serialized }
render json: report_data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -7,3 +7,5 @@ angular.module("admin.indexUtils").directive "datepicker", ->
scope.$apply (scope) ->
# Fires ngModel.$parsers
ngModel.$setViewValue dateText
if attrs.value
ngModel.$setViewValue attrs.value
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't really what this directive is for. If you need to change the datepicker elements to rails form elements rather than pure angular elements, I would suggest removing the ng-model directive altogether (it is doing nothing) and using our custom watch-value-as directive instead.

That said, my preference (instead of c35a165) would be to inject the search data as a service, and have everything be pure angular from there on. I don't like hacking rails form elements to make them 'work' with angular. Too many pitfalls, and too hard to work out what is going wrong when you have multiple custom directives all trying to manipulate the value of the form element directly.

end

it "should denormalise order and distributor details for display as csv" do
subject = OrderAndDistributorReport.new [@order]
context "Old version" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How to you feel about describing these contexts as html and json instead of old and new?

expect(report.distributors_serialized.options[:each_serializer]).to eq(Api::Admin::Reports::EnterpriseSerializer)
end
end

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this blank space, and the one below

before { order.line_items << line_item }

it '#table_items returns one line_item' do
expect(report.table_items).to eq([line_item])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would normally do .to eq [line_item]. Do you have a preference for doing it with parentheses? Doesn't really matter, I'm more thinking about what we do as a convention.

# result['tags'].each do |tag|
# expect(tag['rules']).to be nil
# end
# end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

???

it '#paid?' do
expect(subject.paid?).to eq "No"
end

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whitespace

orders: @report.orders_serialized,
products: @report.products_serialized,
variants: @report.variants_serialized }
render json: report_data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be cool to use the OrdersAndFulfillmentSerializer here:

render json: @report, serializer: Api::Admin::Reports::OrdersAndFulfillmentSerializer

Then you could remove the line_items_serialized, orders_serialized methods from the report, and the report_data hash here. I think this is what I was intending to do in my spike, but I never got around to it.

@@ -0,0 +1,63 @@
class Api::Admin::Reports::OrderSerializer < ActiveModel::Serializer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you describe at a high level how you're designing this? I don't really understand why we are adding this new set of serializers or how the current reports in lib/open_food_network are related to this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sauloperez the basic idea is that the user loads a report as html, and then a separate request for report data is sent via AJAX to ReportsController which uses the lib/open_food_network classes to load data for displaying in different classes of report, this data is then serialised and rendered as JSON, which is consumed by the ui-grids library and rendered dynamically on the page.

Copy link
Contributor

@sauloperez sauloperez Jul 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that the way ui-grids works? Sounds a bit weird to me having to load the HTML and the data separately in two different requests.

Copy link
Contributor

@oeoeaio oeoeaio Jul 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, maybe I wasn't clear, I don't mean that ui-grids needs to receive JSON, I just mean that it takes data and renders it in the DOM. ui-grid isn't continuously pinging the server for data or anything like that.

@lin-d-hop
Copy link
Contributor

Closing with reports upgrade on the back burner

@lin-d-hop lin-d-hop closed this Dec 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants