[sakai2-tcc] Dev list code reviews

Anthony Whyte arwhyte at umich.edu
Thu May 30 14:59:58 PDT 2013


On the CLE team call today I encouraged two CLE contributors to surface a couple minor feature enhancements on the dev list for review, acknowledgement and comment (emails below).  I encourage TCC members to take a moment to review and comment on each enhancement either on the dev list or as a ticket comment.

https://jira.sakaiproject.org/browse/SAK-23567 (in trunk -- which translates into at least one +1 from a committer)
https://jira.sakaiproject.org/browse/SAK-23257 (patch provided)

Irrespective of one's take on these tickets, I think we should encourage developer-to-developer exchanges on list, especially so in the case of contributors who are not in a position to utilize lazy consensus to push a fix to trunk.

In one case, the contributor stated that he was hesitant to ping the dev list because he thought his email would be ignored.  He asked if one of us would post the email on his behalf as he thought it more likely that the proposed enhancement would get a hearing.  Useful feedback though a bit disconcerting.

Cheers,

Anthony


Begin forwarded message:

> From: José Mariano Luján <jmariano at um.es>
> Date: May 30, 2013 5:32:02 PM EDT
> To: dev sakai <sakai-dev at collab.sakaiproject.org>
> Subject: [Building Sakai] Proposed minor enhancement: SAK-23567 NeoPortal site title handling
> 
> Hi dev list,
> Today, on the CLE Call, we discussed jira SAK-23567 [1] which is a feature request from Univ. of Murcia. The CLE Team thinks that some discussion from the list is needed so, please, consider taking a few minutes to look at it. It would be much appreciated. 
> 
> Use case
> Our CLE installation features many long site titles, as in, "This is the subject part I", "This is the subject part II".  In each case, truncating the site titles at position X results in site titles that are indistinguishable from one another (e.g., "This is the subj..."). We need greater flexibility than what the current solution provides.
> 
> Proposed Solution (patches provided)
> We patched 
>       portal-impl/impl/src/java/org/sakaiproject/portal/charon/site/PortalSiteHelperImpl.java
>       portal-render-engine-impl/pack/src/webapp/vm/neoskin/includeTabs.vm
> 
> Note the introduction of 2 new properties
> 
>       site.title.cut.method = customize the cut method. Default 100:0. 
>       site.title.cut.separator = separator string. Default ... 
> 
> We basically use a couple of new properties to choose the way we want to cut the title displayed. The value 'cut.method' has the format X:Y, wich means that X is the percent of maxlength at the beginning and Y is the percent of maxlength at the end. Now, if you choose 50:50 and [...], the above example, will get something like "This is[...]part I" and "This is[...]part II". 
> 
> An example of how it could work. Screenshots attached on the jira.
> 
>    # Max length for site title display 
>    # Default 25 characters 
>    #site.title.maxlength=25 
> 
>    # Cut method for site title display 
>    # Default 100:0 display the first site.title.maxlength characters and the separator string at the end 
>    # Other values: 
>    # 0:100 display the last site.title.maxlength characters and the separator string at the beginning 
>    # 50:50 display first site.title.maxlength*50% characters the separator string and the last site.title.maxlength*50% 
>    #site.title.cut.method=100:0 
> 
>    # Separator string used to separate characters in cut method 
>    # Default ... 
>    #site.title.cut.separator= ...  
> 
> Proposed fix version
> Trunk (2.10), 2.9.3
> 
> Feel free to review or comment, your help is much appreciated.
> 
> Thanks, Mariano
> 
> [1] - https://jira.sakaiproject.org/browse/SAK-23567


Begin forwarded message:

> From: Brian Jones <bjones86 at uwo.ca>
> Date: May 30, 2013 12:40:28 PM EDT
> To: 'dev sakai' <sakai-dev at collab.sakaiproject.org>
> Subject: [Building Sakai] Remove ability for instructors to assign instructor role to others
> 
> Hello,
> 
> Our institution required a (configurable) method of restricting what roles
> maintainers can assign to existing site members, and for adding new
> participants.
> 
> We have developed this feature and provided a .patch for the community here:
> https://jira.sakaiproject.org/browse/SAK-23257
> 
> It is already committed to trunk, but on the CLE call this morning it was
> decided that it should be floated out to the dev list for analysis,
> comments, suggestions, etc.
> 
> The use case (for Western), is that our SIS integration defines all roster
> members and roles, and we cannot allow maintainers (instructors) the ability
> to assign other people as elevated roles (i.e. give someone else the
> instructor role).
> 
> Our proposed solution to this is to define a set of 'allowed roles' in
> sakai.properties, and then both limit the choices on the UI via this
> property, and also do a backend check to ensure that the user role being set
> is contained in this list of 'allowed roles'.
> 
> It was brought up on the CLE call that the Course Management API also
> supports this sort of feature, although using the CM API is optional, not
> required. Therefore there needs to be another, more general way of
> accomplishing this without needing to use the CM API.
> 
> Another option suggested was to make this into a permission, but we chose
> not to go down this path because a single permission is more of an 'all or
> nothing' approach, rather than being configurable on a per-role basis
> (especially in a system where there are likely custom roles that are not
> provided out of the box).
> 
> So, I would like to invite everyone to take a look at this feature/patch.
> Are there other institutions that would utilize this feature, or have
> similar use cases? Is it acceptable as-is? Any comments, suggestions, etc
> are welcome. Feel free to chime in!
> 
> Cheers,
> 
> Brian Jones
> Applications Development
> Information Technology Services
> Support Services Building, Room 4326
> Western University
> (519) 661-2111 x86969
> bjones86 at uwo.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130530/16109814/attachment.html 


More information about the sakai2-tcc mailing list