Community
Participate
Working Groups
http://mylar.eclipse.org/monitor/upload/UsageAnalysisServlet currently shows the 10 most used views over all the usage data that has been submitted to mylar.eclipse.org. This will be changed so that it shows the top 10 org.eclipse.* views because this doesn't feel like an appropriate place to report usage of proprietary tools (non-representative sample, etc.). Any comments?
I have this fix ready, but I can't create a patch until the original code is committed (Bug 170540), or at least I don't know how to create a patch when the original files aren't in cvs yet.
Patch on Bug 170540 applied, so hopefull that unblocks you. Here is what I think would be ideal for the first public version of this (hopefully 2.0M2 since that's what we said at EclipseCon, but not the end of the world if we slip): 1) Top 10 org.eclipse.* views and editors 2) Top 10 org.eclipse.* commands 3) Top 10 org.eclipse.mylar.* commands The latter would be very useful to us. Let me know if you need a pointer to the code the code that grabs command usage.
Maybe it is better to show views/commands with usage above certain threshold. I.e. used more then N times by at least M users (say N=5 and M=3).
There are lots of commands that have ID like "null$item.label.<some text>". Some of those came from Eclipse's menu contributions, i.e. "null$item.label.Duplicate" is from Launch configuration dialog. But there also items with user sensitive info like launch configuration names and items from Mylar's Task List's task history drop down (for those <some text> will be the task name).
(In reply to comment #4) > There are lots of commands that have ID like "null$item.label.<some text>". *Very* good that you spotted this. For the time being I have removed monitoring monitoring of all commands that come from menu items with no ID, because we currently have no way of detecting whether they contain private (e.g. dynamically generated) contents or not. This unfortunately means that we will no longer know when users invoke commands from context menus that do not come from contributions (i.e. have no ID). We should verify how this impacts our ability to report on interaction with the Task List. Eugene: it would be great if you could try this again with a new build, and a dev build should go up within the next 3 hours. Note that you will need to delete your monitor file.
(In reply to comment #5) > *Very* good that you spotted this. For the time being I have removed monitoring > monitoring of all commands that come from menu items with no ID, because we > currently have no way of detecting whether they contain private (e.g. > dynamically generated) contents or not. This unfortunately means that we will > no longer know when users invoke commands from context menus that do not come > from contributions (i.e. have no ID). We should verify how this impacts our > ability to report on interaction with the Task List. Hmm. Can't you use class name if there is no id? That would at least give some clue who contributed such command. > Eugene: it would be great if you could try this again with a new build, and a > dev build should go up within the next 3 hours. Note that you will need to > delete your monitor file. Will do.
(In reply to comment #5) > For the time being I have removed monitoring monitoring of all commands BTW, you made a typo in the bug number in the code you commented out. I wanted to try hyperlink detector and it brought me somewhere else...
Created attachment 62308 [details] improvements to MenuCommandMonitor Mik, apparently toolbar tooltips can also cointain some local info. So, I've commented out tooltip capturing and added id recovery using target or action class names. Please take a look
Created attachment 62309 [details] mylar/context/zip
Very good idea, patch applied. The reason we didn't do it this way before is that Leah Findlater created a map from the UI labels to the corresponding actions. So that map will now have to be updated for class names instead. The only change I had to make is to remove the tags (e.g. "actionId") that you prevised with. This is because what we generate is actually an interaction event handle, and those have to correspond to the most concise form identifying an element in the UI. We can make that table label provider format them better. Currently the only weird case should be that if an ID uses a class name it will look like it's a class name, but in this case the corresponding action should still be easy for the plug-in developer to determine.
Meghan: do you think you can do this today? We should not be reporting submission without it because we could inadvertently report some private actions. Also, I wonder if we should have a mode where we only submit usage of "org.*" IDs, as to avoid someone working in a large company accidentally uploading private data from a tool they were developing internally. We have to add this facility to the editor itself, and then make a copy of the file without only "org.*" events before uploading. Then the Servlet does not need to do the processing.
(In reply to comment #11) > Also, I wonder if we should have a mode where we only submit usage of > "org.*" IDs, as to avoid someone working in a large company accidentally > uploading private data from a tool they were developing internally. We have to > add this facility to the editor itself, and then make a copy of the file > without only "org.*" events before uploading. Mik, you could scramble all ids. Then build a map for publically known types on the server. Another option to allow user to mark events that are ok to send and save allowed event types locally for next submission.
Meghan: do you have an eta for doing this according to comment#11? Eugene's comment#12 is a good suggestion but considerably more work, and we can't encourage use of this until we have comment#11 done due to the privacy issues.
Meghan: when doing this please also delete the old data that has been uploaded.
I think this will be done today (Mar 10)
Created attachment 63785 [details] patch that strips the file of any events that aren't from org.eclipse.* packages This patch creates a new file that only contains the org.eclipse.* events from the monitor-log.xml file and submits the new file to eclipse.org. A message has been added to the Usage Summary editor and to the Usage Submission Wizard stating this.
Created attachment 63786 [details] mylar/context/zip
Excellent. Patch applied, with minor UI changes made (wizard now called "UI Usage Report", feature now called "Mylar Usage Reporting").
I still think it would be better to obfuscate everything and let user to choose what keys should be send back. Then even if user won't mark org.eclipse.* as public we could maintain own dictionary for those public keys.
I agree that such a feature would be useful. But it would be considerably more work, and with this bug we needed to implement the simplest and quickest way to be defensive in preventing users from accidentally uploading sensitive data. I created bug 182639 for your suggestion.
