Once the bug is set RESOLVED, the bug is completely removed from my bugs. I wanted to keep a track of the number of issues resolved. How could I see it and get back all in one list?
Go to any "Search" page and make sure "Status" is set to "all" (or whatever). The default is usually "open" and that's why you're not seeing your closed bugs. If you open the "Advanced" tab of the search, you can drill down very precisely.
Your search criterion "Resolution" may have value "---" which is a value, not a wildcard. Complicating things, usually web browsers don't give you an obvious way to deselect the only selected value in a multiselect list such as this one.
Fix:
You can deselect the "---" value of the "Resolution" search field by holding down the Ctrl key and clicking on the "---" value.
That works in Internet Explorer, Firefox, and Chrome. If I recall correctly it works in Safari as well, or maybe that uses Command or Option modifier keys instead of Ctrl.
Of course this fix doesn't apply to mobile devices. Long press? I don't know.
Alternatively there's nothing wrong doing like in Excrubulent's answer: work around this difficulty by selecting all of the values in the Resolution list.
Actually my BzDeck app [1] had the same issue. It was showing My Bugs in the main Inbox thread pane, the core feature of the app, but bugs would suddenly disappear when it's been RESOLVED. My solution was adding a selector to display all/open/closed bugs [2].
There are two different scenarios:
People usually would like to focus on open bugs (bug if they are involved in too many bugs, the My Bugs list could be very long), however,
People sometimes continue discussing on closed bugs (on BMO, RESOLVED FIXED for Firefox bugs only means the patch has been committed to the source code repository)
Given that, a better, possible solution would be:
Distinguish clearly open bugs from closed bugs like GitHub issues (this applies to the all UI on Bugzilla; GitHub issues use green and red icons for this purpose [3])
Provide a selector like BzDeck to switch between all/open/closed bugs, showing all bugs by default
Load/show the bug list lazily to improve performance
As mentioned, My Bugs was the core of BzDeck as well as another experimental Bugzilla client called Buggy [4], and I believe Bugzilla should also implement the same thread sidebar so people can go though their bugs much faster.
https://bugzilla.mozilla.org/show_bug.cgi?id=1380026
Searching under the advanced tab for resolved bugs doesn't work in some versions of Bugzilla. See this bug on the Bugzilla Bugzillaception:
https://bugzilla.mozilla.org/show_bug.cgi?id=663377
That bug says resolved for 4.2.1, but I'm using 4.2.5 and it isn't fixed for me, so apparently your mileage may vary. I've mentioned this issue on that bug.
A potential workaround for now is to search for various resolution values (FIXED, WONTFIX, WORKSFORME, etc). Anything with those values set should have a status of resolved or verified.
When you are using the quick search, ALL is your friend, this word has to be typed at the very beginning of the input line and overrides the status criterion (as can be found in: Examples of Simple Queries).
BTW: Bugzilla's quick search can also be added to the Browser's search engines and combined with a keyword also within its address bar. (confirmed for Firefox and Edge)
I warmly recommend the 5½-minute summary in Bugzilla Quicksearch will BLOW YOUR MIND on YouTube.
Related
First off I would like to say your product is amazing! Has made the job of inheriting an old DNN instance a much more intuitive experience.
Apologies if this is really simple thing I'm missing but I'm at a dead end after scouring the docs and internet.
I'm using Evoq content and up until the start of the week the publishing workflow had been working fine rich text WISIWIG fields but it seems something has changed. Now when publishing changes any apps that are embedded in rich content fields display the demo item when not logged in.
I've recreated the issue on a smaller scale to illustrate the problem:
When logged in it looks as expected - on the left is a button that's placed directly onto the page, on the right is a button inside a rich text field:
logged in
And when logged out:
logged out
As you can see the button that is embedded as a rich text field is displaying the demo item.
I've gone through all of the content items and ensured that they are set to publish and not draft or hide and ensured the page is set to published in DNN.
Aldo I've double checked how the fields are setup but as this was working previously, I'm doubtful that this is the issue but for clarity here is how the fields look in the model:
Rich text field model
And it's rendered to the page using:
#{
var renderSvc = GetService<IRenderService>();
}
#renderSvc.All(Content, field: "BodyContentBlocks", merge: Content.Body)
I've been scouring the docs and internet for hints of what might be going on but the closest I could find was this thread on github but it doesn't seem to be quite the same issue.
Any help would be massively apricated as this issue has cropped up just before moving to our production server (as they always do!) after working as expected for a couple of months. Let me know if you need any more info from me and thanks for your time.
Evoq has a page-workflow feature which is technically undocumented. 2sxc got a sponsor a few years ago who paid for the implementation but there are limitations to it. Some background:
Some data in 2sxc can be clearly assigned to a module or page - such as content added directly
Other data cannot be assigned to a page - such as a blog post
Because of this, the logic is to first determine if something is partOfPage and if yes - and workflow is active - then it will be set to be a draft. This way the end users don't see it.
Upon page-publish, everything that is partOfPage will be published, so the draft will become the live data.
I assume the detection of this was never implemented for inner content - I think inner-content was actually developed later. Because of this, I assume the toolbars for the inner-content-item tell the UI it's part of the page (resulting in draft), but the publish cycle doesn't know about this, since it's internally a sub-entity (which is just like a tag on a blog - not part of a page).
This is difficult to fix. A proper fix would require 2sxc to be modified to make sure that inner-content is never seen as part-of-page, OR that it's taken into account when publishing. Both of these options would probably take ca. 3 days of dev on 2sxc side and would only happen if we have a sponsor.
A workaround is to disable the Evoq-integration so the page publishing wouldn't happen. I believe there is a feature for this - and AFAIK you don't even have to become a Patron (which I highly recommend to support our thousands of hours of work):
Or you could manually try to publish it, but that will be difficult. Note that most of us will be on x-mas vacation so we won't be answering questions till mid Jan.
Summary of options
Avoid inner content for now
Disable Evoq Page Workflow in 2sxc
Manually publish the items (very difficult, needs super-user permissions because it's an unusual thing to publish)
Get some budget ca. 3 days to sponsor the feature https://2sxc.org/contact but wait till end of January
A mix of short-term solution + sponsoring
Sorry for the delay on this, I've been waiting for a decision. I'm going to close the question as we have been able to work around the issue for now with the help of your last comment. Avoiding inner content is working well enough for our use case. Thanks for your time and help and for making an amazing product!
When developing my react app the app becomes unusably slow with the devtools open in chrome. Works fast and fine with them closed or in incognito mode. I have tried disabling all extensions and had the same problem. This seems to have started happening recently when I updated chrome (now on Version 80.0.3987.132).
I am not really sure where to start debugging this issue but it has become very frustrating to develop on my app.
Any advice or help debugging would be appreciated.
TL;DR: Go to the Sources tab and delete all breakpoints for the site.
I had a similar problem. My site was very slow to load, but only in specific circumstances:
Dev-tools were open.
Tab was in a normal window. (not incognito mode)
Profiling was not enabled.
If (and only if) all three of those conditions were met, the site would load unbearably slowly (15+ seconds; normally ~3s), plus have performance issues for certain operations on the site (like changing which subpanel was open). It was very strange.
Like you, I tried disabling all of my extensions, yet the problem persisted.
Attempt 1: I tried clearing all of the site's cookies and local-storage, using the info/lock dropdown at the left of the address-bar. Suprisingly, that seems to have fixed it! (edit: this was not the root problem; see below for that)
So the problem must be that my site was storing too much data in local storage or something, such that dev-tools was choking on it (but only in specific cases, for some reason). This also matches with the issue resolving in incognito mode: incognito mode uses a "clear slate" for site cookies/local-storage.
Anyway, it's an odd one, but the cookies/local-storage clearing seems to have worked for my case. (If the issue comes up again, and the solution above doesn't fix it, I'll try to remember to mention it.)
Update: Oddly, having the profiler on still speeds things up even after the fix (ie. those three conditions being met still slows down page loading and actions, just much less than before the fix). So apparently the fix merely "reduces the intensity" of the problem rather than fully fixing it; like, by resetting local-storage, it lessens the size of that data, which somehow is a variable affecting the core problem (not yet identified).
Attempt 2: I believe I have found the root problem and solution: I removed all breakpoints for the site, and the slowdown was solved completely. So the problem seems to be that I had lots of unneeded breakpoints set at various places in my website code (some enabled, some disabled). Some of these must have been placed in/near "hotspots" that were getting called frequently. By having the dev-tools open, the Javascript engine must have had to start performing some processing related to the breakpoints, slowing things down.
My guess is that the problem would also be fixed by disabling the "JavaScript source maps" settings (as that's the only thing I can think would cause so much slowdown), but I haven't confirmed this.
This has most probably something to do with this commit, titled "Stop sending profile data when recording is off".
They already know there is an issue with the Developer Tools slowing down and they tried to prevent it by preventing profiling data to be sent via the bridge to the frontend, when not recording.
As reported, it seems the issue is not happening anymore, on the latest version. However, the cause is still unknown.
Try uninstalling the Developer Tools extension, clearing browser cache and then installing it again.
You should probably try using a version other than the one you're using, Version 80.0.3987.132. The app you are trying to develop might not be suitable to the version you are using. Delete the extension you are using, clear and remove every trace of browser cache and then re-download the extension, like what Daniele Molinari said. It might help. If it doesn't let me know. I'll try a different approach.
I've been trying to work with Codename One for years, but I still find errors that prevent me from releasing my apps.
Locally I can fix errors by I overshadowing erroneous classes. This works but for some reason it doesn't work when I send my apps to the build server.
If I could overshadow faulty classes would be good in many ways:
I'd better get on with my work
I could check how my corrections work on the different platforms
I could contribute to the further development of Codename One
I suffer much from not being able to publish my apps because I see no way how I can fix basic problems.
I love iPhones and do not like the Mac. Therefore I do not own a Mac and prefer to work with Linux and use the Codename One build server.
What are the reasons for not supporting overloading classes like com.codename1.ui.Component? Can You see that it would be beneficial?
This isn't the first time people asked for that but we won't deliver it. Doing this creates huge problems:
Developers don't file issues or submit fixes instead they make local fixes
Developers break things due to complex behaviors then try to get support and blame us for the issues
We have a process of submitting patches to Codename One, patches are always accepted quickly when they are valid. If something needs fixing that's what you need to do. If you need a hack then submit a patch that defines the extension point that you need. That's why we are open source...
In the past this might have been painful as you would need to wait until we updated the servers, but since changes go in every week in recent revisions this is no longer an issue. Don't think of it as "contributing", think of it as free code reviews where the entire community pulls together to improve your work...
I'm having the well documented problem of StageVideo killing Stage3d, or at least overlaying a black layer above the Stage3D on mobile.
I've attempted some of the various solutions offered around the forums, including moving the viewport off screen, assigning the netstream to a normal flash video before closing. None of these seem to help.
Adobe's answer seems to be that is is working as it's designed and it's not a bug, specifically:
When using Stage3D, the user must call Context3D.present() to make the stage layer update. There is no independant update of the Stage, Context3D.present() drives the update of both the Stage and the Stage3D layers. This is necessary to achieve high performance. Workarounds include making all the Stage3D invisible and delaying the Context3D creation until you are going to start using it.”
From https://bugbase.adobe.com/index.cfm?event=bug&id=3186454
Away3d seems to use Stage3D managers in the core, and there is a present() function, which contains the important Context3D.present().
I'm having trouble trying to initiate this call, but can't see a way to access it.
Does anyone know if this is likely to work, and what the call might be?
I got around it by using a native extension https://github.com/freshplanet/ANE-Video/
While exporting a Solution from CRM, I dont get the prompt to save the exported solution.
I cleared Cookies and tried,
Upgraded to IE 9 also and tried,
I made sure that the Popup is not blocked, but these things didn't help.
This is the case with few other colleagues of mine also.\
Thanks
I usually get a popup right at the bottom of the window. Its not instant however, Crm has to generate the solution file, so if its particulary large it can take a minute or two. I would suggest clicking export, finish the dialog and then waiting 5 minutes to see if anything happens (it needs a loading icon really).
If that doesnt work, try the same again with a small solution (one entity).
I know it is too late but I am adding the solution here if someone faces the issue again.
The issue was due to URLScan. It was solved by removing URLScan from ISAPI filters for CRM web site.