|
[
Permlink
| « Hide
]
Stephen Marquard added a comment - 18-Aug-2008 13:42
Aaron, by "all polls a user has access to", do you mean all polls across all sites in which the user is a member, or do you mean polls that are currently votable within a specific site?
Not quite. I mean this:
1) All the polls a user can participate in (with option to limit by site) 2) All the polls a user can control (with option to limit by site) Hi Aaron,
Please can you add some more details about use cases. Are these for synoptic widgets? Maybe the complex requirements should be a separate JIRA from the basic entity support through EB. I'm concerned about how to efficiently answer some of the cross-site questions, given that the current site and authz APIs are not really optimal for this. The results might also have to take into account which sites the user has hidden, as generally when people belong to sites but has hidden them (through My Workspace / Preferences), then they don't want to see synoptic info from those sites. I did not realize that polls depended so heavily on sakai to determine what polls a user has access to. I had assumed it was more like eval where we can find all the sites a user has the "be.evaluated" permission in very rapidly and then cross reference that with our own internal record of which siteIds are associated. If this is not the case then you are certainly correct, it would be very inefficient to have to fetch all the sites and then cross check them against the internal polls data storage.
Part of the use case here is to make the poll browseable (part of entity picker) so it could be selected from a listing. We could limit this by the current site but it seems unfortunate to have to restrict users to only seeing the polls for the site they happen to currently be in. This is a similar case to evaluations, but looking at the current eval code in getEvalGroupsForUser, it's efficient for authz (using authzGroupService.getAuthzGroupsIsAllowed()), but is still loading each site individually, just to get the title.
In performance terms, the aim (esp. if this is say a user homepage widget which shows polls open for voting) is to have the number of db queries independent of the size of the user's site membership or the number of polls in each site or in total. For the widget-case, the most efficient solution is something like: - Get the list of sites that the user belongs to - Get the subset of those sites which the user hasn't hidden - Get the intersection of the subset above and authzGroupService.getAuthzGroupsIsAllowed() - From the resulting set of site contexts, get (i) polls open for voting, (ii) "current" polls (by some definition) for which results are viewable. What are the use cases for the entity picker? Sounds like the same use case for the picker. You would basically be "picking" to either embed a poll in a page or embed the results (which I sort of see as possibly the same action). The options would have to be to limit the selectable polls to the ones they have administrative control over. There would not really be a use case for embedding the polls that someone has the ability to take.
On the other hand, there is certainly a use case for getting all polls a user can take (for the widget case). I am thinking a widget which shows either a specific poll OR shows a list of all the polls you have not yet responded to and when you select one the widget transforms into the poll itself. You are right about having to fetch site titles for eval. This is annoying but since sites are cached and 9 times out of 10 the ones we are looking up are already loaded anyway (especially in the case of getting them for the current user) it ends up typically adding very little. Ideally the site service needs 3-4 more methods for finding sites and partially finding site information. Moved polls to new version and fixed poms
Notes on the entitypicker support: there are really 3 actions that you might want to select for a poll. Not all users would have all actions available. Some may be time-limited (vote/results), some affected by permissions and/or poll ownership (manage).
* Vote * View results * Manage So in a context like authoring content, the entitypicker needs to allow the user to select a poll, then select an action/view for the poll. [Bulk Comment] This Task (or Sub-Task) issue currently is Unresolved, but has a Fix Version of 2.6. The Code Freeze for Sakai 2.6 has now passed (29-Sep-2008, 8:00am Eastern US time).
If you are still working to resolve this issue for 2.6, then please post an email to sakai-dev to let everyone now that you need an exception for this JIra, explain what is left to do, and when you plan to have the work completed; please include that information here in the Jira as well. Otherwise, if the resolution of this task has been postponed, please reset the Fix Version to 2.7 or Unknown, depending on what you're new expectations for completion are. If the issue is no longer relevant, please close the issue as Won't Fix or Incomplete with an explanation of why. Thanks! [Bulk Comment] The fix version for this Unresolved Tasks still indicates 2.6, but the code freeze is well passed now, and no exception was requested for this work. The Fix Version of this issue is being reset to 2.7, with the expectation that you are planning to finish the work in time for that release. If that is not the case, please update the Fix Version appropriately, or if you are not actively working on this issue, consider turning it into a Feature Request.
Current problems:
NPE if not logged in: for example a URL like: http://mocha.cet.uct.ac.za:8080/direct/poll-vote/1.json message Direct request failure: NullPointerException:null:Direct request failure: NullPointerException:null: Sakai version: 2.7.0([r54744-rtrunk]) Server: mocha.cet.uct.ac.za(sakai-trunk-a) [sakai-trunk-a-1228242072953] Request URI: /direct/poll-vote/1.json Path Info: /poll-vote/1.json Context path: /direct Method: GET Logs show: java.lang.NullPointerException at org.sakaiproject.poll.tool.entityproviders.PollVoteEntityProvider.getEntity(PollVoteEntityProvider.java:146) at org.sakaiproject.entitybroker.impl.EntityBrokerManager.fetchEntityObject(EntityBrokerManager.java:307) at org.sakaiproject.entitybroker.impl.EntityBrokerManager.internalGetEntities(EntityBrokerManager.java:503) at org.sakaiproject.entitybroker.impl.EntityBrokerManager.getEntitiesData(EntityBrokerManager.java:339) at org.sakaiproject.entitybroker.impl.EntityHandlerImpl.handleEntityAccess(EntityHandlerImpl.java:472) at org.sakaiproject.entitybroker.servlet.DirectServlet.dispatch(DirectServlet.java:151) at org.sakaiproject.entitybroker.servlet.DirectServlet.handleRequest(DirectServlet.java:119) at org.sakaiproject.entitybroker.servlet.DirectServlet.service(DirectServlet.java:95) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) Plus as a site owner, you can see who voted and how they voted with a URL like this: http://mocha.cet.uct.ac.za:8080/direct/poll-vote.json?pollId=7 which defeats the business rules of the tool, viz. polls are anonymous. Either needs to be resolved correctly for 2.6.0, or disabled or backed out.
r55737 addresses the disclosure issuse in stephen's comment. The list is now anonymized for non-admin users (except for the users own submission)
testing would suggest that the other problem is fixed in trunk
Verified on local trunk build - user identities in votes are not visible to a site maintainer.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Blocker
Add entity support to Polls tool
