-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy patharchived github issues.html
4379 lines (3331 loc) · 212 KB
/
archived github issues.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html>
<head>
<meta charset="utf-8"/>
<title>dixonandmoe/imagewall Issues</title>
</head>
<body>
<h1>Closed Issues exported from dixonandmoe/imagewall GitHub repository</h1>
<article>
<h2>Included excluded format</h2>
<h4>#<span class="issue_number">198</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-11 12:33:16 UTC</time></p>
<p>Closed: <time class="closed">2017-08-11 12:33:24 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Footer link</h2>
<h4>#<span class="issue_number">197</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-10 20:26:01 UTC</time></p>
<p>Closed: <time class="closed">2017-08-10 20:31:37 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Sundry fixes</h2>
<h4>#<span class="issue_number">196</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-10 17:05:15 UTC</time></p>
<p>Closed: <time class="closed">2017-08-10 17:05:24 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Rom price</h2>
<h4>#<span class="issue_number">195</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-10 14:09:52 UTC</time></p>
<p>Closed: <time class="closed">2017-08-10 14:10:51 UTC</time></p>
<br>
<p class="description">Under conditions*, display starting price per square foot rather than exact total. In this case, buy button leads to contact form rather than purchase sequence.
A few extras that came along:
- Add error messages to tax address form.
- Prefer signup over login modal.
- Don't save design unless necessary on purchase.
* Currently: international orders and projects over $150,000.</p>
</article>
<article>
<h2>Rearrange mobile menu</h2>
<h4>#<span class="issue_number">194</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-09 14:38:30 UTC</time></p>
<p>Closed: <time class="closed">2017-08-09 14:38:39 UTC</time></p>
<br>
<p class="description">Fixes actual issue in #105. iPhone buttons cover bottom of page. Also fixes scrolling of mobile menu, and reprioritizes menu items.</p>
</article>
<article>
<h2>Don't scroll past last swatch.</h2>
<h4>#<span class="issue_number">193</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-08 18:09:15 UTC</time></p>
<p>Closed: <time class="closed">2017-08-08 18:09:23 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Purchases</h2>
<h4>#<span class="issue_number">192</span> - <span class="user">markjanzer</user></h4>
<p>Created: <time class="created">2017-08-04 01:56:26 UTC</time></p>
<p>Closed: <time class="closed">2017-08-04 02:10:52 UTC</time></p>
<br>
<p class="description">Different buy options and purchase flow depending on whether the design is not paid for, half paid, or fully paid. Added new emails, PDFs, and modals.
Loading modal for Stripe purchases
Removed unnecessary transition object.
Remove API calls on already purchased designs (so price is not recalculated). Also remove stats on purchased designs.
Fix error where UNSAVED was being set to true instantly (thus always asking if a user really wants to redirect).
Add tag for purchases in the profile view.
All designs that are of type "design" are now manipulable by anyone, with the same intent as PR #186.
If user is on a design page that they do not own and they press the buy button:
If the user is logged in – the design is saved as a copy and buy process is started.
If the user is not logged in and no changes were made – the buy process is started.
If the user is not logged in and changes were made – the user is prompted to login/make an account. If they do so, the design is saved as a copy and then buy process is started.
</p>
<section class="comment">
<h4 class="user">markjanzer</h4>
<time class="created">2017-08-04 02:17:28 UTC</time>
<p>Hey @twastvedt , can you look over the views "/invoices/paid-full-invoice.html.erb" and "/invoice_mailer/paid_full_invoice_email.html.erb" and "/invoice_mailer/paid_full_invoice_email.text.erb"? I drafted them, and they are very similar to their "paid_half" counterparts, but check them out and change what you like before we deploy.
We will also have to update the `is_paid_half` and `is_paid_full` columns of the purchases in the database. Just let me know if there are any that are theoretically paid in full, otherwise I'll set them all to `is_paid_half: true` tomorrow.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-04 14:16:44 UTC</time>
<p>@markjanzer As you say, very few changes. I think this looks good. I may take a pass through all of the communication later.
Sorry if I wasn't clear with my note on the issue with the list of emails ( #182 ). You're fine to set them all to `is_paid_half`. Thanks!</p>
</section>
</article>
<article>
<h2>Move design name event to design-option to prevent error when form is…</h2>
<h4>#<span class="issue_number">191</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-03 22:03:47 UTC</time></p>
<p>Closed: <time class="closed">2017-08-03 22:03:54 UTC</time></p>
<br>
<p class="description">…n't shown.</p>
</article>
<article>
<h2>Update price when switching hardware system.</h2>
<h4>#<span class="issue_number">190</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-03 22:00:43 UTC</time></p>
<p>Closed: <time class="closed">2017-08-03 22:00:52 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Pare updatemesh calls</h2>
<h4>#<span class="issue_number">189</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-03 21:58:55 UTC</time></p>
<p>Closed: <time class="closed">2017-08-03 21:59:05 UTC</time></p>
<br>
<p class="description">Reviewed all calls to updateMesh and removed any unnecessary.</p>
</article>
<article>
<h2>Remove dependence on swatch display order.</h2>
<h4>#<span class="issue_number">188</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-03 21:02:08 UTC</time></p>
<p>Closed: <time class="closed">2017-08-03 21:02:19 UTC</time></p>
<br>
<p class="description">@moeamaya Just wanted to draw your attention to this, no action necessary. If painted and anodized were not ordered alphabetically, or there were another aluminum material ordered before painted, the code broke. This should make it more robust, I think.</p>
</article>
<article>
<h2>Fix design saving</h2>
<h4>#<span class="issue_number">187</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-03 20:56:04 UTC</time></p>
<p>Closed: <time class="closed">2017-08-03 20:57:20 UTC</time></p>
<br>
<p class="description">#171 introduced a bug in design saving where all properties of the DESIGN object were saved, not just the parameters. This fixes that, which also means that loading a design will cause all the setter functions to run, ensuring an internally consistent set of parameters.</p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-03 20:57:13 UTC</time>
<p>@moeamaya I'm pretty confident this fixes the full DESIGN object saving issue that you noticed. Let me know if you see differently.</p>
</section>
</article>
<article>
<h2>Show controls for designs user doesn't own.</h2>
<h4>#<span class="issue_number">186</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-08-03 19:17:22 UTC</time></p>
<p>Closed: <time class="closed">2017-08-04 02:10:16 UTC</time></p>
<br>
<p class="description">@markjanzer Here's the naive start. Let me know what you discover. Thanks!</p>
<section class="comment">
<h4 class="user">markjanzer</h4>
<time class="created">2017-08-04 02:10:16 UTC</time>
<p>We implement this in #194! Didn't take too long to do!
You can see all the changes made for it here: https://github.com/dixonandmoe/imagewall/pull/192/commits/24811b8b146d29154d74aa40963bf0e73b819bc9
</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-04 13:15:30 UTC</time>
<p>@markjanzer Awesome. Thanks so much!</p>
</section>
</article>
<article>
<h2>Added Panels Only toggle</h2>
<h4>#<span class="issue_number">185</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-08-02 19:21:37 UTC</time></p>
<p>Closed: <time class="closed">2017-08-09 19:39:12 UTC</time></p>
<br>
<p class="description">A few things here before we can merge.
1) I'm sending DESIGN.depth = 0, so that will need to be updated in the spreadsheet as it's currently returning the same price as with hardware.
2) To simplify things, I set the application type as 'wall' whenever panels-only is selected.
3) In addition, I'm adding an opacity layer over the other system options so they aren't clickable, but still visible (see image).
4) For now I added skinny vertical mullions as a stand-in for viewing how many panels there are. Seems pretty good so far (see image).
5) Also added some copy on the Depth slider, which is a little goofy. You might wanna go in there and improve that.
Closes #106 </p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-03 18:31:45 UTC</time>
<p>Moe,
Ok. I like the UI approach. Internally, though, I'd like to find a more consistent way to represent this. What are the implications of adding a new Application (`none`?)? There would be a corresponding system (currently defined in the spreadsheet as `flatPanels`). This seems pretty straightforward to me, but maybe I'm missing something?
Did you test saving/loading a design? In my environment it looks like something is broken there. When I load a panels only design I get the context wall and shadow but no panels. The Panels Only disabling overlay also doesn't show. If I try to switch back to a hardware system then the context wall disappears and won't reappear.
Thanks,
Trygve Wastvedt
R&D Engineer
816-423-8352 [email protected]<mailto:[email protected]>
[ZAHNER®]<http://www.azahner.com/>
[120 Years of Innovation]<http://www.azahner.com/120>[Twitter]<http://www.twitter.com/azahner>[Facebook]<https://www.facebook.com/zahnermetal?_rdr>[Linkedin]<http://www.linkedin.com/company/468525>
A. ZAHNER CO. www.azahner.com<http://www.azahner.com/>
1400 E. 9th St, Kansas City, MO 64106
Try the latest tools from Zahner: ShopFloor<http://www.azahner.com/shopfloor>™
________________________________
From: Moe Amaya <[email protected]>
Sent: Wednesday, August 2, 2017 2:21:38 PM
To: dixonandmoe/imagewall
Cc: Subscribed
Subject: [dixonandmoe/imagewall] Added Panels Only toggle (#185)
A few things here before we can merge.
1. I'm sending DESIGN.depth = 0, so that will need to be updated in the spreadsheet as it's currently returning the same price as with hardware.
2. To simplify things, I set the application type as 'wall' whenever panels-only is selected.
3. In addition, I'm adding an opacity layer over the other system options so they aren't clickable, but still visible (see image).
4. For now I added skinny vertical mullions as a stand-in for viewing how many panels there are. Seems pretty good so far (see image).
[screen shot 2017-08-02 at 12 13 02 pm]<https://user-images.githubusercontent.com/1373293/28890776-12756c4c-777d-11e7-9ad9-6f691fab31cb.png>
Closes #106<https://github.com/dixonandmoe/imagewall/issues/106>
________________________________
You can view, comment on, or merge this pull request online at:
https://github.com/dixonandmoe/imagewall/pull/185
Commit Summary
* added Panels Only toggle
File Changes
* M app/assets/javascripts/design/design-option-system.es6<https://github.com/dixonandmoe/imagewall/pull/185/files#diff-0> (49)
* M app/assets/javascripts/design/design-scene.es6<https://github.com/dixonandmoe/imagewall/pull/185/files#diff-1> (5)
* M app/assets/stylesheets/custom/designs/_index.scss<https://github.com/dixonandmoe/imagewall/pull/185/files#diff-2> (13)
* M app/views/design/_pane-size.html.erb<https://github.com/dixonandmoe/imagewall/pull/185/files#diff-3> (1)
* M app/views/design/_pane-system.html.erb<https://github.com/dixonandmoe/imagewall/pull/185/files#diff-4> (16)
* M vendor/assets/javascripts/imageWallMesh.js<https://github.com/dixonandmoe/imagewall/pull/185/files#diff-5> (6)
Patch Links:
* https://github.com/dixonandmoe/imagewall/pull/185.patch
* https://github.com/dixonandmoe/imagewall/pull/185.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/dixonandmoe/imagewall/pull/185>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHu0EkqPCg54ou3uJOIWi03Ovd--NWaMks5sUMxBgaJpZM4OrimH>.
</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-08-03 19:08:43 UTC</time>
<p>Ahhh I really like the idea of Application "None". What do you think of that from a UI perspective also, or do you prefer the way it's setup now?
I did test saving, but that was towards the end of the day. Let me do another full pass.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-03 19:13:45 UTC</time>
<p>Great. I like the way you've organized it now, as it's really a higher level distinction than wall/facade/etc. On further consideration, can we just call this application "flatPanels" behind the scenes, to open future doors to naming other "none" application types? Again, I like the UI as you have it now.
Thanks,
Trygve Wastvedt
R&D Engineer
816-423-8352 [email protected]<mailto:[email protected]>
[ZAHNER®]<http://www.azahner.com/>
[120 Years of Innovation]<http://www.azahner.com/120>[Twitter]<http://www.twitter.com/azahner>[Facebook]<https://www.facebook.com/zahnermetal?_rdr>[Linkedin]<http://www.linkedin.com/company/468525>
A. ZAHNER CO. www.azahner.com<http://www.azahner.com/>
1400 E. 9th St, Kansas City, MO 64106
Try the latest tools from Zahner: ShopFloor<http://www.azahner.com/shopfloor>™
________________________________
From: Moe Amaya <[email protected]>
Sent: Thursday, August 3, 2017 2:08:43 PM
To: dixonandmoe/imagewall
Cc: Trygve Wastvedt; Comment
Subject: Re: [dixonandmoe/imagewall] Added Panels Only toggle (#185)
Ahhh I really like the idea of Application "None". What do you think of that from a UI perspective also, or do you prefer the way it's setup now?
I did test saving, but that was towards the end of the day. Let me do another full pass.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/dixonandmoe/imagewall/pull/185#issuecomment-320062302>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHu0EhSFNO4DOfghuqxzBnUEuqD5tsSqks5sUhq7gaJpZM4OrimH>.
</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-08-07 18:56:48 UTC</time>
<p>@twastvedt I fixed up the saving issue and added a variable to save the application type previously selected.
I am having a small issue sending DESIGN.application type of "flatPanels", the price returns a `NaN` value. So for now that line https://github.com/dixonandmoe/imagewall/pull/185/files#diff-3c7a09a2fef2b4a2559e8a2bd6f132b8R103 is commented out.
But otherwise I think this is ready to go. Note on Friday I tried a more complicated integration going into the depths of the IW.settings and DesignModel, but it broke way too many things for something as simple as sending a new application type. That value does persist deep into the app so instead when a user toggles to Panels Only, I set the application type to wall, then run `setApplicationType` then set the application type to 'flatPanels'.
Not sure if you want to build out a more robust solution but with my limited knowledge of the spreadsheet and system settings, I think this solution works for now.
</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-07 21:51:34 UTC</time>
<p>Cool. I updated the spreadsheet so it should be ready now for "flatPanels". I would love to build out a more robust solution! Always! Sometime. If this works though, that works for me.
________________________________
From: Moe Amaya <[email protected]>
Sent: Monday, August 7, 2017 1:56 PM
To: dixonandmoe/imagewall
Cc: Trygve Wastvedt; Mention
Subject: Re: [dixonandmoe/imagewall] Added Panels Only toggle (#185)
@twastvedt<https://github.com/twastvedt> I fixed up the saving issue and added a variable to save the application type previously selected.
I am having a small issue sending DESIGN.application type of "flatPanels", the price returns a NaN value. So for now that line https://github.com/dixonandmoe/imagewall/pull/185/files#diff-3c7a09a2fef2b4a2559e8a2bd6f132b8R103 is commented out.
But otherwise I think this is ready to go. Note on Friday I tried a more complicated integration going into the depths of the IW.settings and DesignModel, but it broke way too many things for something as simple as sending a new application type. That value does persist deep into the app so instead when a user toggles to Panels Only, I set the application type to wall, then run setApplicationType then set the application type to 'flatPanels'.
Not sure if you want to build out a more robust solution but with my limited knowledge of the spreadsheet and system settings, I think this solution works for now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/dixonandmoe/imagewall/pull/185#issuecomment-320750299>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHu0EhvDo80ajwBDlY5YqzFjEZ39wcGBks5sV13xgaJpZM4OrimH>.
</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-08-08 21:32:13 UTC</time>
<p>Fixed the display value when Panels Only selected. I added back in the DESIGN.application = 'flatPanels' but it's still causing an error in the spreadsheet calculation. Also realized we don't even send that value.
Here's the params of the pricing object
- "panelNumber"=>5,
- "overallWidth"=>180,
- "overallHeight"=>132,
- "panelWidth"=>36,
- "panelHeight"=>132,
- "gridSize"=>1.25,
- "gridType"=>"Staggered",
- "perfShape"=>"Circle",
- "reductionType"=>"None",
- "reductionPercent"=>10,
- "panelMaterial"=>"solanumSteel",
- "structureMaterial"=>"painted",
- "city"=>"Chicago",
- "system"=>"angleAnchor",
- "mullion"=>nil,
- "anchorDepth"=>nil,
- "distance"=>509,
- "windCategory"=>0,
- "exposure"=>0,
- "minPanelThickness"=>0.054
</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-09 15:28:06 UTC</time>
<p>I couldn't stop myself, I went and made the robust solution. I think the above commits should fix everything. Sorry, I realize that this was more difficult after I went and made all those changes. I didn't actually make too many changes, just added a `case` to `design-scene:setApplicationType` and `design.model:updateSystem`.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-08-09 15:29:28 UTC</time>
<p>No that's great! I cringed a few times while reviewing the changes on github, so I'm happy you were able to clean it up fairly quickly.
I'll review it then we can merge it in.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-08-09 19:29:53 UTC</time>
<p>@twastvedt Everything looks good! The only thing I noticed was that you lowered the floor whenPanels Only is selected, just double checking if that was intentional.
If that's the case, I think this is ready to merge.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-09 19:39:04 UTC</time>
<p>@moeamaya The floor is lower than for walls, but the same as facades. Yes, intentional. Thanks for checking!</p>
</section>
</article>
<article>
<h2>Export image</h2>
<h4>#<span class="issue_number">184</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-31 22:24:38 UTC</time></p>
<p>Closed: <time class="closed">2017-08-09 16:08:35 UTC</time></p>
<br>
<p class="description"></p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-31 22:27:10 UTC</time>
<p>@moeamaya I fixed the image export so that it's always aligned to the wall. I think it would be most logical for those images to always be the aspect ratio of the wall itself, so, no margins in the image. However, it looks like something is forcing the design images to always save, or at least display, in a 2:1 aspect ratio. Do you know where that happens, and how to change it? Or am I better off just accepting the 2:1?</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-08-01 17:18:44 UTC</time>
<p>Pulled down your branch and I tried both using the Export Image and Saving a design and neither seemed to be generating an image for me. No errors in the console, but both Chrome and Firefox on Mac return a blank png image.
Note I'm also not sure about the 2:1, maybe @markjanzer knows why that is?</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-03 20:02:07 UTC</time>
<p>Ah. Sorry about that. Didn't test the first part after finishing the second part. The current version works for me, excepting my question above. Thanks!</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-09 16:08:22 UTC</time>
<p>@markjanzer @moeamaya Nevermind. I just didn't understand how imgix urls work. What a cool tool. I love the automatic cropping with edge detection. Anyways, I was able to get the correct aspect ratio by turning off cropping for those requests.</p>
</section>
</article>
<article>
<h2>Don't save entire DESIGN object to database</h2>
<h4>#<span class="issue_number">183</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-31 22:24:20 UTC</time></p>
<p>Closed: <time class="closed">2017-08-04 13:16:51 UTC</time></p>
<br>
<p class="description">Moe: There's an interesting side effect of your refactored DesignModel I ran into. Seems like all the methods within the DesignModel are persisting to the database. Not sure if this was the intention or not, but it did cause a bug where when I changed the this.displayValueMap the new values are overwritten by what's stored on that Design. For now I renamed the method to this.displayValMap so it will ignore what's stored in json, but this might be something you look at before too long.</p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-04 13:16:51 UTC</time>
<p>Fixed this with #187.</p>
</section>
</article>
<article>
<h2>Purchase strangeness</h2>
<h4>#<span class="issue_number">182</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-28 20:09:46 UTC</time></p>
<p>Closed: <time class="closed">2017-08-09 19:40:42 UTC</time></p>
<br>
<p class="description">@moeamaya, @markjanzer
Something strange is going on with purchased designs. Here's what I'm seeing:
1. Log in, create design, purchase/get invoice.
4. Everything can still be edited and saved over the original design. However if I go to my profile there are now two apparently identical designs, the one with the original ID and one with a new ID. If I click on the new one, I'm returned to the designer with an empty panel (no buttons, not even 'buy').
What of this is intended? A couple things seem strange to me, but let me know if I'm missing something:
1. If a new ID is created upon purchase, the url should change and the controls should be removed upon completion of the down-payment. I also think that the two identical designs in the profile is confusing - maybe the old one isn't preserved but the user is able to edit the purchased design and save as a new ID?
2. Shouldn't a buy button be displayed on the empty panel of a purchased design so that the user can make the second payment? Or, as suggested above, the full control panel is displayed but saving creates a new design.</p>
<section class="comment">
<h4 class="user">markjanzer</h4>
<time class="created">2017-07-28 21:58:25 UTC</time>
<p>Hey Trygve,
I agree that it's strange to see two identical designs on the profile page. We can put a tag on it to indicate that one of them is a purchase (and thus is not editable).
We were originally conflicted with allowing someone to pay the second for the second half of an imagewall when we do not know if they have paid for the first half. For instance, the Stripe transaction could fail or the invoice could be unpaid and the system wouldn't know. Thinking about it more, the worst case scenario would be someone invoices themselves for both halves one after another without having paid either. I guess we won't concern ourselves with this and let them attempt to pay both halves immediately if they wish.
That being said, now we will allow the user to purchase the second half once they have purchased the first (without our knowledge of whether the purchase actually went through), so we'll have the buy button appear on the purchase. The buy button will not appear on purchases where the user has already paid both halves. In addition, we'll add buttons in the modal for a successful purchase so a user can continue editing, or view the purchase (the uneditable copy of the imagewall).
I'll start working on this today, and will hope to have it done next week. Also, once I push the changes up I'll need to find out which Designs are paid half and which are paid in full so we can edit their status in the database. Does this sound good to you?</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-31 13:37:44 UTC</time>
<p>Mark,
This sounds great. Thanks for clarifying. I do remember the discussions about the purchasing logic, and I apologize that I hadn't investigated the full experience before now.
I think the workflow as you've outlined it sounds just fine. I have an alternative thought for part of it though. If you're already mostly through it, or the below is more complicated, don't worry about it.
I think we can assume that after purchasing a design, the user is done, for the time at least, with that design, so we don't need buttons in the modal to continue editing. I'd also guess that most of the time they don't need the editable version either. What if upon checkout the design becomes a 'purchase', rather than a new 'purchase' design being created? There could then be some explanatory text (which I can write) and a button in the mostly blank purchased design sidebar which would create an editable copy of a purchased design.
If this simplifies things, great. If not, I'd be curious to know why, but am just fine with the approach you laid out for now.
Thanks,
Trygve Wastvedt
R&D Engineer
816-423-8352 [email protected]<mailto:[email protected]>
[ZAHNER®]<http://www.azahner.com/>
[120 Years of Innovation]<http://www.azahner.com/120>[Twitter]<http://www.twitter.com/azahner>[Facebook]<https://www.facebook.com/zahnermetal?_rdr>[Linkedin]<http://www.linkedin.com/company/468525>
A. ZAHNER CO. www.azahner.com<http://www.azahner.com/>
1400 E. 9th St, Kansas City, MO 64106
Try the latest tools from Zahner: ShopFloor<http://www.azahner.com/shopfloor>™
________________________________
From: Mark Janzer <[email protected]>
Sent: Friday, July 28, 2017 4:58:25 PM
To: dixonandmoe/imagewall
Cc: Trygve Wastvedt; Author
Subject: Re: [dixonandmoe/imagewall] Purchase strangeness (#182)
Hey Trygve,
I agree that it's strange to see two identical designs on the profile page. We can put a tag on it to indicate that one of them is a purchase (and thus is not editable).
We were originally conflicted with allowing someone to pay the second for the second half of an imagewall when we do not know if they have paid for the first half. For instance, the Stripe transaction could fail or the invoice could be unpaid and the system wouldn't know. Thinking about it more, the worst case scenario would be someone invoices themselves for both halves one after another without having paid either. I guess we won't concern ourselves with this and let them attempt to pay both halves immediately if they wish.
That being said, now we will allow the user to purchase the second half once they have purchased the first (without our knowledge of whether the purchase actually went through), so we'll have the buy button appear on the purchase. The buy button will not appear on purchases where the user has already paid both halves. In addition, we'll add buttons in the modal for a successful purchase so a user can continue editing, or view the purchase (the uneditable copy of the imagewall).
I'll start working on this today, and will hope to have it done next week. Also, once I push the changes up I'll need to find out which Designs are paid half and which are paid in full so we can edit their status in the database. Does this sound good to you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/dixonandmoe/imagewall/issues/182#issuecomment-318771419>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHu0Eq4iHLIldle9TcBQTCk7RTyRCwwQks5sSlmBgaJpZM4OnB7N>.
</p>
</section>
<section class="comment">
<h4 class="user">markjanzer</h4>
<time class="created">2017-08-01 18:55:32 UTC</time>
<p>Hi Trygve,
No worries, I could have done more to clarify the complete purchase flow.
There are a couple issues with turning Designs with a type of "design" into a Design with a type of "purchase."
We wanted to build out the purchasing system so it was possible for an architect to send an unalterable Imagewall design to a contractor (who is possibly not logged in) and have the contractor purchase that design. If designs were turned into the purchases (and thus made unalterable), we would have to change the system to only allow the owner of the Imagewall to purchase it.
A less important reason is that we built out the purchasing flow with the (possibly false) assumption that the editable version could be used as means of continuing communication between Zahner and the customer. Zahner would have access to it through the "original_id" of the purchase to identify the original and the user would still have the original saved, so they would both have access to an editable copy. So if the user wanted to change specs after paying the first half or Zahner found that it needed to be different dimensions, the design could be used as a shared prototype.
However, if you want the user to be directed to the purchase page with an open success modal upon successful purchase rather than adding options for routing to the success modal, we can do that instead! I haven't built out those buttons on the success modal yet.
Thanks for the input! I hope to get this to you soon!</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-03 00:06:58 UTC</time>
<p>Mark,
Ok. Thanks for the thoughts. Don’t know if Moe mentioned this, but I’m in training Tuesday, Wednesday, and Thursday AM this week. So, I’ll take a look at this first thing Thursday afternoon and get back to you.
Thanks,
Trygve Wastvedt
R&D Engineer
816-423-8352 [email protected]<mailto:[email protected]>
[ZAHNER®]<http://www.azahner.com/>[Twitter]<http://www.twitter.com/azahner>[Facebook]<https://www.facebook.com/zahnermetal?_rdr>[Linkedin]<http://www.linkedin.com/company/468525>[Download our iPhone App]<http://itunes.apple.com/us/app/zahner/id403745012?mt=8>
A. ZAHNER CO. www.azahner.com<http://www.azahner.com/>
1400 E. 9th St, Kansas City, MO 64106
Try the latest tool from Zahner: ShopFloor<http://www.shopfloorapp.com>™
From: Mark Janzer [mailto:[email protected]]
Sent: Tuesday, August 01, 2017 1:56 PM
To: dixonandmoe/imagewall <[email protected]>
Cc: Trygve Wastvedt <[email protected]>; Author <[email protected]>
Subject: Re: [dixonandmoe/imagewall] Purchase strangeness (#182)
Hi Trygve,
No worries, I could have done more to clarify the complete purchase flow.
There are a couple issues with turning Designs with a type of "design" into a Design with a type of "purchase."
We wanted to build out the purchasing system so it was possible for an architect to send an unalterable Imagewall design to a contractor (who is possibly not logged in) and have the contractor purchase that design. If designs were turned into the purchases (and thus made unalterable), we would have to change the system to only allow the owner of the Imagewall to purchase it.
A less important reason is that we built out the purchasing flow with the (possibly false) assumption that the editable version could be used as means of continuing communication between Zahner and the customer. Zahner would have access to it through the "original_id" of the purchase to identify the original and the user would still have the original saved, so they would both have access to an editable copy. So if the user wanted to change specs after paying the first half or Zahner found that it needed to be different dimensions, the design could be used as a shared prototype.
However, if you want the user to be directed to the purchase page with an open success modal upon successful purchase rather than adding options for routing to the success modal, we can do that instead! I haven't built out those buttons on the success modal yet.
Thanks for the input! I hope to get this to you soon!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<https://github.com/dixonandmoe/imagewall/issues/182#issuecomment-319463612>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHu0EtVLP6gXirErWorWyiznpozcgT2eks5sT3SlgaJpZM4OnB7N>.
</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-03 19:49:04 UTC</time>
<p>@markjanzer I think we're good to go:
```
irb(main):027:0> Design.where(type: "purchase").select(:purchaser_email).each { |u| y u.purchaser_email }
Design Load (1.5ms) SELECT "designs"."purchaser_email" FROM "designs" WHERE "designs"."type" = $1 ORDER BY "designs"."position" ASC [["type", "purchase"]]
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
```
I recognize all these email addresses.</p>
</section>
<section class="comment">
<h4 class="user">markjanzer</h4>
<time class="created">2017-08-04 18:49:59 UTC</time>
<p>Oops, didn't check this thread! I just updated the "is_paid_half" column on all purchases.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-08-09 19:40:42 UTC</time>
<p>Closed by #192.</p>
</section>
</article>
<article>
<h2>Add reduction options with sliders for intensity and angle</h2>
<h4>#<span class="issue_number">181</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-07-27 23:20:01 UTC</time></p>
<p>Closed: <time class="closed">2017-07-31 22:23:27 UTC</time></p>
<br>
<p class="description">Closes #122.
Not sure if we also need to update price when reductions are added. For now it's commented out but we'll need to add it back in the controller and spreadsheet if it's needed.
Hiding the sliders when "None" is selected. But otherwise we display.
</p>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-27 23:21:39 UTC</time>
<p>@twastvedt Also not sure what the extents of angle are. 0-360?</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-28 13:00:21 UTC</time>
<p>Awesome. Yes, 0-360 sounds good. The angle only affects the linear reduction though, right? And yes, this should trigger a price update, as the number of punched holes changes the fabrication time.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-28 21:36:35 UTC</time>
<p>@twastvedt Seems like this one is ready to go. If no objections, I'll go ahead and merge this in on Monday.
</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-31 13:44:19 UTC</time>
<p>Looks good to me!</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-31 13:46:50 UTC</time>
<p>Actually, it looks like saving is a bit broken (slider values don't match sliders when loading), and Random and Linear are flipped when changing the display text.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-31 17:54:58 UTC</time>
<p>Ah good catches. I'll fix those up before I merge.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-31 22:07:59 UTC</time>
<p>Ok @twastvedt fixed up both the slider values setting and the correct order for Random and Linear.
However, there's an interesting side effect of your refactored DesignModel I ran into. Seems like all the methods within the DesignModel are persisting to the database, this is directly out of database:
Not sure if this was the intention or not, but it did cause a bug where when I changed the `this.displayValueMap` the new values are overwritten by what's stored on that Design. For now I renamed the method to `this.displayValMap` so it will ignore what's stored in json, but this might be something you look at before too long.
Otherwise, this should be ready to go.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-31 22:23:10 UTC</time>
<p>@moeamaya Shoot. That was definitely not intended. Unfortunately I'm out until Thursday afternoon, but I'll look at this then.</p>
</section>
</article>
<article>
<h2>Don't recreate geometry when toggling context. ...</h2>
<h4>#<span class="issue_number">180</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-27 20:59:19 UTC</time></p>
<p>Closed: <time class="closed">2017-07-28 14:39:04 UTC</time></p>
<br>
<p class="description">Define context as everything but wall.</p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-27 20:59:37 UTC</time>
<p>Need to hide host on screen and ceiling.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-27 23:18:24 UTC</time>
<p>Looks pretty good to me. </p>
</section>
</article>
<article>
<h2>Hardware Color Picker</h2>
<h4>#<span class="issue_number">179</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-07-24 21:58:37 UTC</time></p>
<p>Closed: <time class="closed">2017-07-31 18:33:19 UTC</time></p>
<br>
<p class="description">This is still a WIP. I ended up adding a bunch of code to make it functional, but now I think it needs a bit of cleanup before we merge it in. This will close #79.</p>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-24 22:53:17 UTC</time>
<p>Ok @twastvedt I refactored the `initColorPicker` method with DesignApp to clean up a bunch of the redundancies. I think this is ready to merge, but I want to check with you if we should call updatePrice for the painted hardware or not worry about that at this time?</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-24 23:24:07 UTC</time>
<p>@moeamaya Thanks for checking. Changing the hardware finish (raw, painted, anodized) require a price update, but changes to the color itself (within painted or anodized) don't. I'm thinking that amounts to a "yes" though, right?</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-24 23:40:01 UTC</time>
<p>Ah crap there's 3 types for that?? I just thought painted lol. Aight I'll need a few more hours to add those options. But I suppose that will be a yes then. We'll have to work through this together @twastvedt then before we push it up.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-24 23:51:10 UTC</time>
<p>@moeamaya sure, no problem. I'm off tomorrow, but I'll dive in Wednesday and check over what you have.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-26 21:45:30 UTC</time>
<p>The PR is ready to check out @twastvedt. We also need to coordinate on the spreadsheet and DESIGN parameters in the Rails controller.
Also added a nice little feature when selecting a color where it shows on the material swatch now.
</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-27 20:30:37 UTC</time>
<p>I like the color update!
It looks like nothing prevents someone from creating an anodized wall with a color that isn't an anodized option. If you select 'painted', then switch to 'anodized', and then don't select a color, you end up with the painted color, but the anodized finish selected.
Per my earlier comment, changing the hardware finish should trigger a price update. (Changing color within a finish doesn't need to, but it could and that wouldn't be a problem if it's easier that way.) I tried uncommenting the `getPrice` in `updateHardware`, but that didn't seem to do anything. Probably faster if you enable that?</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-27 23:25:18 UTC</time>
<p>For the anodized wall, if they click that swatch should we default to the first color?
And for the price update, I'm leery of updating those controller methods mostly because I've broke the spreadsheet too many times to count now. I can call the method, but I prefer if you update the parameters that are sent back to your spreadsheet.</p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-28 13:01:40 UTC</time>
<p>Oh sure, no problem! I'll handle the spreadsheet interface. I think defaulting to the first color sounds just fine. Thanks!</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-28 23:13:22 UTC</time>
<p>Ok this one should be ready to go now. I made it so that anytime anodized is clicked, we update the wall or the hardware with only those limited options. </p>
</section>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-31 13:58:45 UTC</time>
<p>Looking great. What were you thinking needs to change in the spreadsheet parameters? I removed the static value for `structureMaterial`. Anything else you had in mind? I don't need the color of the hardware for pricing, at least for now.</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-31 17:55:38 UTC</time>
<p>Nope I think that's it. Should we go ahead and merge then?</p>
</section>
</article>
<article>
<h2>Add modal for test text input.</h2>
<h4>#<span class="issue_number">178</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-21 19:01:33 UTC</time></p>
<p>Closed: <time class="closed">2017-07-21 19:01:42 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Added dropdown and 3 most recent saved imagewalls</h2>
<h4>#<span class="issue_number">177</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-07-21 00:39:50 UTC</time></p>
<p>Closed: <time class="closed">2017-07-21 20:51:44 UTC</time></p>
<br>
<p class="description">Closes #60
</p>
</article>
<article>
<h2>Input limit</h2>
<h4>#<span class="issue_number">176</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-07-19 21:38:58 UTC</time></p>
<p>Closed: <time class="closed">2017-07-20 17:31:05 UTC</time></p>
<br>
<p class="description">For the perf Input I added a small if statement to add `this.perfMin` and `this.perfMax` to handle when a user changes the grid size. Should also close #124 </p>
</article>
<article>
<h2>View improvements</h2>
<h4>#<span class="issue_number">175</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-19 18:34:41 UTC</time></p>
<p>Closed: <time class="closed">2017-07-19 18:40:55 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Remove debug statements.</h2>
<h4>#<span class="issue_number">174</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-18 13:36:31 UTC</time></p>
<p>Closed: <time class="closed">2017-07-18 13:36:42 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Fix Design model problems</h2>
<h4>#<span class="issue_number">173</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-17 21:32:08 UTC</time></p>
<p>Closed: <time class="closed">2017-07-18 05:05:35 UTC</time></p>
<br>
<p class="description">@moeamaya Realized there's already an object called `Design`. Whoops! Renamed mine to `DesignModel`. I didn't want to wade in any deeper, but should/could those be combined? It looked like `Design` had some controller stuff in it though, not sure.
Also what do you think of the promisifying of the initialization? This way it doesn't have to wait for all the images to load (I think?) and we can ensure that google.maps and the windMap are ready. Happy to discuss though.</p>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-18 17:12:12 UTC</time>
<p>I already merged this yesterday, but yea let's keep the DesignApp and DesignModel separate for now. There's quite a bit of functionality in it and it's like you said it's acting as both a controller and the parent for all the rest of the app.</p>
</section>
</article>
<article>
<h2>Contact: Fix comments, use environment's google api key.</h2>
<h4>#<span class="issue_number">172</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-17 19:46:37 UTC</time></p>
<p>Closed: <time class="closed">2017-07-17 19:46:49 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Design model and test spreadsheet</h2>
<h4>#<span class="issue_number">171</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-17 19:12:12 UTC</time></p>
<p>Closed: <time class="closed">2017-07-17 19:12:51 UTC</time></p>
<br>
<p class="description">The need arose to be able to test the cost spreadsheet against a wide array of possible designs. This required creating sets of internally consistent design parameters, using all of the functions in design-option and design-option-system. Problem there was that in the current version each update to parameters is inextricably tied to an update in display and price. Felt like we needed a separate model, so, here it is. I ran into surprisingly few bugs, which I think is a sign that this was a good move.
NOTE: This pull request requires a change to the cost spreadsheet!</p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-17 19:36:27 UTC</time>
<p>@moeamaya Take a look at this when you get a chance. Thanks!</p>
</section>
</article>
<article>
<h2>Add new users to Mailchimp ImageWall group.</h2>
<h4>#<span class="issue_number">170</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-10 19:23:49 UTC</time></p>
<p>Closed: <time class="closed">2017-07-10 19:24:01 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Add getPrice back to grid size change.</h2>
<h4>#<span class="issue_number">169</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-07 16:20:27 UTC</time></p>
<p>Closed: <time class="closed">2017-07-07 16:23:35 UTC</time></p>
<br>
<p class="description">@markjanzer @moeamaya The price doesn't update when grid size is changed, and I think it's due to the removal of `getPrice()` from `design-option` in 71e8dbf. These changes look to me like they fix the issue without introducing duplicate calls, but you've both spent more time with getPrice() than I have. Thoughts? In general, is there a rule you'd like to follow for where calls to getPrice() are made? Always directly in the event handler? Or if multiple event handlers call the same function, like `setGridSize()`, should it be there once?</p>
</article>
<article>
<h2>Keys and stripe</h2>
<h4>#<span class="issue_number">168</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-06 21:23:51 UTC</time></p>
<p>Closed: <time class="closed">2017-07-06 21:24:04 UTC</time></p>
<br>
<p class="description"></p>
</article>
<article>
<h2>Improve depth slider behavior:</h2>
<h4>#<span class="issue_number">167</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-06 21:20:54 UTC</time></p>
<p>Closed: <time class="closed">2017-07-10 23:23:02 UTC</time></p>
<br>
<p class="description">- Reorganize system options javascript
- Restrict interactivity of depth slider by application.
- Set depth slider range by application.</p>
</article>
<article>
<h2>Keys and stripe</h2>
<h4>#<span class="issue_number">166</span> - <span class="user">twastvedt</user></h4>
<p>Created: <time class="created">2017-07-06 21:19:44 UTC</time></p>
<p>Closed: <time class="closed">2017-07-06 21:21:16 UTC</time></p>
<br>
<p class="description"></p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-06 21:21:35 UTC</time>
<p>Accidentally added depth slider commit to this</p>
</section>
</article>
<article>
<h2>Add context toggle</h2>
<h4>#<span class="issue_number">165</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-07-06 00:07:50 UTC</time></p>
<p>Closed: <time class="closed">2017-07-10 23:18:41 UTC</time></p>
<br>
<p class="description">Should close #131</p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-07 16:27:37 UTC</time>
<p>@moeamaya Are these ready to merge? I thought from our conversation that you were going to merge these. No particular rush, I just want to make sure you aren't waiting on me.</p>
</section>
</article>
<article>
<h2>Add 3d scale figure to the scene</h2>
<h4>#<span class="issue_number">164</span> - <span class="user">moeamaya</user></h4>
<p>Created: <time class="created">2017-07-05 21:26:14 UTC</time></p>
<p>Closed: <time class="closed">2017-07-11 00:13:57 UTC</time></p>
<br>
<p class="description">Should close #76 </p>
<section class="comment">
<h4 class="user">twastvedt</h4>
<time class="created">2017-07-10 17:59:32 UTC</time>
<p>@moeamaya
</p>
</section>
<section class="comment">
<h4 class="user">moeamaya</h4>
<time class="created">2017-07-10 21:01:02 UTC</time>
<p>Ah good catch. I forget that I'm scaling form the center.</p>
</section>
</article>
<article>