-
-
Notifications
You must be signed in to change notification settings - Fork 730
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
Uk/1316 ui grid reports #1547
Conversation
…bject and 'all' array
…of data into byID and pristineByID
…levant info in group headers
Looks like some merge conflicts.... Could you take a look please @jeronimo? |
Fixed! |
Still showing up with conflicts :( |
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 :( |
Ok, it passed! |
Awesome! Over to you @oeoeaio |
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? |
There was a problem hiding this 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? |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 | ||
|
There was a problem hiding this comment.
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]) |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 | ||
|
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Closing with reports upgrade on the back burner |
Order and Distributors, Bulk Coop, Orders and Fulfillments have UI grid design reports.
It is possible to switch to old version as well.
TODO: