Contributions for Project Verdun
 
Date Type From Resource Type Qty URL Description Process Deliverables
Aug. 28, 2018 Time Contribution Tibi Work - Meeting 2.00 HR Met with M. Dugas at the Church in Verdun, to decide for a space for Eco2FEst and Verdun.
Aug. 17, 2018 Time Contribution Tibi Work - Meeting 0.75 HR Spoke to Remis from DEC over the phone, gave updates and sent info by email.
Aug. 15, 2018 Time Contribution Tibi Work - Facilitation and coordination 2.00 HR Phone conversations and email exchanges with Alicia (David), MESI, DEC, and some people in charge for the church (potential location for eco2fest and Verdun project) in Verdun. Updated the Updates doc for the Verdun project
Aug. 13, 2018 Time Contribution Tibi Work - Meeting 2.00 HR Meeting with Sylvain Lefebvre (prof) et Jeremy Diaz (PhD student) at UQAM, they want to contribute to the Verdun project. Meeting organized by Jeremy.
Aug. 7, 2018 Time Contribution Tibi Work - Meeting 1.50 HR Open Meeting with MESI at their Montreal office for funding the project, Jeremy represented OuiShare.
Aug. 6, 2018 Todo Tibi Work - Analysis and Strategy 1.50 HR worked on the presentation with Jeremy https://docs.google.com/presentation/d/1lLOmPJEQKkTC2bN5swHT0YvzuuJ6D3lNdGtzMdMR1fM/edit#slide=id.g3e775edc7f_0_18
July 18, 2018 Time Contribution Tibi Work - Facilitation and coordination 0.02 HR test Create new classical NRP for the Vedun project
July 16, 2018 Time Contribution Tibi Work - Meeting 3.00 HR Meeting for Eco2Fest, which is now presented jointly with the Verdun project. Meeting organized by Ouishare / Agathe, with participants from the federal government, provincial government, Desjardins, Desjardins lab, Caisse d'economie solidaire, chantier d'economie sociale, etc.
July 12, 2018 Time Contribution Tibi Work - Analysis and Strategy 2.00 HR worked with Agathe from Ouishare on eco2fest, which is not presented jointly with the Verdun project. discussions for understanding where eco2fest is going, how to present it, communications with potential partners, ...
July 9, 2018 Time Contribution Tibi Work - Business building 0.25 HR Called Philippe Tisseurs from http://www.destinationtravail.org/ , as David suggested, to talk about collaboration and perhaps sharing space. Sent email to Sensorica and NOICE mailing lists to inform about meetings last week (improved the last entries in the Updates document).
July 5, 2018 Time Contribution Tibi Work - Meeting 1.83 HR Open Had a meeting with 2 guys from Europe to structure collaboration on Governance, in relation to Verdun and next gen NRP. Jonathan (lawyer from Sensorica + EVA) and Dardan (Eva) were part of the meeting. This was the first meeting. More to come...
June 14, 2018 Time Contribution Tibi Work - Meeting 0.75 HR Phone call with David, discussing about funding, where to take this next.
June 4, 2018 Time Contribution Tibi Work - Administration 0.50 HR PME Montreal send us possible locations for the first lab. I documented, sent signals to PierreLaurent and Eimen about it.
May 22, 2018 Time Contribution davidh Work - Programming for product 1.62 HR Checking out the create order UI. Looks pretty good; might want to make the description row-fluid to get it to sit to the right on monitors and go under the thumbnail on mobile. Also, I thought I had the controls to the right of the thumbnail, which would make the description on the bottom make more sense. Looking into that. The template overrides the extra_head block without adding the block.super, so I stuck that in. Probably should consider this first if there are any other silly looking things in the HTML. Perfect. Now for the finale, testing the value equations UI. Made a roughly fair value equation that rewards squeezing work. I'm now double-billing for coding and squeezing lemons (for the lemonade stand test project). Have to make a juicer to complete the process, can't find the control to adjust the quantity. So I went to add an unplanned output to the process as a quick hack, but I found that the dialog has a lot of goofy text that doesn't really belong anywhere. Investigating. Went ahead and added block.super since it was missing. The type variable wasn't declared, which really should have caused it to crash, but didn't. Should work now. The resource type dropdown list options are not quite right; may be due to the missing label fields. Should be easier to fix at the tag level, otherwise will need to sweep all the templates. Alternatively, it might be due to a missing process pattern or a lack of output resource types (though I don't see how they would get messed up in this way). It actually looks as if it's the string-ification of resource types adding a list of facet values, since two forms that have nothing at all else in common are having the same problem. Er, it looks like the facets were included intentionally. Anyway, the labels are fixed. Looks like everything works to me. Calling it a day on this one, switching over to brainstorming on the next-gen NRP standardization minimal requirements. Create new classical NRP for the Vedun project
May 22, 2018 Time Contribution Tibi Work - Administration 0.50 HR Open Added some new items to the planning doc for the Verdun project, while reading proposals.
May 22, 2018 Time Contribution Tibi Work - Administration 0.50 HR Open Updated Trello board
May 21, 2018 Time Contribution Tibi Work - Administration 0.75 HR Open Propagated Emian's urban analysis document, for chosing the place for the 5 CELLs, sent it to PME Montreal, Ville de Montreal (Development economique) and David.
May 21, 2018 Time Contribution davidh Work - Programming for product 1.42 HR Investigating the 2 remaining create_order test fails. In both cases, the offending commitment list is from changeable.producing_commitments(), which should have two elements, but instead has none. Indeed, the list of commitments makes no mention of changeable. Will have to examine the test system to make sure there really should be changeables involved, as I only see the order for parent, child, or grandchild, and my impression was that those are related only to each other. Sure enough, there are no solid links between those 2 systems that I can find, so I don't know how this was supposed to happen. Changed them to order the workflow recipe RTs, and everything now works. Confetti please. And now the server is handing out 500 internal server errors. Will have to check out log files. Yeah that one is going to be webfaction's problem, unfortunately. Create new classical NRP for the Vedun project
May 20, 2018 Time Contribution davidh Work - Programming for product 3.80 HR Messing with the test_orders.py; the field names have changed, the primary keys have changed, and the tests relied on all of that. Luckily I did figure out what the old primary keys were. Er, can't import django.forms.BaseFormSet? I'm looking at the source right now..... Can't import it. Interesting. aha, it's django.forms.formsets.BaseFormSet If this doesn't work I need to create an OrderItem model class to bind to the form class; they could be confused that they aren't really associated with real live commitments in an exact way. Needs a max_items to survive, eh? Added all the static fields I could see the Django code doing to its own formsets. Looks like the #510 fix test passes, but I've spoken too soon about that before. Drat. The RT IDs are still not appearing. Just for fun, try getting rid of the boundness to Commitment, which I don't like at all anyway. Maybe it will validate anyway. That worked. I need to stop trusting the Django documentation. Came up with a hackish, inelegant fix that works for the IDs, plugged default values of zero in literally every place conceivable for the quantities, since they went unfilled in the initializers. Seems to make the forms' is_valid work, finally. Now, to deal with the 2 remaining failing tests (yeah we're down two!) Create new classical NRP for the Vedun project
May 18, 2018 Time Contribution davidh Work - Programming for product 5.22 HR About to get a smoking gun in relation to VerdunNRP #10 and valnet #510. It's the order item form. It can't find its fields right. Or maybe my list comprehension sucked. Both of these things are true. Probably going to need to rewrite the form class as an order form with an order item form formset. Otherwise I'm just not equipped to figure out what is confusing the form bindings. The plan is like this. I wanted to mess with the order form anyway, get rid of the table, make it look more like the inventory list, make things a little more sensible with regard to the fact that it isn't bound to a commitment object anyway, it doesn't use half of its fields now, etc. etc. I can clean it up so that it uses an independent template. Done with that template, _order_item_rt.html Now for the parent template, create_order.html Done (it has some TODOs for filtering, but I doubt it will come up) Made some changes to forms.OrderItemForm, made forms.OrderItemFormSet to manage them Modified the view to accommodate. Won't have time to test it, so I leave it down for today. Create new classical NRP for the Vedun project
May 17, 2018 Time Contribution davidh Work - Programming for product 0.92 HR Apparently there was a problem saving the notes from my last debug session, so the last line should have read: The fail-early scenario (implemented in views.create_order) was the one that played out, so the form classes are a good place to start. E.g. which of the form validators flunked, or was it the additional stipulation that there needed to be at least one non-zero order item? In all 3 cases, the receiver was being problematic; it doesn't have a default even when the list is populated. Added defaults & disambiguated problems with error types and messages. That problem is fixed. New issue: commit referenced before assignment, which I believe was the original issue in the valnet version. Have an appointment, will fix when I get back. Create new classical NRP for the Vedun project
May 17, 2018 Time Contribution davidh Work - Programming for product 6.55 HR Returning to issue of commit being unassigned when referenced in views.create_order. Also making said function a little more logical about its choice of default users, and reviewing best practices on raising ValidationErrors I feel a little dumber about this, but it appears we can circumvent this problem entirely by getting the date from the order creation date (or just datetime.date.today). Using the method that creates these commitments in the first place, there is no way for these commitments to have any other date. However, it's still probably going to fail all the tests, as there is no good reason for commit to be None unless there are no commitments in the DB for the order, unless they failed to be generated. But the tests and the extra diagnostic functions should catch this when the the view function doesn't throw in these locations. Er, now it's having the receiver issue too... how did that go away temporarily? Maybe it wants the ids? Nah, that was pretty dumb too. Fixed. Diagnostic shows association flaw in all 3 cases; elaborating that trap. Fix for #510 shows 1 commitment existing after a zero quantity order. Just to make sure, adding assertion that all commitments are really gone under fix #510. All 3 of the other tests are showing flaws at the first call, which in all cases is using resource_type.producing_commitments(), so let's start there. Things that are not the problem with the 3 association issues: - No commitments generated at all (there is 1) - Parent RT not associated with (the 1) commitment - Commitments not associated with event types - Parent RT not associated with producing process - Commitment associated with RT not associated with order (the 1 is) I might have just cracked it, but it will be a pain to really fix. However, if I am right, it should address all 4 problems. The OrderItemForms are not binding to their own controls. That explains why it wouldn't catch the quantity issue, but would stop the items from ever being added to the order. Testing just that hypothesis for now before I make huge changes to fix it. Yeah that has gotta be it. Will start patching it up tomorrow. Create new classical NRP for the Vedun project
May 16, 2018 Time Contribution davidh Work - Programming for product 3.83 HR Continuing debugging of customer orders and tests thereof. Adding various prints to narrow down where exactly the resource types go awry. Typical Output: recipe created parent RT parent : 87 recipe created child RT child : 88 recipe created grandchild RT grandchild : 89 order_test.setUp sees parent RT parent : 87 order_test.setUp sees child RT child : 88 order_test.setUp sees grandchild RT grandchild : 89 view got RT another changeable : 91; made fields {'quantity': <django.forms.fields.DecimalField object at 0x4623710>, 'description': <django.forms.fields.CharField object at 0x46239d0>, 'resource_type_id': <django.forms.fields.CharField object at 0x4623210>, 'url': <django.forms.fields.URLField object at 0x4623150>} view got RT changeable : 90; made fields {'quantity': <django.forms.fields.DecimalField object at 0x4623e10>, 'description': <django.forms.fields.CharField object at 0x46230d0>, 'resource_type_id': <django.forms.fields.CharField object at 0x46231d0>, 'url': <django.forms.fields.URLField object at 0x4623610>} view got RT parent : 87; made fields {'quantity': <django.forms.fields.DecimalField object at 0x4623b90>, 'description': <django.forms.fields.CharField object at 0x4623ed0>, 'resource_type_id': <django.forms.fields.CharField object at 0x4623f50>, 'url': <django.forms.fields.URLField object at 0x4628110>} Uh huh... two problems are very apparent. First, two unrelated RTs (changeable & another changeable) have made it into the form, Second, the child & grandchild RTs did not make it into the form. My impression was that there were no RTs at all in the DB at this point, but evidently tests.objects_for_testing.WorkFlowRecipe makes changeable and another changeable. Ultimately this won't be a problem if I can get the right RTs to show up too. View filters RTs by: PatternUseCase.objects.get(use_case__identifer="cust_order").pattern.all_resource_types() or equivalent. Or, not quite equivalent; they use objects.filter(...)[0]... If there are multiple objects returned that will surely not work. Nope, wasn't that. Aha. The child and grandchild RTs were lacking resource type facet values that make them appear in the customer order process type. That did the trick. Prepare confetti. Just need to chop off these response.follow() calls. Put back the confetti. Tests output: ====================================================================== ERROR: test_create_order (valuenetwork.valueaccounting.tests.test_orders.OrderTest) Test create_order view ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/valnet/webapps/verdunnrp/VerdunNRP/valuenetwork/valueaccounting/tests/test_orders.py", line 181, in test_create_order process = self.parent.producing_commitments()[0].process File "/home/valnet/Envs/verdun/lib/python2.7/site-packages/django/db/models/query.py", line 207, in __getitem__ return list(qs)[0] IndexError: list index out of range ====================================================================== FAIL: test_create_workflow_order (valuenetwork.valueaccounting.tests.test_orders.OrderTest) Test create_order for a workflow item ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/valnet/webapps/verdunnrp/VerdunNRP/valuenetwork/valueaccounting/tests/test_orders.py", line 243, in test_create_workflow_order self.assertEqual(count, 2) AssertionError: 0 != 2 ====================================================================== FAIL: test_two_workflow_item_order (valuenetwork.valueaccounting.tests.test_orders.OrderTest) Test create_order for two workflow items ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/valnet/webapps/verdunnrp/VerdunNRP/valuenetwork/valueaccounting/tests/test_orders.py", line 283, in test_two_workflow_item_order self.assertEqual(count, 2) AssertionError: 0 != 2 Alright obviously in the first case, self.parent.producing_commitments() is empty. That method filters commitments with RT==self whose event_type.relationship=="out" or whose event_type.name=="Receipt". Event types are set up in fixtures, but they do generate one in the test setUp(). Looks like all 3 fails are actually due to this empty query set, but only the first crashes. So it could be either failure to produce these commitments in views.create_order, or failure of commitments to associate to the right event types, processes, process types, patterns, etc etc. Put together several fault-finding mechanisms to determine whether the test, the association setup, or the actual code is broken. Discovered that the fail-early scenario is playing out; will need to see what I did to validation tomorrow. Create new classical NRP for the Vedun project
May 15, 2018 Time Contribution davidh Work - Programming for product 3.60 HR Setting up some of the entities used by the orders tests as fixtures rather than creating them programmatically during the test in an attempt to remedy the issue of mismatched primary keys Putting that on hold, it's going to take a lot of work to adapt that into the test code without going back to primary keys. Trying another mapping of the hard-coded PKs based on the original creation order (not that I can figure out why there would be 3 RTs produced right in a row with PKs 6, 9, and 10) Now for exchange_type getting erased. Sure enough, neither fixtures nor the objects_for_testing.py create any ExchangeType objects, so the form would be unable to choose a default the way it does when served. Adding sale as an ExchangeType fixture and TransferType fixtures in hacks/fixtures.js and fixtures/verdun.json. Also adding a few bits to fixtures.js to let me add a few extra properties to instances so that the resulting objects have the bells and whistles like a description. Adding the new functionality to the documentation for hacks/fixtures.js to hacks/readme.md Implementing use of the exchange type in the tests. I can tell this is probably going to crash down the line anyway, as there are a bunch of array indexes, but this should get it past the immediate crashes if the new mapping of RT keys is correct. Now they crash because ExchangeType model has no all... uh huh... oops. It should be objects. Now it needs to have the id/pk of the exchange type. Needs a get() too Looks like it will need to have the form's receiver filled out too. Maybe it will take the user they've already set up? It will not, but there are two options in that select box. Create new classical NRP for the Vedun project
May 15, 2018 Time Contribution Tibi Work - Meeting 1.00 HR Open Phonecall with Eiman, who created the urban study for chosing the place of the 5 CELLs in Verdun. We spoke about the initial draft of her study and improvements to make