Bugzilla – Full Text Bug Listing
| Summary: | Git Log broken on individual files | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Simon Kaegi <simon_kaegi> |
| Component: | Client | Assignee: | libing wang <libingw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ken_walker, libingw, mamacdon |
| Version: | 0.4 | Flags: | ken_walker:
review+
mamacdon: review+ |
| Target Milestone: | 0.4 RC3 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 372158 | ||
|
Description
Simon Kaegi
fixed. (I was worried I had caused this so investigated...) The problem goes like this: - searchClient added a new feature to use the file service name in the searchbox when searching root - searchClient assumes that it gets passed the file service in the glue code - git log never did - git log folder scopes the search to the folder so no worries - git log file scopes to the root and tries to find the file service name - BOOM just another example of our need of an "open every page on every possible metadata" type testing. Another thing we could consider is doing assertions for our dependencies in the constructors so that if someone doesn't pass you a service you expected, we find out right away vs. the first time we touch it in some obscure feature. reopening. I fixed the git log case by ensuring a file service was provided to the search client. After thinking about it some, I think we should also safeguard the searchclient by checking for a null file service in that new code. Just in case there's another subtle case we wouldn't find until it's too late. Perhaps print a warning to the console so that we'd know to fix it later. (In reply to comment #2) > Just in > case there's another subtle case we wouldn't find until it's too late. Perhaps > print a warning to the console so that we'd know to fix it later. I believe that bug 372158 is a symptom of this same problem. "Find File Named" is failing on pages that were not passing a file client into the search client. We either need to search on all creators of searchClient and make sure they are passing a file client in, or we need to check for a null file client in line 28 of searchClient.js I am searching for all the searchClient creation in all glue code and will fix them. (In reply to comment #3) > We either need to search on all creators of searchClient and make sure they are > passing a file client in, or we need to check for a null file client in line 28 > of searchClient.js Maybe we should do both. Doesn't seem that searchClient will work correctly without a fileClient, and if it doesn't get one, it's better to fail loudly sooner than quietly later. *** Bug 372158 has been marked as a duplicate of this bug. *** There are 3 places missing the fileClient : git-commit.js, user-list.js and user-profile.js. I've also safe guarded the fileClient in the searchClient.js. I've fixed them and tested. John helped me on testing user-list.js as he has the admin password to see user list on my self-hosting site. I've also test other pages just to make sure open resource dialog and search works. I've pushed changes in to origin/Bug371015. Code looks good. I tested every page except for user-list. Have validated the change before and after including user-list page as admin. As a project lead I +1 this for RC3 Pushed the fix. Thanks Mark and Ken reviewing it and Susan pointing this out. |