I added some logging to SectionsUtil.load_sections to see what it was getting from the config, and other variables. Looks like the problem is that the section name (entry point name) is "followers" so that needs to be used.
On 9/16/18 2:37 PM, Deshani Geethika wrote: > Hi Dave, > > To move up the activity section in dashboard and profile I've modified the > development.ini file. For the user profile, the section order was there but > commented, so that I've uncommented the line. For the dashboard section > order, I've added a similar line, but it doesn't work. (activity section is > not moving up) Do you have any idea about this? > I have committed my changes to the repo. ( > https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/1955539543430eb71e56a995307135d258247b74/ > ) > > Regards! > > On Thu, Aug 30, 2018 at 1:27 AM Dave Brondsema <d...@brondsema.net> wrote: > >> Hi! >> >> I've merged that merge request, it looks good. I think the title text is >> ok. >> The layout of the logo runs into the main gray content though. It'd be >> nice if >> it had a bit of space like it does on the user profile page, for example. >> I see >> on the user profile page there is an empty <h2 class="project_summary"> >> that >> helps push it down. >> >> Another thing that could be polished is the placement of the Activity box >> in the >> right column. On both the dashboard and the profile pages it is part way >> down >> the column, and I think it'd be better at the top of the column. That >> might be >> fixable by CSS rules, but also by the ordering of the widgets. If it is >> the >> first widget then when it floats to the right its ok at the top of the >> column. >> So either by code, or .ini config file you could make it first in the >> profile_sections.order and personal_dashboard_sections.order >> >> On 8/29/18 6:44 AM, Deshani Geethika wrote: >>> Hi Dave, >>> >>> Sorry for the delays. I've done some fixes on dashboard styles and added >> a >>> merge request ( >>> https://forge-allura.apache.org/p/allura/git/merge-requests/271/) >>> Please review it and let me know if any improvements required. >>> >>> Also, for the dashboard title, currently it is shown as *username / >>> Dashboard *(eg: Admin1 / Dashboard). Is it alright? Otherwise, do you >> have >>> a better idea for the dashboard title? >>> >>> Regards! >>> >>> On Fri, Jul 27, 2018 at 9:17 PM Deshani Geethika < >> deshanigeeth...@gmail.com> >>> wrote: >>> >>>> Thanks a lot. Will try these and let you know >>>> >>>> On Fri, Jul 27, 2018 at 8:52 PM Dave Brondsema <d...@brondsema.net> >> wrote: >>>> >>>>> Sure, here's some thoughts: >>>>> >>>>> Inheriting from TestGitRepo means it gets all the test_* functions, so >>>>> when I >>>>> ran nosetests, it ran a lot of TestGitRepo.test_* tests too, which we >>>>> don't want >>>>> to happen. So I'd remove that inheritance. You probably will have to >>>>> duplicate >>>>> the setup_with_tools() function in this file then. >>>>> >>>>> Actually, inheriting from _TestCase in >>>>> forgegit/tests/functional/test_controllers.py might be a good option. >> It >>>>> has >>>>> some setup functions you can use (so you don't have to duplicate >>>>> setup_with_tools) and it doesn't have any test_* functions. >>>>> >>>>> The super() call is supposed to use its own name, like >>>>> super(TestMergeRequestsSection, self).setUp() Not sure if that makes a >>>>> difference here or not. >>>>> >>>>> merge_request() is a function but you don't have parenthesis on `mr= >>>>> self.merge_request` so that function isn't running. >>>>> >>>>> I realized what happened earlier when I didn't see the "Tickets" >> section >>>>> in the >>>>> HTML output of the tickets test! When I was trying this test now, I >> got a >>>>> similar situation where the "Merge Requests" section isn't in the HTML >>>>> output at >>>>> all either. So I looked in the 'test.log' file (where logging goes to >>>>> during >>>>> tests) and saw "Error rendering section MergeRequestsSection: ..." with >>>>> error >>>>> details. So these sections trap errors and log them, instead of >> letting >>>>> the >>>>> whole page error. So looking at the test.log output can help see those >>>>> errors >>>>> when they happen. >>>>> >>>>> You may need to run ThreadLocalODMSession.flush_all() after creating >> the >>>>> merge >>>>> request object. That is a common test pattern we have when tests >> create >>>>> something and then need to view it. (Mainly needed in tests, since >>>>> regular web >>>>> pages will flush at the end of each request). >>>>> >>>>> Hope that helps, let me know how far you get, and I can look at it some >>>>> more if >>>>> needed :) >>>>> >>>>> On 7/27/18 9:11 AM, Deshani Geethika wrote: >>>>>> Hi Dave, >>>>>> >>>>>> I have started to write a test case for Merge Requests Section. For >>>>> that I >>>>>> have followed ForgeGit tests but it doesn't work for me. I was trying >> to >>>>>> create a merge request and see whether it appears in dashboard. >>>>>> >>>>>> I've pushed the code into my fork >>>>>> < >>>>> >> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/96613c7854d116130455a343c814e853c2b5d812/ >>>>>> . >>>>>> Can you kindly take a look at that? Also, please let me know any >>>>> debugging >>>>>> process can be done for methods called internally when creating a >> merge >>>>>> request. >>>>>> >>>>>> Regards! >>>>>> >>>>>> On Tue, Jul 17, 2018 at 11:19 PM Deshani Geethika < >>>>> deshanigeeth...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Dave, >>>>>>> >>>>>>> Thank you for sharing these valuable information. I have added a >> merge >>>>>>> request < >>>>> https://forge-allura.apache.org/p/allura/git/merge-requests/269/>. >>>>>>> Please review it and let me know any further improvements. >>>>>>> >>>>>>> Regards! >>>>>>> >>>>>>> On Mon, Jul 16, 2018 at 9:54 PM Dave Brondsema <d...@brondsema.net> >>>>> wrote: >>>>>>> >>>>>>>> On 7/16/18 9:49 AM, Deshani Geethika wrote: >>>>>>>>> Hi Dave, >>>>>>>>> >>>>>>>>> I have tried with adding above lines, but still doesn't work. Can >> you >>>>>>>> take >>>>>>>>> a look at my implementation >>>>>>>>> < >>>>>>>> >>>>> >> https://forge-allura.apache.org/u/deshani/allura-personal-dashboard/ci/a7ddd0c0bbcfe89cb14fc5214deff168cbb20477/ >>>>>>>>> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>> >>>>>>>> Here's some debugging process I did, you can try it too: >>>>>>>> >>>>>>>> Tests use the MockSOLR class instead of a real solr instance (so >> that >>>>> you >>>>>>>> don't >>>>>>>> need solr to run tests). I knew that, so I started by going to >>>>>>>> MockSOLR.search() and putting in some print statements to debug it. >>>>> At >>>>>>>> the >>>>>>>> beginning of search() I added: >>>>>>>> >>>>>>>> print q >>>>>>>> print fq >>>>>>>> >>>>>>>> And inside the "for obj in self.db.values():" loop, I added "print >>>>> obj" >>>>>>>> >>>>>>>> My idea was to see what query is happening and what the stored >> objects >>>>>>>> are, and >>>>>>>> see what's not working. I ran just the single test with `nosetests >>>>>>>> >>>>>>>> >>>>> >> allura.tests.functional.test_personal_dashboard:TestTicketsSection.test_tickets_section` >>>>>>>> I noticed there was a 'project_id_s' in the search query, and there >>>>>>>> shouldn't >>>>>>>> be. But after a bit of trial & error to see what was happening, I >>>>>>>> realized that >>>>>>>> was coming from a "update_bin_count" background task, and that >> wasn't >>>>>>>> related to >>>>>>>> the test really. >>>>>>>> >>>>>>>> So I commented-out the tasks M.MonQTask.run_ready() to avoid all the >>>>>>>> background >>>>>>>> tasks for now and did it again, and there wasn't any of my print >>>>>>>> statements >>>>>>>> occurring. So the dashboard ticket search wasn't even happening it >>>>> seems. >>>>>>>> >>>>>>>> Then I printed the "response.html" variable to look at the whole >>>>>>>> dashboard page >>>>>>>> and I didn't see the Tickets section in it at all. So indeed, that >>>>>>>> section >>>>>>>> isn't included in this test at all for some reason. >>>>>>>> >>>>>>>> Hopefully those are some helpful examples for this particular >>>>> situation >>>>>>>> and also >>>>>>>> ideas for how to debug high level (like "is it even running?") and >> low >>>>>>>> level (to >>>>>>>> see where things might be not working). >>>>>>>> >>>>>>>> Next step of course is to figure out why in this test the dashboard >>>>>>>> section >>>>>>>> isn't even running. I'll let you work on that. My general strategy >>>>> is >>>>>>>> to put >>>>>>>> debugging in various places to confirm if things are running with >> the >>>>>>>> right >>>>>>>> values, or where they aren't, and narrow down to the spot where it >>>>> goes >>>>>>>> wrong. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dave Brondsema : d...@brondsema.net >>>>>>>> http://www.brondsema.net : personal >>>>>>>> http://www.splike.com : programming >>>>>>>> <>< >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Deshani Geethika* >>>>>>> Undergraduate at Department of Computer Science and Engineering >>>>>>> Faculty of Engineering - University of Moratuwa Sri Lanka >>>>>>> LinkedIn <https://www.linkedin.com/in/deshanigeethika/> | GitHub >>>>>>> <https://github.com/deshanigtk> | Mobile - +94776383034 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Brondsema : d...@brondsema.net >>>>> http://www.brondsema.net : personal >>>>> http://www.splike.com : programming >>>>> <>< >>>>> >>>> >>>> >>>> -- >>>> *Deshani Geethika* >>>> Undergraduate at Department of Computer Science and Engineering >>>> Faculty of Engineering - University of Moratuwa Sri Lanka >>>> LinkedIn <https://www.linkedin.com/in/deshanigeethika/> | GitHub >>>> <https://github.com/deshanigtk> | Mobile - +94776383034 >>>> >>>> >>> >> >> >> >> -- >> Dave Brondsema : d...@brondsema.net >> http://www.brondsema.net : personal >> http://www.splike.com : programming >> <>< >> > > -- Dave Brondsema : d...@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><
