Contributions for Project Verdun
 
Date Type From Resource Type Qty URL Description Process Deliverables
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 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 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 views.py 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 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 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 chair_tag.py 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 chair_tag.py |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 3, 2018 Time Contribution davidh Work - Programming for product 0.00 HR Create new classical NRP for the Vedun 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 views.py 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 1, 2018 Time Contribution davidh Work - Programming for product 1.98 HR Start fixing issue: Graph on home page broken #13 Most likely due to the Home Page Layout in the DB (the canvas element in here is not even in the template) The layout doesn't have the canvas either. It's generated by the library static/jquery.maphilight.min.js Since it's minified, it will be difficult to figure out what's going on. Looking for the source version. Interesting. The image itself is 691x457, but the canvas in the Verdun homepage sizes the canvas as 830x447. Something to ctrl-F in the source code maybe? Nope, the dimensions were set manually in the HomePageLayout object. Punched in the correct dimensions, should work immediately. Resuming work on issue: Forms using chair_tag.py are ugly #12 At least one case is screwed up by an oversized description, trimming that as a kluge. Increased line height for containing elements, protected li elements inside forms from styles that disable their bullets. Create new classical NRP for the Vedun project
April 30, 2018 Time Contribution davidh Work - Programming for product 0.00 HR Create new classical NRP for the Vedun project
April 30, 2018 Time Contribution davidh Work - Programming for product 4.85 HR Found issue: TemplateDoesNotExist at Create Exchange #9 Examining exchange_logging.html Looks like the {% include %} tags need the full path. Fixed that. Now encountering: TemplateSyntaxError at /accounting/exchange/1/0/ Could not parse the remainder: ',' from 'xfer.change_commitments_form,' On the same page. Found some syntax errors on the included form, _commit_form.html, not sure if that could interfere. Also found a comma in the arguments to {% include %}, which is likely the source of the problem. Also improved some other spots in _add_xfer_form.html Now I get: TemplateSyntaxError at /accounting/exchange/1/0/ Could not parse the remainder: ',' from 'slot.add_commit_form,' Obviously this is another syntax error of the same nature Works now, but I may want to revisit to check out all the case-specific renderings Found issue: Create Order dies #10 Clear solution here. I can fix this particular problem easily and quickly, bur we need to decide whether we are implementing customer orders or not. According to previous communications with Bob, the tests never passed and the functionality was never used, which is why there is an import there. If we want to have customer orders, I need to fix this AND the issues revealed by the tests. If not, I need to disable the button and not worry about it. Will defer here. Found issue: Production Planning looks like something is missing #11 The view function, process_selections(), has a variable slots, which should give the context a list of resource types. The function is fairly complicated. Could be related to lack of EventTypes? Probably not, unless the project is supposed to be associated somehow with the event types and it isn't. on lines 9535 to 9538: slots = selected_pattern.event_types() slot.resource_types = selected_pattern.get_resource_types(slot) Since the slots appear to be present but unfilled, it's most likely an issue of process_pattern.get_resource_types(event_type) not finding any resource types. Checking out models.py This is the function that is filtering resource types based on the resource type facet values, which it gets from self.facets_for_event_type(event_type) Looks like the resource types associated with the dummy project need more facet values, as they don't match these filters. Tried that, still coming up empty. Could be due to incomplete list of facet values or poorly assigned facet values to patterns or resource types; will ask Tiberius to review them. Found another instance of issue: UnboundLocalError when creating exchange without exchange type #3 Will give this similar treatment (alert at template level) and fix at the forms.py level as well. Went ahead and added required=True to all of the WhateverNavForm classes. Moved the preventDefault() definition used by all of my events that need to do so to its own template, _prevent_default.html (event.preventDefault() is deprecated, event.defaultPrevented is not universally supported) Added click events at all 3 locations. Verified that all 3 cases work as expected for the case of no selection. However, in the case of exactly one exchange type present, the :selected selector doesn't pick up the very much selected option. Will have to add a line to select the first option by default. Fixed. Fixed up create_exchange.html with type aliases. Found a really ugly form via create_exchange > Save Changes > Log a new Transfer Event. Could be due to the {% field_as_div %} tag from chair_tag.py; trying that out, since it would be more convenient to edit in one place. Turns out it's due to the label element; replacing that. Still doesn't look right; starting issue: Forms using chair_tag.py are ugly #12 and picking it up tomorrow. Create new classical NRP for the Vedun project
April 26, 2018 Time Contribution davidh Work - Programming for product 4.77 HR Found bug: UnboundLocalError when creating exchange without exchange type #3 Fixing. Added an alert and preventDefault() when the exchange type is not selected. Still needs to be tested to make sure that it works when an exchange type IS selected, but we currently have no defined exchange types for this agent. Found bug: Layout of agent page has "add to map" on same line as "Photo" #4 Fixing that too. Added div elements as chair_tag would have if the a elements could have been put in by that tag. For testing, created an order for lemonade, "I am thirsty" Found bug: TemplateSyntaxError at /accounting/process #5 Looks like there's a few missing symbols there. Added a }, fixed. Edi-table on accounting/contributionhistory/ is off. The Edit button is missing. The Deliverables column is empty. The unit "Hours" has no space in front of it. Created issue: The edi-table on contribution history is a mess #6 Shouldn't have replaced the textual Edit button with an <i>. Made it an a.btn.btn-large with "Edit". Added a leading space to the data-suffix in the quantity column. Removed the data- properties from the Deliverables column; this column was never editable, so the json override was abandoned. If the column is still empty, it's probably due to the DB having an empty field due to my naive data entry rather than an actual bug. Since the quantity column doesn't start out managed by the edi-table JS, had to add a space in the initial output too. Seems that the datepickers aren't working; probably because I commented out the datepicker() calls. Adding them back. Now it appears that the Save button is, once again, trying to submit the form and navigate away. How is this still happening? Looks like the form still has its enctype attribute, which should have been stripped. Used the wrong span class to install the editor in the first place, so who knows what will happen now. Checking out process_oriented_logging, it looks like an image is missing. Evidently our static files have not made it into the static app on the server. Looking into that. Messed with settings, that was necessary but didn't fix it. Fixed by uploading proper files to the repository (there was a directory mixup the first time, my bad) and collecting statics on the server. Found issue: TemplateSyntaxError at /accounting/create-resource-type-list/ #7 Fixing by removing nested comment. Trying to replace the inner comments with {# #} syntax so that the inner comment can be preserved, otherwise if the block is ever un-commented, the inner comment block will return to haunt us. Worked, but now the form.as_ul looks ugly. Let's see if it's better with |as_bootstrap. Unfortunately I may need to sweep this across all the templates, but it was somewhat uncommon. Looks nicer if the checkbox is simply labeled by the resource type name, rather than a read-only textbox. Trying it out. Hmm the label showed "None" below the checkbox itself. Will need to use .value() instead of .data and either move the input into the label or move the label text into the input widget (probably easier to do with JS than the django template). Checked out incoming exchanges page; for some reason the exchange type variable is not being replaced. Created issue: Typename variable not replaced in incoming exchanges #8 Found that the template still features the variable nested in a {% trans %}. Changed to use |tr. Create new classical NRP for the Vedun project
April 25, 2018 Time Contribution davidh Work - Programming for product 2.12 HR Continuing fix of #1: Non Production Logging form Fixed several issues: Forgot to add the edit column. Added. Moved the time total right by one cell to put it under the hours total. Used parseFloat instead of idiomatic casts for durations expressed as hours/minutes widget. Coerce the values() iterator to an array before getting the first element in EdiTable.table(). Remove enctype from all modal edi-table forms, as the async saves don't need to navigate either. Problem: the durations are apparently still not calculating properly. Also, it's still wanting to submit the form and navigate. Added a save() call on the table after loading to calculate the total; at load, it calculates correctly. After the pull that fixed that, the navigation problem appears solved, too. Create new classical NRP for the Vedun project
April 24, 2018 Time Contribution France Work - Writing 2.00 HR French translation and proof reading Writing the MESI memo Document - Documentation: Memo pour l'economie collaborative
April 24, 2018 Time Contribution Tibi Work - Writing 8.00 HR Wrote and coordinated the memo. Writing the MESI memo Document - Documentation: Memo pour l'economie collaborative
April 20, 2018 Time Contribution Winluck Work - Writing 4.00 HR Proofread and edited MESI memo. Wrote additional linking text to blend paragraphs together for better content flow. Writing the MESI memo Document - Documentation: Memo pour l'economie collaborative
April 20, 2018 Time Contribution davidh Work - Programming for product 0.50 HR Fixing #1. Caused by implicit cast failure while altering table contents. Create new classical NRP for the Vedun project