[sakai2-tcc] Dev list code reviews

[Berg, Alan]

Yes, a good patch idea. Murcia are doing a lot of good work including an interesting confluence page on their upgrade experiences to 2.9

https://confluence.sakaiproject.org/display/PROD/University+of+Murcia's+upgrading+experience+from+2.7+to+2.9

And a case study which will be handed out at the reception of the conference.

They also contribute hours for different types of testing.

Nice to see positive thinking and energy at work enhancing a community source product.


Alan

Anthony Whyte <arwhyte at umich.edu> wrote:



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<mailto:jmariano at um.es>>
Date: May 30, 2013 5:32:02 PM EDT
To: dev sakai <sakai-dev at collab.sakaiproject.org<mailto: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<mailto:bjones86 at uwo.ca>>
Date: May 30, 2013 12:40:28 PM EDT
To: 'dev sakai' <sakai-dev at collab.sakaiproject.org<mailto: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<mailto:bjones86 at uwo.ca>

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