Contributions for Project Verdun
Date Type From Resource Type Qty URL Description Process Deliverables
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 , 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 Updated Trello board
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 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; 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 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/", 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/", 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/", 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/", 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"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 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
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 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/ 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 14, 2018 Time Contribution davidh Work - Programming for product 2.18 HR Starting work on issue: Create Order dies #10 Just to see what happens, getting rid of the offending import. No issues calling up the page itself. Re-enabling tests. Tests fail because of all the hard-coded primary keys in the tests, though I do recall them resisting attempts to force it into accepting more reasonable forms of data because of oddly incoherent primary key assignments. The validation test also throws missing the exchange_type key from the QueryDict. Form class has exchange_type. HTML has exchange_type. Using pdb trace, discovered that exchange_type is trimmed from the dictionary by WebTest's submit(), which calls fields = self.submit_fields(). submit_fields() trims off any field with a None value. This doesn't seem to bother the actual form served to the UI. Breaking for lunch Create new classical NRP for the Vedun project
May 14, 2018 Time Contribution davidh Work - Documenting 2.55 HR Filling in the NRP-CAS dictionary file with some skeleton explanation and a table of terms as they are now. Create new classical NRP for the Vedun project
May 11, 2018 Time Contribution davidh Work - Programming for product 2.32 HR Trying Bob's solution for issue: AttributeError at /accounting/exchanges/ #20 Also making sure there isn't a type issue at the root of the problem, since the lack of union() method on a QuerySet doesn't really make sense. Set objects don't have a distinct() method, so if I do that, I will have to get rid of those calls. Did that, also had to convert a related object manager to a QuerySet with all() Investigating issue: accounting/resource/ can't display units of quantity or use #19 view function in sets the context's resource variable to an EconomicResource instance EconomicResource class has resource_type as an instance of EconomicResourceType, meaning it probably gets string'd somewhere in the template? Oops. The unit_of_quantity is a getter in EconomicResource, not the resource type Still not showing up. Made the field obligatory and used formatted_quantity to let python figure out what unit to use. The unit_of_use not appearing may be due to a lack of value_per_unit_of_use, rather than unit_of_use. Yeah, that should work once those are assigned. Now it works. The unit's symbol property needed to be erased to get the unit positioned right. Inventory page has same aesthetic issues as resource types did. Fixing that. Works and looks good. Create new classical NRP for the Vedun project
May 6, 2018 Time Contribution Tibi Work - Meeting 0.50 HR Meeting with David Lametti at his office in Verdnu, to discuss physical space for Verdun project.
May 4, 2018 Time Contribution davidh Work - Programming for product 5.62 HR Starting work on issue: Inventory/Resource Types page is ugly. #16 Added some mostly logical divs, floated and hanged image, set "view recipe" on its own line right of the image. Oops, left a div unclosed. Explicitly set the div containing the image to block vertically and fit its content height (the CSS for this property may not be supported everywhere, should look into it) A similar effect can be achieved by setting height: 100%, maybe try that first since it's universally available. None of that worked. Using clearfix. Worked. Attempting to support the test project and test exchange functionality by adding exchanges of the new exchange types. Noted additional problem for issue: Forms using are ugly #12 Couldn't use the purchase exchange type to add a juicer, so I went to add it via Inventory > Resource Types > Juicer > Create Resource Found issue: Formsets rendered as .as_ul without labels are ugly #17 Put labels on ul and li elements to prevent the ugliness. Might want to grep something here, perhaps .as_ul, since the pattern was used for that initially. Grep output on templates/valueaccounting: _form_dialog.html (fixed already) log_past_work.html log_simple.html process_oriented_logging.html resource.html resource_type.html (fixed already) workbook.html Fixed all of those by adding <b>Plural description</b> to main ul and description #{{forloop.counter}} to inner li Also prepared the |s filter to handle strings marked for translation. While checking out resource.html, found issue: TemplateSyntaxError at /accounting/resource/ #18 Obviously another nested variable syntax problem Oops! that should have a field argument too. Somehow the resource.resource_type is getting cast to string, preventing the template from getting to its unit_of_use, unit_of_quantity, etc. Will address separately since the syntax error itself is fixed.. Created issue: accounting/resource/ can't display units of quantity or use #19 Checking out process oriented logging, started a new process to access. Found that it was impossible to access the #createResourceForm I modified because its only a[data-toggle] is commented out. It's embedded in another modal, so that wasn't going to work anyway. Another modal is conditionally rendered to the modal, but the button (add output) is rendered regardless. Fixed that by making the button have the same condition as the form. Log unplanned output (the other modal that was modified) didn't appear to use the new list styles I added to site_base; turns out it overloads the extra_head block, so I added block.super. Didn't take, so I commented out the li CSS in the document. That works. Typo on log_past_work, fixed. log_simple seems to be inaccessible from any view, skipping. Facets are resisting outputting all of their fields using .as_ul, will fix tomorrow. Create new classical NRP for the Vedun project
May 4, 2018 Time Contribution Tibi Work - Office 0.50 HR Sent info to Cecille, Ville de Montreal / Development Economique, after our meeting she wanted some info. Updated the Updates doc for the Verdun project.
May 3, 2018 Time Contribution davidh Work - Programming for product 4.65 HR Attempting to add exchange types myself, marking everything I create with TEST so that it's visible from the admin interface. Copying the exchanges, process patterns, transfer types from the existing Sensorica NRP. Exchange Type: Donation TEST Process Pattern: Donation process pattern TEST Transfer Type: Donation No clear answer for which Use Cases the patterns should have, leaving that blank for now; unfortunately I think this is sort of vital to some algorithms, so at some point this is still going to be a show stopper for tests. Transfer types on the other hand seem to be complete. Exchange Type: Expense TEST Transfer Types: Expense, Pay Expense Process Patterns: Expense TEST, Pay Expense TEST Exchange Type: Material Contribution TEST Transfer Type: Resource Contribution Exchange Type: Purchase TEST Transfer Type: Receipt, Additional Expenses, Pay Purchase Process Patterns: Purchase Receipt TEST, Purchase Addl Expense TEST, Purchase Pay Purchase TEST Exchange Type: 3D Printer Use TEST Transfer Types: Paid Service Package, Maintenance Fee Process Patterns: 3D Printer Maint Fee TEST, 3D Printer Svc Pkg TEST Exchange Type: Maintenance Fee TEST (does not appear to be used in the Sensorica NRP) Transfer Types: Use of Sensorica Resources, Pay Maintenance Process Patterns: Maint Fee Resource Use TEST, Maint Fee Pay TEST Exchange Type: FabLab Membership TEST (also appears unused) Transfer Types: Monthly FabLab Membership, Membership Fee Process Patterns: FabLab Membership TEST, FabLab Membership Fee TEST Exchange Type: Fiscal Sponsorship TEST Transfer Types: Deliverable, Sponsorship Process Patterns: Fiscal Sponsorship (not created, but modified to include For Sale: For Sale facet value) Exchange Type: Loan Repayment TEST (appears unused) Transfer Type: Pay Back Loan Process Pattern: Loan Repayment TEST Exchange Type: Rent TEST (appears unused) Transfer Types: Rent, Rent Payment Process Pattern: Rent TEST Exchange Type: Sale TEST Transfer Types: Shipment, Cash Receipt Exchange Type: Tech Shop Access TEST (appears unused) Transfer Types: Use of Lab, Tech Shop Payment, No Cleanup Fee Agent Association Type: TechShop User TEST Process Pattern: Tech Shop Access TEST Returning to UI & HTML tests. Found Issue: AttributeError at /accounting/exchanges/ #14 That's really silly behavior; empty query sets can't union. Luckily, they do bool as False. so I can fix with conditional expressions. Made a dry throw-proof union(). Now I get 'Exchange' object has no attribute 'own_events_list' at line 10279:x.event_list = union(x.transfer_event_list, x.own_events_list).distinct() should be x.own_event_list (no s) Found issue: Various cosmetic issues with accounting/change-exchange-type/ #15 The lack of spaces at those points is clearly due to using |add instead of |sp or manual spaces. Easy fix. The Proxy issue requires that the translation string is unicode()ed. The purely cosmetic issues are fixed, but the DB still doesn't connect the pattern to the exchange type. Will try adding it manually in the app, observe the effect through the admin interface, and learn something. Alternatively, the patterns in the DB will not change at all, but changes will be shown in the UI, and I will learn nothing. Aha. There is a class TransferTypeFacetValue in the models.... but it's totally inaccessible from the admin interface. Well, at least I can get rid of the Process patterns I made. aaaand add the "patterns" (transfer type facet values) back through the app. Created issue: Inventory/Resource Types page is ugly. #16 Will fix tomorrow. Create new classical NRP for the Vedun project
May 3, 2018 Time Contribution davidh Work - Programming for product 0.00 HR Create new classical NRP for the Vedun project