I am wandering if anybody can shed some light on this problem for me.
Are Sugar tasks ever meant to show up in the Scheduling bar at the bottom of the editeview when you are Scheduling a meeting or call?
There seems to be an intermittent bug in Sugar CE that sometimes shows tasks in the scheduling bar. This was highlighted to me when one of the users of the CRM kept complaining that the scheduling bar was always showing fully booked e.g. purple then when he scheduled a meeting it was showing double booked. I looked into this and found that he had created tasks that were a month long and that’s why the scheduling bar was showing fully booked. But his other shorter Tasks were not showing up in the scheduling bar at all. So to me it was unclear whether this is normal behavior or not.
I then tried it myself on a clean install of Sugar CE and the same thing was happening intermittently. I also noticed that when you delete the Task it does not remove it from the scheduling bar. I had to go into the database and remove the record and remove the cache folder before it would vanish.
Ever seen this behaviour?
I looked into the code and found where the scheduling bar is being created. It seems to be done entirely in JavaScript and the source file is jssource/src_files/modules/Meetings/jsclass_scheduler.js and within that the SugarWidgetScheduleRow.prototype.add_freebusy_nodes function seems to be what is determining if its booked or not. This JS function is getting its data from the GLOBAL_REGISTRY['freebusy_adjusted'] but where is that populated about?
In order to debug this I need to know how the scheduling bar in Meetings and Calls is pulling in its data?
Surly this must be a bug?
Cheers
Ok one of my colleges helped me solve this problem. There is a bug in modules/vCals/vCal.php line 129
get_activities($user_bean->id,
array("show_calls" => true),
$start_date_time,
$end_date_time,
'freebusy');
This param : array("show_calls" => true), should be to just false.
get_activities($user_bean->id,
false,
$start_date_time,
$end_date_time,
'freebusy');
You may then have to go into the vcals database table and delete the db entry for an affected user, then when the user goes into meetings or calls and saves a meeting the db cache will be refreshed and the task will no longer show up on the scheduling bar.
Related
I have a really bizarre one here...I have developed and deployed to my back end system a launchpad application that currently works OK. Part of this application is a report that, based on certain filters, returns a table and a chart (see snapshot below).
After finishing deployment next step is configuring the app so it runs from the launchpad within the SAP portal. Not familiar with the portal, another colleague undertook the task, application is now running from within the portal as well. With one exception - the chart above is not visible (see 2nd snapshot below).
Noticing the "No Data" message and NO exception in the Chrome debugger, thought as a good idea to debug the OData methods in the back end. To my big surprise, found out that while filters pass to the method just fine both for table and chart (two different entities but almost identical and accepting exactly the same parameters) when running outside portal, when running from within (the portal) parameters "get lost" on their way to the chart entity - no parameters for the chart method. See snapshots below and pay attention to the IT_FILTER_SELECT_OPTIONS at the bottom right.
Outside portal (parameter table filled)
Within Portal (parameter table empty)
Furthermore, the filter table passed to both OData tables is common, you can see the code underneath - just two lines: one for table and one for chart binding.
Closing with a clarification. Mentioned above that there are no errors in the debugger when calling the back end methods. There are actually a couple of them but they take place during the initialization of the app and do not seem to affect anything else in the app, which aside a set of reports has a lot of data operations (dialogs, tables etc), everything else works fine. These errors can be seen below.
Does this situation ring any bells to anyone?
Thanks in advance
Issue solved, it was a deployment issue...
During 10.8 times I created macro in Keyboard Maestro for adding web pages to Reminders list to read them later.
In Mountain Lion and Maverics it worked fine but in Yosemite something wrong is going on resulting very slow executions.
Previously execution time was about 1-2 seconds now its over 40 seconds or even one minute!
Apple team provided me with wrong solution ordered to "code sign" my script, but there is no "file" to codesign and applescripts can be executed in command line. So IMO they messed up something in osascript and still couldn't fix it till 10.10.4. But I need someone to confirm or to advice me how to debug problem, because I cannot find in system console log lines relevant to problem.
UPDATE:
On El Capitan 10.11.1 problem still persist.
Macro
Could anyone test and confirm this? I provided link to macro.
It is bind currently to F1 - change as you like. Before execution create "2Read" list in Reminders on OSX.
I've tried it and it's done in about 1-2 seconds on my machine. So I do not experience the same problem as you.
I'm running OS X 10.10.4 on a late 2013 MBP Retina.
Maybe your "2Read" list is too long?
Another tip:
I used to have a problem with long lists in Applescript, too. Sometimes it would take minutes to run through a list, but after using some if these tips the time for the lists was brought back to only seconds.
From your pastebin link (yeah, I did warn you it'd look like mince):
Keyboard Maestro event logs
(1) KM sends an 'open' event ('aevt/odoc') to Growl, telling it to open a temp file (presumably to make Growl display a message)
(2) Bartender sends a 'get scripting terminology' event ('ascr/gdut') to KM
(3) Bartender sends a 'BTDR/Load' event to KM, which looks like Bt telling KM to load a plugin named "BartenderHelperNinetyOne.bbundle"
(4) KM send a 'KeyC/KeyB' event to something (it doesn't give the name of the process, only its Process Serial Number, which is the classic MacOS equivalent to a Unix process ID). Probably easiest just to ask the KM devs about that one.
(5,6,7) KM then sends three 'application died' events ('aevt/obit') to Keyboard Maestro Engine (I'm guessing that's a faceless helper app that runs constantly in the background), informing it that three osascript processes (PSNs 312312, 315315, 316316) have terminated. This doesn't necessarily mean that osascript has crashed as those events contain an error number ('errn') parameter with value 0, and command-line processes normally return error code 0 to indicate they've completed successfully. It's quite likely these are normal internal notifications sent between KM and KME to indicate when a task is completed. The first of those osascript processes (PSN 312312) is related to the Reminders activity below; the other two I'm guessing are you running other AppleScript macros and probably not relevant here.
Reminders event logs
(1,2,3) The 'osascript' process with PSN 312312 sends Reminders a 'make' ('core/crel') event and two 'set' ('core/setd') events, which is obviously your AppleScript being run.
(4) The Dock sends it a 'reopen' ('aevt/rapp') event, which is probably just you clicking on Reminders' dock icon to bring it to the front.
The main problem, of course, is that without timestamps I can't tell you where your 40-second delay is occurring. You'd really need to do it again, this time manually noting the time at which each message is logged. And if you see a single 40-second delay somewhere in the middle, it should easy enough to determine which events it's occurring inbetween, which should start to point towards a cause. At which point, you're probably best contacting the KM vendor to discuss it with them.
HTH
I'm hopefully missing something obvious here...
I have just kicked off developing a new Access 2010 application. Something personal and hopefully simple.
The first thing I need to do is read a bunch of files off of the hard drive. I parse the contents adding the information to a table if it doesn't already exist.
Code works fine, that's not the issue. As it can take a while I've added a simple progress dialog using a standard form but in dialog/popup mode. As the For Each loop of the FSO.Folder.Files object is progressed I send some information to a couple of text boxes and issue a Me.Repaint (have also tried DoCmd.RepaintObject acForm, "FormName").
The issue is that I can get anywhere from 5% to 35% of the process complete before the repaints stop responding. The form only repaints when it gets to 100%.
The process uses limited recursion - if there is a subfolder - it calls itself to process that subfolder, but the folder structure is fairly linear so not many of those.
There are nothing bound to the form. All table updates happen in code and via RecordSets.
Any ideas why Access stops responding?
Cheers,
Roy
Add DoEvents after Repaint. That will cause Access to yield to Windows, which will can then handle its pending tasks ... such as updating the display in this case.
Actually, if your code updates text boxes, I don't see why you need to Repaint the form in order to display the changes. Try something like this instead ...
Me.MyTextBox = "hello"
DoEvents
Preface:
If you don't care about the preface, skip down to the section marked "Question."
Hi,
Recently my company has upgraded to the latest version of WatiN for its test automation framework. We upgraded to avoid a problem where interacting with a select list would cause an ACCSES DENIED error. This error seems to be a product of the fact that our web application reloads the page it is on (which sits in a frame which sits in a frameset) with new fields after certain select lists options are selected. It could also be that our framework, which wraps around WatiN, often does actions on the same SelectList after the page refresh (I'm still looking into this, I'm new to the framework).
The new version of WatiN does solve the ACCESS DENIED error, but also seems to stop select lists from firing the action that causes the page to reload w/ its new options. In fact, if you use WatiN to make the selection, the select list won't work correctly, even if manually interacted with, until the page has been forced to refresh.
Question:
When selecting an option in a SelectList using the newest WatiN code, the event that causes our web app's page to reload with new fields/values does not execute. What are some possibilities that could cause this?
The term i've seen used most often to describe the refreshing that occurs when our select lists are used is "double post-back".
Many thanks,
Chad
This is part of the new WatiN code. The new code, if you look into the SelectList class has comments about the fact that it has been changed so that these events don't exactly fire. It says something along the lines of "you may need to use a key press or other event to get a select list to fire its events".
This didn't work for me so we went back to the old code.
One thing that has helped is wrapping calls to the select list w/ a try/catch(System.UnauthorizedAccess e) and then doing a .Refresh on the select list object. Afterwards, the call can be retried and it seems to work pretty well.
I am making a simple time sheet for which people can register times
worked on a bug real quickly.
But the hours added to the bugs_activity table are not noticed
anywhere.
here is a simple made up line
Bugzilla::Bug::LogActivityEntry(1, 'work_time', 0, 66, 1, '2010-01-12 14:44:44');
Pretty much, add 66 hours to bug 1, work time. This executes like I would expect but does nothing else. I also need to send e-mails and add comments. I can't find anything on using Bug.pm or LogActivityEntry API.
Is this a huge undertaking or what ?
What I would need is what else is required of me, this is just a batch job that runs when the user presses submit and this info can be on many bugs. I know how to get the bugs, user and such, just not registering the hours, I need the final item. This can be almost as rough as the example above.
I am using Bugzilla 3.4.4
Time worked is kept in longdescs table - the table with comments. Hours worked in fact is a property of a comment. (I also think it's weird.)
bugs_activity table that you're modifying is the table for the history of changes, I bet you can see the result of your call on the "bug activity" page. But it does not change the state of the bug.
Hope this helps.
Igor