[uportal-dev] Resource Aggregation

[Drew Wills]

Folks,

Can anyone share some insights on how Resource Aggregation is supposed to work? 
 How much is it supposed to aggregate (i.e. combine)?  What triggers 
aggregation or causes the system to ignore a file for aggregation?

https://github.com/Jasig/uPortal/pull/602 


drew

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Announcing the Release of uPortal 4.2.1

[Drew Wills]

Folks,

The uPortal Developer Community is proud to announce 4.2.1!

This version of uPortal is a maintenance/bug-fix release of the 4.2 minor 
version.  It includes 21 bug fixes and enhancements in total, but the primary 
motivation for this new patch release is updating to the new Java Portlet API 
2.1 specification.

Please see the news item on apereo.org <http://apereo.org/>:

  - https://www.apereo.org/projects/uportal/announcing-uportal-421 
<https://www.apereo.org/projects/uportal/announcing-uportal-421>

Or the complete release notes on the wiki:

  - https://wiki.jasig.org/display/UPC/4.2.1

drew wills

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] proposal : uPortal Developers as public GitHub team

[Drew Wills]

Yes... +1.

drew

> On Oct 1, 2015, at 6:35 AM, Andrew W Petro  wrote:
> 
> uPortal developers,
> 
> The "team" in GitHub representing uPortal committership is currently "secret" 
> rather than "public".
> 
> http://goo.gl/VhcWng 
> 
> This seems needlessly opaque when we could have more transparency by making 
> this team "public", as in, publicly visible.
> 
> Proposal: flip the switch to make it "public" instead.
> 
> +1
> 
> -Andrew
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org 
>  as: awi...@unicon.net 
> 
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev 
> 

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] CODE FREEZE on rel-4-2-patches please

[Drew Wills]

Folks,

The release tag is cut — code freeze over.

drew

> On Sep 30, 2015, at 10:26 AM, Drew Wills  wrote:
> 
> Folks,
> 
> I’m working on a 4.2.1 release.  Please do not apply commits to the 
> rel-4-2-patches branch until further notice.
> 
> thank you,
> 
> drew wills
> -- 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] CODE FREEZE on rel-4-2-patches please

[Drew Wills]

Folks,

I’m working on a 4.2.1 release.  Please do not apply commits to the 
rel-4-2-patches branch until further notice.

thank you,

drew wills
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] proposed: Benito Gonzalez as uPortal committer

[Drew Wills]

+1

drew

> On Sep 28, 2015, at 8:32 AM, James Wennmacher  wrote:
> 
> +1
> James Wennmacher - Unicon
> 480.558.2420
> On 09/28/2015 05:56 AM, Aaron Grant wrote:
>> +1 
>> 
>> Benito has been a really big help to us over the last few months ironing out 
>> issues with the uPortal framework and various portlets.
>> 
>> On Fri, Sep 25, 2015 at 6:40 PM, Andrew W Petro > > wrote:
>> Proposal to recognize Benito
>> 
>> 
>> https://github.com/Jasig/uPortal/commits?author=bjagg 
>> 
>> 
>> 
>> as a uPortal committer, privileged to merge pull requests and otherwise push 
>> to Jasig/uPortal repo and related, aka as a member of
>> 
>> 
>> https://github.com/orgs/Jasig/teams/uportal-developers 
>> 
>> 
>> (Benito is already a member of the "Portlet Developers" team.)
>> 
>> 
>> +1
>> 
>> 
>> -Andrew
>> 
>>  -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org 
>>  as: asgr...@oakland.edu 
>> 
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev 
>> 
>> 
>> 
>> -- 
>> Aaron Grant
>> Senior Applications Architect
>> Oakland University - UTS 
>> 
>> -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org 
>>  as: jwennmac...@unicon.net 
>> 
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev 
>> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] [cas-user] Resolving attirbutes dao results in "no value specified for parameter 2"

[Drew Wills]

> On Aug 20, 2015, at 5:09 PM, James Wennmacher  wrote:
> 
> Would NamedParameterJdbcPersonAttributeDao work for him?

I was thinking the same thing.  I bet it would allow him to run the query he 
wants.

drew

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] UP-4516 - Significant overhaul of IPermissionPolicy and AnyUnblockedGrantPermissionPolicy

[Drew Wills]

Folks,

I just posted a pull request with a significant re-boot of the permissions 
code...

  - https://github.com/Jasig/uPortal/pull/570 


We’re observing some performance concerns as the amount of permissions checking 
we do increases.  I added a new kind of caching, and it seems to help… but 
further improvements are probably possible.

drew


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal API endpoint for returning portlet markup (aka exclusive window_state alternative) for Rich JS UI and uMobile

[Drew Wills]

Folks,

I just created a PR for this feature:  
https://github.com/Jasig/uPortal/pull/562 


It doesn’t have all the bells & whistles covered in the discussion so far, but 
it does cover the basic, 80% case.

drew

> On May 28, 2015, at 2:15 PM, James Wennmacher  wrote:
> 
> For the Rich-JS Angular uPortal front-end we are working on, we need to 
> create a uPortal API for returning portlet markup without using the current 
> EXCLUSIVE window-state strategy.  As Anthony elaborated in 
> http://jasig.275507.n4.nabble.com/Name-for-new-window-state-that-was-like-DETACHED-td4665156.html
>  
> ,
>  this (mis)use of Window State has some negative ramifications.  We are 
> finding much the same.
> 
> I am planning on following Andrew P's excellent idea (also in the above 
> thread) of creating a uPortal REST endpoint that returns the markup for a 
> single portlet, effectively like EXCLUSIVE mode without actually setting or 
> using the Window State.  I want to discuss and collaborate on this feature as 
> I see it having broad applicability, minimally the two rich JS UIs and 
> uMobile.
> 
> I haven't dug into the code details yet so I'm sure I'll find a few things 
> that might require some changes, but I wanted to present my overall thoughts 
> first for community feedback:
> endpoint is /uPortal/api/portlet/{fname}.{ID}/exclusive
> As opposed to /uPortal/api/portlet/{fname} which returns minor portlet 
> publishing info
> Including ID which would be from /uPortal/layout.json or 
> /uPortal/api/layout/v2/layout.json 
> afterhttps://issues.jasig.org/browse/UP-4438 
>  is processed.  Including ID since a 
> portlet can appear multiple times on a page so fname is not sufficient.
> Must return the markup as response body.  Failure to return markup should 
> return appropriate HTTP error code. Should never return a 302. I propose:
> 200 - content returned in response body
> 204 - no content (I think it is better the portal definitively indicates no 
> content).  An example of this might be when a portlet is minimized or has no 
> content?
> 302 - A poorly formed URL that goes into uPortal would do the normal 302 to a 
> uPortal landing page, but I consider this a client-side error we probably 
> shouldn't try to prevent.
> 304 - return this if supporting eTag (or If-Modified-Since but I'm not sure 
> this makes sense)?
> 401 - Unauthorized (need to authenticate)
> 403 - Forbidden for some reason, probably that it exists but user doesn't 
> have access to it
> 404 - for invalid portlet ID or URL (assuming URL at least gets to the 
> endpoint)
> 500 - for portlet throwing an error, etc.  
> markup returned in body of response. If portlet supports RENDER_HEADERS, 
> perhaps this should be the combined RENDER_HEADERS plus content 
> (RENDER_HEADERS content first of course).
> Questions:
> Should the HTTP Cache headers respect the portlet cache parameters; e.g. if 
> portlet's entry in portlet.xml had 60 
> should the HTTP cache headers indicate a 60 second cache time?  I think not 
> since an Action request should invalidate the cache.  The JS UI could figure 
> that out, but the browser could not.  If we always send an eTag and maybe 
> If-Modified-Since on the response and allow uPortal to intelligently manage 
> the caching primarily using its existing render output cache mechanism, I 
> think this would be as good as we need.
> Do we need to allow for ?refresh=true to force invoking the portlet and not 
> using cached render output?  I don't know of a use case for this at this 
> point.
> Potential future expansions:
> Create an endpoint to return content for a list of portlets or all portlets 
> on a specific tab
> I welcome your thoughts on this idea.  Written up as 
> https://issues.jasig.org/browse/UP-4478 
> .
> -- 
> James Wennmacher - Unicon
> 480.558.2420
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Some REST API enhancements

[Drew Wills]

Folks,

I just created a PR for an enhancement to our collection of REST APIs...

  - https://github.com/Jasig/uPortal/pull/561 


Insights, as ever, are appreciated.

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] PAGS Tester for AdHoc Groups

[Drew Wills]

Folks,

There are now 2 Pull Requests in GitHub related to this effort (aimed it 
breaking it into bite-sized segments)…

  - https://github.com/Jasig/uPortal/pull/546 
<https://github.com/Jasig/uPortal/pull/546>
UP-4456:  PAGS (JPA) -- Add constructors to IPersonTester implementations 
that accept a single IPersonAttributesGroupTestDefinition;  deprecate the ones 
that accept String,String

  - https://github.com/Jasig/uPortal/pull/547 
<https://github.com/Jasig/uPortal/pull/547>
UP-4458:  Expand the nature of the data than can be defined in a PAGS 
 element with Set includes and Set excludes

Benito’s AdHocGroupsTester is built upon these 2 enhancements.

drew


> On May 6, 2015, at 9:43 AM, Drew Wills  wrote:
> 
> James...
> 
>> On May 5, 2015, at 1:41 PM, James Wennmacher > <mailto:jwennmac...@unicon.net>> wrote:
>> 
>> I think
>> 
>> > script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>> ">
>>   Member of Students (PAGS)
>>   Member of Students group
>>   
>> 
>>   Students
>>   Test Users
>> 
>>   
>> 
>> 
>> is great and a much cleaner solution.  I want to verify you could do 
>> something like the following:
> 
> Except that (I feel) the child groups *need* to be wrapped in a  
> element and the  element *needs* to be there.  I don’t want to 
> start teaching Import/Export about specific IPersonTester implementations and 
> whether you can “infer” one or another specifically based on the nature of 
> the child elements found within the .
> 
> Also, the element names “member-of-group” & “not-member-of-group” are 
> workable — that approach would be okay — but I think even better is 
>  & , here’s why…
> 
> In the future we may want to create even more IPersonTester classes that do 
> new and innovative things.  For their functioning, they may need some 
> parameters in the  element as well.  These parameters, moreover, will 
> need to be modeled as members on IPersonAttributesGroupTestDefinition and the 
> JPA-managed implementation of that interface as well… so that means (albeit 
> minor) database schema changes.  I’d like to avoid those, to the extent 
> possible, so I’d prefer to use names that are more likely to be reusable in 
> the future with other IPersonTesters.
> 
> So my proposal for the XML corresponding to this example would be (note the 
> version change in the script attribute)…
> 
>  script="classpath://org/jasig/portal/io/import-pags-group_v4-3.crn 
> ">
>   Non-Test Students
>   Students who are not test accounts
>   
> 
>   
> 
> org.jasig.portal.groups.pags.testers.AdHocGroupTester
> Students
> Test Users
>   
> 
>   
> 
> 
> This way, furthermore, it’s clear how you combine test definitions based on 
> the AdHocGroupTester with other criteria (just as we’ve always done).  This 
> approach makes this new type of group less different or weird as compared 
> with existing groups, testers, data files, documentation, Import/Export 
> support, etc.
> 
> drew
> 
> 
> 
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] PAGS Tester for AdHoc Groups

[Drew Wills]

James...

> On May 5, 2015, at 1:41 PM, James Wennmacher  wrote:
> 
> I think
> 
>  script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
> ">
>   Member of Students (PAGS)
>   Member of Students group
>   
> 
>   Students
>   Test Users
> 
>   
> 
> 
> is great and a much cleaner solution.  I want to verify you could do 
> something like the following:

Except that (I feel) the child groups *need* to be wrapped in a  element 
and the  element *needs* to be there.  I don’t want to start 
teaching Import/Export about specific IPersonTester implementations and whether 
you can “infer” one or another specifically based on the nature of the child 
elements found within the .

Also, the element names “member-of-group” & “not-member-of-group” are workable 
— that approach would be okay — but I think even better is  & 
, here’s why…

In the future we may want to create even more IPersonTester classes that do new 
and innovative things.  For their functioning, they may need some parameters in 
the  element as well.  These parameters, moreover, will need to be 
modeled as members on IPersonAttributesGroupTestDefinition and the JPA-managed 
implementation of that interface as well… so that means (albeit minor) database 
schema changes.  I’d like to avoid those, to the extent possible, so I’d prefer 
to use names that are more likely to be reusable in the future with other 
IPersonTesters.

So my proposal for the XML corresponding to this example would be (note the 
version change in the script attribute)…


  Non-Test Students
  Students who are not test accounts
  

  

org.jasig.portal.groups.pags.testers.AdHocGroupTester
Students
Test Users
  

  


This way, furthermore, it’s clear how you combine test definitions based on the 
AdHocGroupTester with other criteria (just as we’ve always done).  This 
approach makes this new type of group less different or weird as compared with 
existing groups, testers, data files, documentation, Import/Export support, etc.

drew





-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] rel-4-2-patches branch created

[Drew Wills]

Folks,

I create the branch for patch releases on the 4.2 line.  I sorted through the 
commits since 4.2.0 and applied those that seems to apply to 4.2, leaving those 
that didn’t in master (only).

drew



-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] PAGS Tester for AdHoc Groups

[Drew Wills]

I created a JIRA specifically for the new ad hoc IPersonTester work...

  - https://issues.jasig.org/browse/UP-4457 
<https://issues.jasig.org/browse/UP-4457>

I think it’s sensible to get that part in as a stand-alone enhancement.

drew

> On May 5, 2015, at 5:22 PM, Benito J. Gonzalez  wrote:
> 
> I will check out the changes — thank you, Drew!
> 
> Benito J. Gonzalez - Unicon
> bgonza...@unicon.net <mailto:bgonza...@unicon.net>
> 480.558.2360
> 
> 
> 
>> On May 5, 2015, at 5:07 PM, Drew Wills > <mailto:awi...@unicon.net>> wrote:
>> 
>> Here you go…
>> 
>> https://github.com/Jasig/uPortal/pull/546 
>> <https://github.com/Jasig/uPortal/pull/546>
>> 
>> drew
>> 
>>> On May 5, 2015, at 3:36 PM, Benito J. Gonzalez >> <mailto:bgonza...@unicon.net>> wrote:
>>> 
>>> Sounds good!
>>> 
>>> Benito J. Gonzalez - Unicon
>>> bgonza...@unicon.net <mailto:bgonza...@unicon.net>
>>> 480.558.2360
>>> 
>>> 
>>> 
>>>> On May 5, 2015, at 3:06 PM, Drew Wills >>> <mailto:awi...@unicon.net>> wrote:
>>>> 
>>>> Benito et al.,
>>>> 
>>>> I believe this change will help with these efforts:
>>>> 
>>>>   - https://issues.jasig.org/browse/UP-4456 
>>>> <https://issues.jasig.org/browse/UP-4456>
>>>> 
>>>> I’m going to organize it into a pull request.
>>>> 
>>>> drew
>>>> 
>>>> 
>>>>> On May 5, 2015, at 2:18 PM, Benito J. Gonzalez >>>> <mailto:bgonza...@unicon.net>> wrote:
>>>>> 
>>>>> Yep, you got it. That is how it should work.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Benito J. Gonzalez - Unicon
>>>>> bgonza...@unicon.net <mailto:bgonza...@unicon.net>
>>>>> 480.558.2360
>>>>> 
>>>>> 
>>>>> 
>>>>>> On May 5, 2015, at 1:41 PM, James Wennmacher >>>>> <mailto:jwennmac...@unicon.net>> wrote:
>>>>>> 
>>>>>> Benito,
>>>>>> 
>>>>>> I think
>>>>>> 
>>>>>> >>>>> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>>>>> ">
>>>>>>   Member of Students (PAGS)
>>>>>>   Member of Students group
>>>>>>   
>>>>>> 
>>>>>>   Students
>>>>>>   Test Users
>>>>>> 
>>>>>>   
>>>>>> 
>>>>>> 
>>>>>> is great and a much cleaner solution.  I want to verify you could do 
>>>>>> something like the following:
>>>>>> 
>>>>>> >>>>> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>>>>> ">
>>>>>>   Member of Students (PAGS)
>>>>>>   Member of Students group
>>>>>>   
>>>>>> 
>>>>>>   Students
>>>>>>   English Majors
>>>>>>   Test Users
>>>>>>   Boring Users
>>>>>>   
>>>>>> agentDevice
>>>>>> 
>>>>>> org.jasig.portal.groups.pags.testers.PropertyInvertedRegexTester
>>>>>> 
>>>>>> org.jasig.portal.http.header.userAgent.mobile.regex.pattern
>>>>>>   
>>>>>> 
>>>>>>   
>>>>>>   
>>>>>> 
>>>>>>   Faculty
>>>>>>   BannedFaculty
>>>>>> 
>>>>>>   
>>>>>> 
>>>>>> 
>>>>>> e.g. following the rules that test-group members are ANDed together, 
>>>>>> selection-tests are ORed together so you can have multiple 
>>>>>> member-of-group and not-member-of-group and 1 or more test elements in a 
>>>>>> test-group.
>>>>>> James Wennmacher - Unicon
>>>>>> 480.558.2420
>>>>>> On 05/04/2015 06:15 PM, Benito J. Gonzalez wrote:
>>>>>>> All,
>>>>>>> 
>>>>>>> My current design supports PAGS group definitions as shown by the 
>>>&

Re: [uportal-dev] rel-4-2-patches branch created

[Drew Wills]

Also heads up... I bumped the version of master to 4.3.0-SNAPSHOT.

drew

> On May 6, 2015, at 8:32 AM, Drew Wills  wrote:
> 
> Folks,
> 
> I create the branch for patch releases on the 4.2 line.  I sorted through the 
> commits since 4.2.0 and applied those that seems to apply to 4.2, leaving 
> those that didn’t in master (only).
> 
> drew
> 
> 
> 
> -- 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] PAGS Tester for AdHoc Groups

[Drew Wills]

Here you go…

https://github.com/Jasig/uPortal/pull/546 
<https://github.com/Jasig/uPortal/pull/546>

drew

> On May 5, 2015, at 3:36 PM, Benito J. Gonzalez  wrote:
> 
> Sounds good!
> 
> Benito J. Gonzalez - Unicon
> bgonza...@unicon.net <mailto:bgonza...@unicon.net>
> 480.558.2360
> 
> 
> 
>> On May 5, 2015, at 3:06 PM, Drew Wills > <mailto:awi...@unicon.net>> wrote:
>> 
>> Benito et al.,
>> 
>> I believe this change will help with these efforts:
>> 
>>   - https://issues.jasig.org/browse/UP-4456 
>> <https://issues.jasig.org/browse/UP-4456>
>> 
>> I’m going to organize it into a pull request.
>> 
>> drew
>> 
>> 
>>> On May 5, 2015, at 2:18 PM, Benito J. Gonzalez >> <mailto:bgonza...@unicon.net>> wrote:
>>> 
>>> Yep, you got it. That is how it should work.
>>> 
>>> Thanks!
>>> 
>>> Benito J. Gonzalez - Unicon
>>> bgonza...@unicon.net <mailto:bgonza...@unicon.net>
>>> 480.558.2360
>>> 
>>> 
>>> 
>>>> On May 5, 2015, at 1:41 PM, James Wennmacher >>> <mailto:jwennmac...@unicon.net>> wrote:
>>>> 
>>>> Benito,
>>>> 
>>>> I think
>>>> 
>>>> >>> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>>> ">
>>>>   Member of Students (PAGS)
>>>>   Member of Students group
>>>>   
>>>> 
>>>>   Students
>>>>   Test Users
>>>> 
>>>>   
>>>> 
>>>> 
>>>> is great and a much cleaner solution.  I want to verify you could do 
>>>> something like the following:
>>>> 
>>>> >>> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>>> ">
>>>>   Member of Students (PAGS)
>>>>   Member of Students group
>>>>   
>>>> 
>>>>   Students
>>>>   English Majors
>>>>   Test Users
>>>>   Boring Users
>>>>   
>>>> agentDevice
>>>> 
>>>> org.jasig.portal.groups.pags.testers.PropertyInvertedRegexTester
>>>> 
>>>> org.jasig.portal.http.header.userAgent.mobile.regex.pattern
>>>>   
>>>> 
>>>>   
>>>>   
>>>> 
>>>>   Faculty
>>>>   BannedFaculty
>>>> 
>>>>   
>>>> 
>>>> 
>>>> e.g. following the rules that test-group members are ANDed together, 
>>>> selection-tests are ORed together so you can have multiple member-of-group 
>>>> and not-member-of-group and 1 or more test elements in a test-group.
>>>> James Wennmacher - Unicon
>>>> 480.558.2420
>>>> On 05/04/2015 06:15 PM, Benito J. Gonzalez wrote:
>>>>> All,
>>>>> 
>>>>> My current design supports PAGS group definitions as shown by the 
>>>>> following simple example:
>>>>> 
>>>>> >>>> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>>>> ">
>>>>>   Member of Students (PAGS)
>>>>>   Member of Students group
>>>>>   
>>>>> 
>>>>>   
>>>>> 
>>>>>   Students
>>>>> 
>>>>> 
>>>>>   Test Users
>>>>> 
>>>>>   
>>>>> 
>>>>>   
>>>>> 
>>>>> 
>>>>> Working on the implementation, I realized that there was no need for 
>>>>> multiple adhoc-group-test stanzas since all the tests in the surrounding 
>>>>> test-group are AND-ed together as are the group tests inside 
>>>>> adhoc-group-test nodes. 
>>>>> 
>>>>> As I consider persistence, it dawned on me that there was not need for a 
>>>>> parent adhoc-group-test for the inner member-of and not-member-of tests 
>>>>> since there is a 1-to-1 correspondence to the test-group.
>>>>> 
>>>>> Would the following be an improvement or is there an advantage to the 
>>>>> extra stanzas?
>>>>> 
>>>>> >>>> script="class

Re: [uportal-dev] PAGS Tester for AdHoc Groups

[Drew Wills]

Benito et al.,

I believe this change will help with these efforts:

  - https://issues.jasig.org/browse/UP-4456 


I’m going to organize it into a pull request.

drew


> On May 5, 2015, at 2:18 PM, Benito J. Gonzalez  wrote:
> 
> Yep, you got it. That is how it should work.
> 
> Thanks!
> 
> Benito J. Gonzalez - Unicon
> bgonza...@unicon.net 
> 480.558.2360
> 
> 
> 
>> On May 5, 2015, at 1:41 PM, James Wennmacher > > wrote:
>> 
>> Benito,
>> 
>> I think
>> 
>> > script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>> ">
>>   Member of Students (PAGS)
>>   Member of Students group
>>   
>> 
>>   Students
>>   Test Users
>> 
>>   
>> 
>> 
>> is great and a much cleaner solution.  I want to verify you could do 
>> something like the following:
>> 
>> > script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>> ">
>>   Member of Students (PAGS)
>>   Member of Students group
>>   
>> 
>>   Students
>>   English Majors
>>   Test Users
>>   Boring Users
>>   
>> agentDevice
>> 
>> org.jasig.portal.groups.pags.testers.PropertyInvertedRegexTester
>> 
>> org.jasig.portal.http.header.userAgent.mobile.regex.pattern
>>   
>> 
>>   
>>   
>> 
>>   Faculty
>>   BannedFaculty
>> 
>>   
>> 
>> 
>> e.g. following the rules that test-group members are ANDed together, 
>> selection-tests are ORed together so you can have multiple member-of-group 
>> and not-member-of-group and 1 or more test elements in a test-group.
>> James Wennmacher - Unicon
>> 480.558.2420
>> On 05/04/2015 06:15 PM, Benito J. Gonzalez wrote:
>>> All,
>>> 
>>> My current design supports PAGS group definitions as shown by the following 
>>> simple example:
>>> 
>>> >> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>> ">
>>>   Member of Students (PAGS)
>>>   Member of Students group
>>>   
>>> 
>>>   
>>> 
>>>   Students
>>> 
>>> 
>>>   Test Users
>>> 
>>>   
>>> 
>>>   
>>> 
>>> 
>>> Working on the implementation, I realized that there was no need for 
>>> multiple adhoc-group-test stanzas since all the tests in the surrounding 
>>> test-group are AND-ed together as are the group tests inside 
>>> adhoc-group-test nodes. 
>>> 
>>> As I consider persistence, it dawned on me that there was not need for a 
>>> parent adhoc-group-test for the inner member-of and not-member-of tests 
>>> since there is a 1-to-1 correspondence to the test-group.
>>> 
>>> Would the following be an improvement or is there an advantage to the extra 
>>> stanzas?
>>> 
>>> >> script="classpath://org/jasig/portal/io/import-pags-group_v4-1.crn 
>>> ">
>>>   Member of Students (PAGS)
>>>   Member of Students group
>>>   
>>> 
>>>   Students
>>>   Test Users
>>> 
>>>   
>>> 
>>> 
>>> 
>>> One thought is that testing for group membership could be more efficient if 
>>> all the group tests were done together. Yet, that code could be rolled up 
>>> into the test-group class, TestGroup.
>>> 
>>> Thoughts?
>>> 
>>> Benito J. Gonzalez - Unicon
>>> bgonza...@unicon.net 
>>> 480.558.2360
>>> 
>>> 
   
 
   Students
   Mobile Device Access
 
 
   Testers
 
   
>>> 
>>> -- 
>>> 
>>> You are currently subscribed to uportal-dev@lists.ja-sig.org 
>>>  as: jwennmac...@unicon.net 
>>> 
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev 
>>> 
>> -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org 
>>  as: bgonza...@unicon.net 
>> 
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev 
>> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Announcing uPortal 4.2.0

[Drew Wills]

The uPortal Developer Community is proud to announce the newest minor version 
of uPortal:  4.2.0.

This version of uPortal is a general audience (GA) release.  It provides 
several new and exciting features that are not in the 4.1.x line, as well as 
all the maintenance updates – primarily bug & security fixes – that are 
included in the 4.1.x line.  This release includes some modest changes to 
default configuration settings.  (See "Notes on Deploying & Upgrading" below.)  
In upgrading to uPortal 4.2 from version 4.1, you are free to continue with the 
configurations you have;  but you should review these changes and strongly 
consider making them locally.  These changes offer better alignment with 
planned future enhancements.

Highlights
-

• The following enhancements or bug fixes are especially noteworthy.
• Hover chrome, which provides access to chrome-based functions (e.g. 
Minimize, Maximize, Remove, etc.) for portlets with showChrome=false
• Numerous enhancements and fixes to uPortal's Multi-Tenancy features
• The Portlet Manager UI has been greatly improved & simplified
• A client-side session timeout warning message, with the option to 
continue the session, has been added
• A 6-column layout option has been added;  works gorgeously with small 
portlets like the App Launcher
• The Portlet Marketplace UI has been greatly improved & simplified
• Added MAINTENANCE portlet lifecycle state (accessible from the 
Portlet Manager), which displays a user-friendly message when a portlet is 
out-of-service
• Added support for the Experience ("Tin Can") API
• Added Transient Layout Node support for unauthenticated (guest) 
users;  this enhancement means that guest users can access – provided they have 
the proper permissions -- portlets that are not on the guest layout

Notes on Deploying & Upgrading


• Requires Servlet API 3.0 to run. Tomcat 7.0 supports this version. 
Choose the most recent Tomcat 7.
• Requires Java 7 ("JDK 1.7"). Java 8 ("JDK 1.8") is not yet supported.
• Data export and import is required when upgrading from uPortal 4.0.x 
or earlier. (It's also worth considering if you're upgrading from uPortal 
4.1.x, depending on how much is changing.)
• The default PAGS implementation has been switched from XML file-based 
(legacy) to database-based (JPA); the legacy configuration still works, but you 
may want to make the switch (some future administrative tools may require the 
JPA strategy); there is a Groovy script for migrating
• The BROWSE permission now exclusively governs whether a portlet is 
available to a user in the Customize Gallery, Search results, and the 
/api/portletList API (used by Customize Gallery). The behavior of 
/api/portletList, moreover, has changed to include portlets with no categories. 
This change will require uPortal 4.1 and prior to review their data entities to 
add BROWSE permissions when migrating portlet definitions to uPortal 4.2.0. 
Without the BROWSE permission, users will not see portlets in these interfaces.
• The Universality theme has been retired; Respondr is now the only 
theme for non-mobile devices

Complete release notes are available here:  
https://wiki.jasig.org/display/UPC/4.2.0

Thanks tremendously to everyone who contributed!

drew wills


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] uPortal 4.2 release CODE FREEZE is over!

[Drew Wills]

Folks,

The uPortal 4.2 release has been cut, tags pushed, artifacts on their way to 
Maven Central.

The code freeze is over.

I’ll organize an announcement email shortly.

drew

> On Apr 24, 2015, at 6:08 AM, Tim Levett  wrote:
> 
> Best of luck! Exciting to get a patch out the door. :)
> 
> Tim Levett
> tim.lev...@wisc.edu
> MyUW-Infrastructure
> https://calendar.wisc.edu/share/u/tim.lev...@wisc.edu/dr(-14,30)
> 
> 
> 
> From: bounce-40956116-70367...@lists.wisc.edu 
>  on behalf of Drew Wills 
> 
> Sent: Thursday, April 23, 2015 5:05 PM
> To: uportal-dev@lists.ja-sig.org
> Subject: [uportal-dev] uPortal 4.2 release CODE FREEZE please
> 
> Folks,
> 
> In accordance with our community plans — and in the absence of objections — 
> I’d like to go ahead and call for a CODE FREEZE while I release uPortal 4.2.
> 
> I hope to complete this process tomorrow.
> 
> drew
> 
>> On Apr 22, 2015, at 9:21 AM, Drew Wills  wrote:
>> 
>> Folks,
>> 
>> I’m aiming to cut a uPortal 4.2 this week.  There’s nothing game-changing in 
>> master vs 4.1, but are a good number of innovations committed (that are not 
>> in the 4.1 line) and a fresh minor release will set us up well for the 
>> upcoming conference & community call.
>> 
>> Please send any objections and/or insights you may have related to this move.
>> 
>> drew
>> --
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> awi...@unicon.net
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>> 
> 
> 
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> tim.lev...@wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] uPortal 4.2 release CODE FREEZE please

[Drew Wills]

Folks,

In accordance with our community plans — and in the absence of objections — I’d 
like to go ahead and call for a CODE FREEZE while I release uPortal 4.2.

I hope to complete this process tomorrow.

drew

> On Apr 22, 2015, at 9:21 AM, Drew Wills  wrote:
> 
> Folks,
> 
> I’m aiming to cut a uPortal 4.2 this week.  There’s nothing game-changing in 
> master vs 4.1, but are a good number of innovations committed (that are not 
> in the 4.1 line) and a fresh minor release will set us up well for the 
> upcoming conference & community call.
> 
> Please send any objections and/or insights you may have related to this move.
> 
> drew
> -- 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Looking to cut a 4.2 release this week

[Drew Wills]

Folks,

I’m aiming to cut a uPortal 4.2 this week.  There’s nothing game-changing in 
master vs 4.1, but are a good number of innovations committed (that are not in 
the 4.1 line) and a fresh minor release will set us up well for the upcoming 
conference & community call.

Please send any objections and/or insights you may have related to this move.

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Initial research on uPortal 4.2.0 using Java 8

[Drew Wills]

James et al.,

> On Jan 29, 2015, at 1:59 PM, James Wennmacher  wrote:
> 
> the portlets generally must be compiled to Java 6 to be backwards compatible 
> with uPortal 4.0.x [4].

They have to be compiled to Java 6 to be compatible with uP 4.0 _on Java 6_.  
IIRC, running uP 4.0 on Java 7 is supported as well, so you could actually run 
a Java 7 portlet on uP 4.0 if you like.

And as we advance the platform to newer versions of Java, I should think the 
portlets are free to follow suit as soon as the opportunity permits.  This who 
want updates to their Java 6 portlets running in their Java 6 JVM can still 
have them — they just need to obtain a new patch release on the line they’re 
already on.  We won’t shift required JVM version in a patch release.

drew



-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Register Portlet Makeover

[Drew Wills]

On Nov 17, 2014, at 10:34 AM, Andrew Petro  wrote:

> I suggest *not* defaulting category and group selections.  
> Fail closed rather than failing open.  Accidentally *not* putting a portlet 
> into a category and *not* making groups of users able to use it has a worst 
> case of the newly published content not being available as one would like -- 
> and that issue can be mitigated by making the portlet publication UI more 
> helpful [1].  However, accidentally publishing a portlet such that anyone can 
> use it and anyone can readily find it in the customize drawer, well, if the 
> portlet relied upon the framework providing coarse-grained access control, 
> that's an opportunity to have a security incident.  

This nuancing of the original proposal sounds very reasonable.

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] How do we feel about ending support for Universality/mUniversality?

[Drew Wills]

Should these themes be removed in 4.2 (or 4.3, 5.0, etc.), or should we retain 
support for them indefinitely?

I’m inclined to believe we should remove them at some point, I’m just not sure 
of the right moment.  It’s a bandwidth drag to maintain them, and they’re 
enough long-in-the-tooth that I don’t see anyone innovating on them.

Thoughts?

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Josh Helmer for uPortal Committer

[Drew Wills]

That’s more than three +1 votes and zero -1 votes… welcome Josh Helmer!

drew


On Nov 7, 2014, at 9:29 AM, Drew Wills  wrote:

> Folks,
> 
> I want to nominate Josh Helmer as a uPortal committer.  Many of you know him 
> already — he’s been pitching in with a lot of the recent community-focused 
> development at Unicon.  He has submitted several pull requests.  He already 
> has 45 commits applied to master…
> 
>   - https://github.com/Jasig/uPortal/graphs/contributors
> 
> He has opened tickets and added valuable comments in JIRA too…
> 
>   - https://issues.jasig.org/secure/ViewProfile.jspa?name=jhelmer
> 
> He has also added documentation to the wiki…
> 
>   - https://wiki.jasig.org/pages/viewpage.action?pageId=67928268
> 
> drew
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Moving away from Ant/Maven to Gradle

[Drew Wills]

Misagh,

I pushed my Gradle work here:

  - 
https://github.com/drewwills/uPortal/commit/c445d85a0f0a4e105791fd5f2bcf567153675f70

There’s not much of it — it doesn’t complete a build of anything yet.

IIRC, I was at the point where I needed to find some sort of jaxb plugin for 
generating some classes from a schema.

drew


On Nov 7, 2014, at 10:23 AM, Misagh Moayyed  wrote:

> Drew,
>  
> Do you have your changes by any chances stashed into a separate topic branch 
> somewhere I could review and get started with? I have got a baseline myself 
> (having converted the CAS build to Gradle as a starting point)  and would 
> like to see what other progress I can make based your changes and others 
> before digging any deeper. One of the more challenging bits of this 
> conversion seems to be Gradle’s lacking of an overlay concept but I know 
> there are plugins out there, and Unicon actually put together one as well 
> that seems to do the job. That would be the first leg of the exploration.
>  
> Also I do suppose targeting this changeset for anything lower than 5.0 would 
> not be somewhat realistic, as of this writing and my other active engagements 
> counted, but if I manage to get something working (with all the help I can 
> get from others in the community) before 5  is out, that would surely be 
> better (although at this point somewhat miraculous).
>  
>  
> From: bounce-37555018-57692...@lists.wisc.edu 
> [mailto:bounce-37555018-57692...@lists.wisc.edu] On Behalf Of Drew Wills
> Sent: Friday, November 7, 2014 10:07 AM
> To: uportal-dev@lists.ja-sig.org
> Subject: Re: [uportal-dev] Moving away from Ant/Maven to Gradle
>  
> Misagh,
>  
> On Nov 7, 2014, at 9:01 AM, Misagh Moayyed  wrote:
> 
> 
> So questions are:
> 
> 1.  How do others feel about this build tool and the approach?
> 
> I am very much in favor of a serious exploration of Gradle as a the (one and 
> only) build tool for uPortal.
>  
>   - It *does* appear to support scripting arbitrary behavior much better than 
> Maven and even Ant
>   - Cris’ point about maybe we’re doing too much of that is very sensible, 
> but even if we make all the best moves, we may chose to do _some_ of that 
> sort of thing, particularly around portlets
>   - There is compelling evidence that Gradle may make the build much faster, 
> in addition to the scripting benefits
> 
> 2.  Has anybody begun working on the same proposal locally perhaps?
> 
> I have, though I had to set it aside.
> 
> 3.  What uPortal release should this be targeted to? I’d assume 5.0 as 
> this would be a pretty big change both in scope and the effort/time required 
> to implement this.
> 
> It's a uPortal 5 thing, as I understand it, though I’m open-minded.
>  
> drew
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> mmoay...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Moving away from Ant/Maven to Gradle

[Drew Wills]

Misagh,

On Nov 7, 2014, at 9:01 AM, Misagh Moayyed  wrote:

> So questions are:
> 
> 1.  How do others feel about this build tool and the approach?
> 
I am very much in favor of a serious exploration of Gradle as a the (one and 
only) build tool for uPortal.

  - It *does* appear to support scripting arbitrary behavior much better than 
Maven and even Ant
  - Cris’ point about maybe we’re doing too much of that is very sensible, but 
even if we make all the best moves, we may chose to do _some_ of that sort of 
thing, particularly around portlets
  - There is compelling evidence that Gradle may make the build much faster, in 
addition to the scripting benefits
> 2.  Has anybody begun working on the same proposal locally perhaps?
> 
I have, though I had to set it aside.
> 3.  What uPortal release should this be targeted to? I’d assume 5.0 as 
> this would be a pretty big change both in scope and the effort/time required 
> to implement this.
> 
It's a uPortal 5 thing, as I understand it, though I’m open-minded.

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Josh Helmer for uPortal Committer

[Drew Wills]

+1

drew


On Nov 7, 2014, at 9:29 AM, Drew Wills  wrote:

> Folks,
> 
> I want to nominate Josh Helmer as a uPortal committer.  Many of you know him 
> already — he’s been pitching in with a lot of the recent community-focused 
> development at Unicon.  He has submitted several pull requests.  He already 
> has 45 commits applied to master…
> 
>   - https://github.com/Jasig/uPortal/graphs/contributors
> 
> He has opened tickets and added valuable comments in JIRA too…
> 
>   - https://issues.jasig.org/secure/ViewProfile.jspa?name=jhelmer
> 
> He has also added documentation to the wiki…
> 
>   - https://wiki.jasig.org/pages/viewpage.action?pageId=67928268
> 
> drew
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Josh Helmer for uPortal Committer

[Drew Wills]

Folks,

I want to nominate Josh Helmer as a uPortal committer.  Many of you know him 
already — he’s been pitching in with a lot of the recent community-focused 
development at Unicon.  He has submitted several pull requests.  He already has 
45 commits applied to master…

  - https://github.com/Jasig/uPortal/graphs/contributors

He has opened tickets and added valuable comments in JIRA too…

  - https://issues.jasig.org/secure/ViewProfile.jspa?name=jhelmer

He has also added documentation to the wiki…

  - https://wiki.jasig.org/pages/viewpage.action?pageId=67928268

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] uPortal 4.1.2 now available

[Drew Wills]

Folks,

The newest uPortal release — version 4.1.2 — is now tagged in GitHub & 
available.

This version of uPortal is a maintenance/bug-fix release of the 4.1 minor 
version.  It corrects some build issues, some potential Javascript issues, some 
visual issues in admin UIs, and improves some caching behavior.
See also

The 4.1.2 wiki page, which includes macros listing known defects in this 
release and the issues resolved for this release.
Notable fixes in this release

Additional improvements to ant build issues with downloaded artifacts having 
301 Moved Permanently html content
Implement effective caching for Marketplace entities
Fix for Google Analytics CONFIG mode
Contributors

The following people contributed updates to this release
James Wennmacher
Josh Helmer
Tim Vertein
Anthony Colebourne
Jodie Muramoto
Drew Wills
All the best,

drew wills
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] code freeze for rel-4-1-patches is over

[Drew Wills]

Folks,

The uportal-4.1.2 tag is made and the release is being finalized — code freeze 
over.

drew


On Oct 27, 2014, at 8:52 AM, Drew Wills  wrote:

> I’d like to call a code freeze on the rel-4-1-patches patches branch (for the 
> next couple days, I hope), while I work through a uP 4.1.2 release.
> 
> drew
> 
> 
> On Oct 21, 2014, at 2:55 PM, Andrew Petro  wrote:
> 
>> DW> Is anyone working on something that will go into the 4.1.x line?
>> 
>> It would be nice to fix the over-eager discarding of layout customizations 
>> under profile switching ( UP-4272 ), since that is a trip hazard for folks 
>> trying to do non-big-bang migrations to respondr, but I wouldn't want the uP 
>> 4.1.2 release held up for it.
>> 
>> I'm *not* working on UP-4272, in part because it happens not to actually 
>> affect MyUW because of the way the new bucky theme and old themes render 
>> exclusive folder types and so a fine local workaround for us is to include 
>> all the Fragments all the time regardless of profile, and since they're 
>> always included in the layout, DLM thinks any layout customizations are 
>> applicable and doesn't delete them.
>> 
>> 
>> 
>> 
>> https://issues.jasig.org/browse/UP-4272
>> 
>> On Mon, Oct 20, 2014 at 2:09 PM, Andrew Petro  wrote:
>> DW> Is it a good time to work on a release?
>> 
>> Yes.
>> 
>> On Mon, Oct 20, 2014 at 12:24 PM, Drew Wills  wrote:
>> > Folks,
>> >
>> > It’s been almost 2 months since the release of 4.1.1.
>> >
>> > There have been 21 non-merge commits to eel-4-1-patches sense then:
>> > https://github.com/Jasig/uPortal/commits/rel-4-1-patches  (Also a review of
>> > master may yield additional commits that meet the patch release criteria.)
>> >
>> > Is it a good time to work on a release?  Is anyone working on something 
>> > that
>> > will go into the 4.1.x line?
>> >
>> > drew
>> >
>> > --
>> >
>> > You are currently subscribed to uportal-dev@lists.ja-sig.org as:
>> > apetro.li...@gmail.com
>> > To unsubscribe, change settings or access archives, see
>> > http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>> 
>> -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> awi...@unicon.net
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Releasing 4.1.2 -- code freeze rel-4-1-patches

[Drew Wills]

I’d like to call a code freeze on the rel-4-1-patches patches branch (for the 
next couple days, I hope), while I work through a uP 4.1.2 release.

drew


On Oct 21, 2014, at 2:55 PM, Andrew Petro  wrote:

> DW> Is anyone working on something that will go into the 4.1.x line?
> 
> It would be nice to fix the over-eager discarding of layout customizations 
> under profile switching ( UP-4272 ), since that is a trip hazard for folks 
> trying to do non-big-bang migrations to respondr, but I wouldn't want the uP 
> 4.1.2 release held up for it.
> 
> I'm *not* working on UP-4272, in part because it happens not to actually 
> affect MyUW because of the way the new bucky theme and old themes render 
> exclusive folder types and so a fine local workaround for us is to include 
> all the Fragments all the time regardless of profile, and since they're 
> always included in the layout, DLM thinks any layout customizations are 
> applicable and doesn't delete them.
> 
> 
> 
> 
> https://issues.jasig.org/browse/UP-4272
> 
> On Mon, Oct 20, 2014 at 2:09 PM, Andrew Petro  wrote:
> DW> Is it a good time to work on a release?
> 
> Yes.
> 
> On Mon, Oct 20, 2014 at 12:24 PM, Drew Wills  wrote:
> > Folks,
> >
> > It’s been almost 2 months since the release of 4.1.1.
> >
> > There have been 21 non-merge commits to eel-4-1-patches sense then:
> > https://github.com/Jasig/uPortal/commits/rel-4-1-patches  (Also a review of
> > master may yield additional commits that meet the patch release criteria.)
> >
> > Is it a good time to work on a release?  Is anyone working on something that
> > will go into the 4.1.x line?
> >
> > drew
> >
> > --
> >
> > You are currently subscribed to uportal-dev@lists.ja-sig.org as:
> > apetro.li...@gmail.com
> > To unsubscribe, change settings or access archives, see
> > http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal build steals focus

[Drew Wills]

The same thing happens to me — I’m not sure how to stop it.

drew


On Oct 27, 2014, at 8:11 AM, Andrew Petro  wrote:

> uPortal developers,
> 
> At some point the uPortal build started stealing focus on my Mac.
> 
> You know the drill.  `ant deploy-war`.  That sucker takes 2 minutes and 36 
> seconds, without the "clean".
> 
> Rather than sit on my hands, I figure that's just long enough to edit a few 
> words in the Draft buffer I have open for the Pull Request description that 
> will eventually accompany the changeset I'm testing.
> 
> Except there I am typing along and something in the build process steals 
> focus, a couple times actually, during that two minutes.
> 
> In general, I don't often appreciate anything stealing focus.
> 
> In specific, I *certainly* don't want a non-interactive command line build 
> process to steal focus.
> 
> Anyone know how to make it stop doing that?
> 
> Andrew
> 
>   
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Release 4.1.2?

[Drew Wills]

Folks,

It’s been almost 2 months since the release of 4.1.1.

There have been 21 non-merge commits to eel-4-1-patches sense then:  
https://github.com/Jasig/uPortal/commits/rel-4-1-patches  (Also a review of 
master may yield additional commits that meet the patch release criteria.)

Is it a good time to work on a release?  Is anyone working on something that 
will go into the 4.1.x line?

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal 4.1.0 release now available

[Drew Wills]

Yes — congratulations and well done!

drew


On Jul 16, 2014, at 12:13 PM, Jim Helwig  wrote:

> Well done, all!
> 
> On 7/16/14, 1:31 PM, Andrew Petro wrote:
>> uPortal developers,
>> 
>> It's finally done!
>> 
>> uPortal 4.1.0 is now available.
>> 
>> It is tagged in source control, there's a release page up on apereo.org , 
>> and there's binaries available for download from a GitHub release page.  The 
>> release is in process slurping into Maven Central.
>> 
>> https://wiki.jasig.org/display/UPC/4.1.0
>> 
>> https://github.com/Jasig/uPortal/releases/tag/uportal-4.1.0
>> 
>> http://www.apereo.org/uportal/download/uportal-4-1-0
>> 
>> 
>> Master is now un-frozen and free for development towards uPortal 4.2:
>> 
>> https://github.com/Jasig/uPortal/
>> 
>> and there's a new maintenance branch for patches for 4.1 towards 4.1.1:
>> 
>> https://github.com/Jasig/uPortal/tree/rel-4-1-patches
>> 
>> 4.1.0 is first and foremost a tremendous step forward.  uPortal now has a 
>> release defaulting to the Respondr responsive design theme, and pursuing 
>> responsive design together is really important to continuing to meet adopter 
>> expectations for compelling web portal experiences across devices.
>> 
>> Also, thanks are especially due to James Wennmacher for untangling the Maven 
>> dependency resolution issues into the final days of the release.  Those 
>> fixes made it into 4.1.0 and should make this release a lot more feasible to 
>> adopt and support in green field environments.
>> 
>> More generally, these developers contributed commits to this release:
>> 
>> Ludovic Auxepaules
>> Nicholas Blair
>> Vincent Bonamy
>> Jennifer Bourey
>> Raymond Bourges
>> Bill Brown
>> Shawn Connolly
>> Christian Cousquer
>> Eric Dalquist
>> Michael Gillian
>> Arvids Grabovskis
>> Aaron Grant
>> Julien Gribonvald
>> Peter Hart
>> Josh Helmer
>> Tim Levett
>> Jacob Lichner
>> Dan McCallum
>> Misagh Moayyed
>> Jodie Muramoto
>> Ross Nicoll
>> Chris Paraiso
>> Andrew Petro
>> Matt Polizzotti
>> Jeff Sittler
>> Paul Spaude
>> Steve Swinsburg
>> Gary Thompson
>> Tim Vertein
>> Chris Waymire
>> James Wennmacher
>> Chris White
>> Drew Wills
>> 
>> 
>> Finally, a special thanks to Ahad Zaman for providing downright intensive 
>> testing of master into the final days of the release.
>> 
>> So, well done!
>> 
>> uPortal 4.1.0 is also shipping with some known bugs and issues.  There's a 
>> macro in the release page that conveniently lists those in priority order.  
>> It would be a lovely thing to burn down that list through some early patch 
>> releases.
>> 
>> https://wiki.jasig.org/display/UPC/4.1.0​
>> 
>> I'd like to tentatively set the expectation that there will be a 4.1.1 patch 
>> release around August 15th, that is, a month out.  It certainly doesn't have 
>> to be me cutting that release at that time, but I think that's the right 
>> timeline to be thinking about.
>> 
>> Kind regards,
>> 
>> Andrew
>> 
>> 
>> 
>> 
>> From: Andrew Petro
>> Sent: Tuesday, July 15, 2014 4:20 AM
>> To: uportal-dev@lists.ja-sig.org
>> Subject: release notes for 4.1.0 release
>>  
>> Still tying off loose ends for the actual tag-and-release.
>> 
>> Release notes, which will be placed in the "Release" page in GitHub and 
>> linked from the wiki, are drafted here:
>> 
>> https://gist.github.com/apetro/c35b8891075af97a0b2b
>> ​
>> ​
>> From: Andrew Petro
>> Sent: Thursday, July 10, 2014 8:09 AM
>> To: uportal-dev@lists.ja-sig.org
>> Subject: RE: FREEZE master for 4.1.0 release
>>  
>> ​Status update on this:
>> 
>> Short version: Updated ETA for uPortal 4.1.0 is Monday July 14th.
>> 
>> You can most immediately help by grabbing this changeset, testing it, and 
>> reassuring all that it ought to be merged already thanks-very-much. : 
>> https://github.com/Jasig/uPortal/pull/378​ :  :)
>> 
>> Long version:
>> 
>> The good news is JIRA is now groomed to provide clearer reporting when you 
>> ask it questions about the uPortal 4.1.0 release (and the staged 4.1.0 
>> release notes page now embeds a couple of those queries) and human-readable 
>> narrative release notes are coming together.  uPortal 4.1.0 is a *huge* 
>> release in term

Re: [uportal-dev] "customize" and "add tabs" features no longer working

[Drew Wills]

Susan,

There was a bug — fixed late in the 4.1 cycle — where those 2 buttons appeared 
on the page in Focused Mode but didn’t work.  It was fixed before July 2nd, but 
perhaps there is some kind of tie-in.

Does this issue happen on every page?  Or just one page with some specific 
content on it?

drew

On Jul 14, 2014, at 11:57 AM, Susan McCarthy 
 wrote:

> Hi Andrew, 
> 
> I am using the Respondr theme and the error is apparently coming from 
> jquery-1.10.2.min.js line 3. I have not touched anything in any JavaScript 
> file so I do not know where to begin to fix this error. 
> 
> Thanks, 
> 
> Susan 
> 
> 
> On Mon, Jul 14, 2014 at 2:37 PM, Andrew Petro  wrote:
> ​Susan,
> 
> 
> 
> Which theme (Respondr? Universality?) are you observing this problem in?
> 
> 
> 
> Hypothesis: JavaScript errors are breaking those features.  JavaScript 
> console elucidating?
> 
> 
> 
> Kind regards,
> 
> 
> 
> Andrew
> 
> 
> 
> 
> 
> From: bounce-35694227-81063...@lists.wisc.edu 
>  on behalf of Susan McCarthy 
> 
> Sent: Monday, July 14, 2014 1:35 PM
> To: uportal-dev@lists.ja-sig.org
> Subject: [uportal-dev] "customize" and "add tabs" features no longer working
>  
> Hi, 
> 
> I am running uPortal 4.1 and I updated the code on July 2, 2014 and I am 
> running it on linux mint from firefox browser. I can no longer use the "add 
> tab" or "customize" features. Is this a problem with my build or because I am 
> running it on linux/ firefox? Any ideas? 
> 
> Thanks, 
> 
> Susan McCarthy 
> Manhattan College '15 
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> andrew.pe...@wisc.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> smccarthy02.stud...@manhattan.edu
> 
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Editing the Portlet XML Preferences Section in respondr theme

[Drew Wills]

Susan,

I suggest the command-line Import/Export tools:

  - https://wiki.jasig.org/display/UPM41/Import+Export+Data+Migration+Tools

drew


On Jul 10, 2014, at 7:45 AM, Susan McCarthy  
wrote:

> Hi, 
> 
> I chose type = image and since I am new to uPortal I did not realize there 
> were certain restrictions depending on the portlet type. I attempted to edit 
> preferences in the portlet.definition.xml file and I went to re-import the 
> file I was unable to successfully do this because none of the buttons would 
> work/ load. I am able to export and delete files perfectly...  
> 
> 
> On Thu, Jul 10, 2014 at 10:30 AM, Drew Wills  wrote:
> Susan,
> 
> Is the new portlet definition one of type=portlet?  (Which type did you 
> choose on the first screen?)
> 
> Portlets of type=portlet have section where you can “Add” new preference 
> names and tweak the values of preferences that have already been added.
> 
> Another alternative is to export the port let-definition.xml file and tweak 
> the preferences there, then re-import.
> 
> drew
> 
> 
> On Jul 10, 2014, at 7:26 AM, Susan McCarthy 
>  wrote:
> 
> >
> > Hi,
> >
> > I registered a new portlet from the admin UI and I want to edit the portlet 
> > XML Preferences section; however, it appears that if I want to edit this 
> > section I need to do it directly from the portlet-definition.xml file not 
> > from the admin UI. Is there something obvious I am not seeing?
> >
> > Thanks,
> >
> > Susan McCarthy
> > Manhattan College '15
> > --
> >
> > You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> > awi...@unicon.net
> > To unsubscribe, change settings or access archives, see 
> > http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> 
> --
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> smccarthy02.stud...@manhattan.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Editing the Portlet XML Preferences Section in respondr theme

[Drew Wills]

Susan,

Is the new portlet definition one of type=portlet?  (Which type did you choose 
on the first screen?)

Portlets of type=portlet have section where you can “Add” new preference names 
and tweak the values of preferences that have already been added.

Another alternative is to export the port let-definition.xml file and tweak the 
preferences there, then re-import.

drew


On Jul 10, 2014, at 7:26 AM, Susan McCarthy  
wrote:

> 
> Hi, 
> 
> I registered a new portlet from the admin UI and I want to edit the portlet 
> XML Preferences section; however, it appears that if I want to edit this 
> section I need to do it directly from the portlet-definition.xml file not 
> from the admin UI. Is there something obvious I am not seeing? 
> 
> Thanks, 
> 
> Susan McCarthy 
> Manhattan College '15 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] adding logo to header in respondr theme

[Drew Wills]

On Jul 8, 2014, at 10:03 AM, James Wennmacher  wrote:

> I updated 
> https://wiki.jasig.org/display/PLT/Jasig+Widget+Portlets+Configuration+and+Installation
>  with more detail.  Perhaps it will be more clear.

Thanks!

drew
-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] adding logo to header in respondr theme

[Drew Wills]

Susan,

IMHO you’re better off not messing with the source code (you shouldn’t need 
to).  The jasig-widget-portlets project is already a part of the uPortal 
distribution.

You can define that JSP name in the Portlet Manager.  Use the “Preferences” 
screen to set the value you want — ‘MCLogo'

drew


On Jul 8, 2014, at 9:23 AM, Susan McCarthy  
wrote:

> Hi, 
> 
> I followed the directions for option 1 and I am still having trouble. I 
> downloaded the JasigWidgetPortlets source code from gitHub and merged it into 
> my main uPortal directory. I added a custom JSP page to 
> uportal-portlets-overlay/src/main/webapp/WEB-INF/jsp just as the instructions 
> explained. I was not sure exactly what to do in regards to configuring the 
> SimpleJspPortletController.jspName portlet preference. I assumed I needed to 
> change a few lines in the file SimpleJspPortletController.java. I based my 
> changes off the instructions from this link 
> https://wiki.jasig.org/display/PLT/Portlet+Preferences. Currently, in the 
> .java file I changed  the line public static final String INSTRUCTIONS_VIEW = 
> "simple-jsp-instructions"; to  public static final String MCLOGO_VIEW = 
> "MCLogo"; since "MCLogo" is the name of the JSP page I added in the jsp 
> directory as I stated above. I also changed the line jspName = 
> prefs.getValue(JSP_NAME_PREFERENCE, INSTRUCTIONS_VIEW); to jspName = 
> prefs.getValue(JSP_NAME_PREFERENCE, MCLOGO_VIEW); . 
> 
> I was wondering if I needed to add the portlet to the portlet.xml file which 
> is located in /JasigWidgetPortlets/src/main/webapp/WEB-INF/ and after adding 
> it do I now go to the  respondr-lo.fragment-layout.xml file and replace 
> channel portal-logo with the portlet I created. After that should I be 
> manually adding a new file to the portlet-definition folder that looks 
> exactly like the portal-logo.portlet-definition.xml file but instead of 
> /SimpleContentPortlet it would be 
> /SimpleJSP and obviously the title and name 
> would be different. Also, should I be adding a PortletContext.xml file in  
> /JasigWidgetPortlet/src/main/webapp/WEB-INF/context/portlet/ . 
> 
> I apologize if this is confusing! 
> 
> Thanks in advance! 
> 
> Susan McCarthy
> Manhattan College '15
> 
> 
> On Thu, Jun 26, 2014 at 1:10 PM, James Wennmacher  
> wrote:
> There are two ways to do it.
> 
> 1. Replace the SimpleContentPortlet that is currently in the header-left 
> region with a SimpleJSP portlet from the Jasig Widgets Portlets (see 
> https://wiki.jasig.org/display/PLT/Jasig+Widget+Portlets+Configuration+and+Installation).
>   You'd need to modify the 
> uportal-war/src/main/data/quickstart-entities/fragment-layout/respondr-lo.fragment-layout.xml
>  to replace the channel portal-logo with the portlet you create (you can 
> create it in the UI using Manage Portlets and export the channel definition 
> and save it into the 
> uportal-war/src/main/data/quickstart-entities/portlet-definition folder).  
> This approach is easiest in terms of keeping it simple and not relying on any 
> data in the database.
> 
> 2. Using the SimpleContentPortlet that is already published, you can use its 
> WYSIWYG editor to upload the logo and include it in the portal-logo's 
> content.  This approach saves the logo in the attachments table in the 
> database.  There is currently not an easy way to move that data between 
> environments or to include it in an ant initportal so I generally recommend 
> approach #1.  However for simple experimentation on getting the logo on the 
> page, this way works.
> James Wennmacher - Unicon
> 480.558.2420
> On 06/26/2014 09:20 AM, Susan McCarthy wrote:
>> Hi, 
>> 
>> I am new to uPortal and I am experimenting with the new respondr theme. I 
>> would like to include a logo image instead of text in the header. Can 
>> someone point me in the right direction as to how to do this correctly. 
>> Thanks in advance! 
>> 
>> Susan McCarthy 
>> Manhattan College '15 
>> -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> jwennmac...@unicon.net
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> smccarthy02.stud...@manhattan.edu
> 
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] VOTE: Release uPortal 4.1.0

[Drew Wills]

+1

Welcome uPortal 4.1.

drew


On Jul 3, 2014, at 10:48 AM, James Wennmacher  wrote:

> +1, and yes let's keep the changes/pull-requests flowing ... :-)
> James Wennmacher - Unicon
> 480.558.2420
> On 07/03/2014 10:18 AM, Andrew Petro wrote:
>> uPortal developers,
>> 
>> +1 for release Jasig/uPortal/master as uPortal 4.1.0.
>> 
>> Per Apache guidelines, we need 3 binding +1s and majority to release 4.1.
>> 
>> If there seems to be sufficient consensus in time, I intend to release 
>> engineer a uPortal 4.1.0 release this holiday weekend; if there doesn't, 
>> I'll instead cut another RC and we can use that as a platform to get to 
>> 4.1.0 GA.
>> 
>> Kind regards,
>> 
>> Andrew
>> 
>> Apache voting guidelines: http://www.apache.org/foundation/voting.html​
>> 
>> From: bounce-35615826-81063...@lists.wisc.edu 
>>  on behalf of James 
>> Wennmacher
>> Sent: Tuesday, July 01, 2014 11:32 AM
>> To: uportal-dev@lists.ja-sig.org
>> Subject: Re: [uportal-dev] uPortal 4.1 release march
>>  
>> We (Drew, Eric G, I, and some others) were just talking yesterday about 
>> this.  We collectively agree there is no reason to wait at this point for 
>> any other changes.  We are ready for a 4.1.0 release.  If someone has time 
>> to pull in any of the existing pull requests that are worth while that is 
>> great, but I'd say let's cut and celebrate!
>> 
>> James Wennmacher - Unicon
>> 480.558.2420
>> On 07/01/2014 09:05 AM, Andrew Petro wrote:
>>> So, how about that uPortal 4.1 release?
>>> 
>>> All of the JIRA issues identified in James' email are marked resolved.
>>> 
>>> There are no "Blocker" issues tagged as affecting 4.1.0, though maybe this 
>>> one ought to be a "Blocker": https://issues.jasig.org/browse/UP-3935​ .  
>>> There are no unresolved "Blocker" issues tagged as fix-for 4.1.0.
>>> 
>>> So.  Anyone intend to fix something in `master` so important that it ought 
>>> to hold up releasing 4.1.0 ?  Or are we at that point where 4.1.0 GA ought 
>>> to be cut from master whenever release engineering bandwidth can be 
>>> mustered?
>>> 
>>> Kind regards,
>>> 
>>> Andrew
>>> 
>>> 
>>> From: bounce-35356638-81063...@lists.wisc.edu 
>>>  on behalf of James 
>>> Wennmacher
>>> Sent: Thursday, June 19, 2014 2:45 PM
>>> To: uportal-dev@lists.ja-sig.org
>>> Subject: Re: [uportal-dev] uPortal 4.1 release march
>>>  
>>> I suggest holding off for about two weeks.  We are tackling some issues for 
>>> some clients that are important enough to them that they want to hold up a 
>>> release for a fix.
>>> 
>>> Their issues are:
>>> - IE10 support (UP-4121, UP-4122, UP-4123)
>>> - Drag n drop portlets from customize (UP-4000)
>>> - hide add tab in maximized view (UP-4104)
>>> 
>>> I think these would benefit the broader community and might as well be in a 
>>> GA release.
>>> James Wennmacher - Unicon
>>> 480.558.2420
>>> On 06/19/2014 08:43 AM, Andrew Petro wrote:
 So, how about that uPortal 4.1 release?
 
 Anyone aware of defects in 4.1 RC2, unfixed on master, that are so 
 significant they ought to block a 4.1 GA release?
 
 There are no BLOCKER issues tagged as affecting 4.1.0:
 
 http://goo.gl/SV6mJV
 
 And there are no unresolved BLOCKER issues tagged as fix-for 4.1.0:
 
 http://goo.gl/4lxwND
 
 So.  Anyone intend to fix something soon in master so important it ought 
 to hold up 4.1.0?  Or are we at that post-conference point of good to cut 
 4.1.0 whenever release engineering attentions can be applied?
 
 
 
 
 
>>> 
>>> -- 
>>> 
>>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>>> jwennmac...@unicon.net
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>> 
>> -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> andrew.pe...@wisc.edu
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>> -- 
>> 
>> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
>> jwennmac...@unicon.net
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
> 
> -- 
> 
> You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
> awi...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency

[Drew Wills]

On 06/17/2014 09:56 AM, Joe Novalany wrote:

Any luck fixing this issue? My university has begun investigating an upgrade
to 4.1 and it's preventing me from successfully building.



I received some new insights/information this morning that may help me 
fix it.


  - 
https://github.com/Jasig/uPortal/commit/1f415eaecd5edebec40639c4e0198800fed31abb


drew


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency

[Drew Wills]

Folks,

I'm encountering a new Maven dependency issue with echcache.  It seems 
to happen always (small sample size) on a machine that doesn't have 
these artifacts cached in the local repo.


These items do seem to be in m2 central.  I'm not sure how Maven is 
getting the 'null:ehcache-web:jar:null' (see below) but I suspect it's a 
factor in the issue.


drew

---

BUILD FAILED
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:635: The following 
error occurred while executing this line:
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1437: The following 
error occurred while executing this line:
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1372: The following 
error occurred while executing this line:
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1315: The following 
error occurred while executing this line:
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1318: The following 
error occurred while executing this line:
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1375: The following 
error occurred while executing this line:
/home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1227: Unable to 
resolve artifact: Unable to get dependency information: Unable to read 
the metadata file for artifact 'net.sf.ehcache:ehcache-web:jar': Cannot 
find parent: net.sf.ehcache:ehcache-web-parent for project: 
null:ehcache-web:jar:null for project null:ehcache-web:jar:null

  net.sf.ehcache:ehcache-web:jar:2.0.4

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  sonatype-nexus-snapshots 
(https://oss.sonatype.org/content/repositories/snapshots),

  apache-snapshots (http://repository.apache.org/snapshots)

Path to dependency:
1) org.jasig.portal:uportal-war:war:4.1.0-SNAPSHOT
2) org.jasig.resourceserver:resource-server-utils:jar:1.0.38

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] jQuery not being detected when using Bootstrap

[Drew Wills]

Steven,

Can you share the JSP source?

drew

On 05/15/2014 12:59 PM, Steven Wiggins wrote:

Sorry about that. Hit enter a little too early.

I am working on adding Bootstrap to a portlet of ours. It should be
noted that I'm not developing on top of Respondr. Using the resource
server, I'm importing everything I need to use Bootstrap (i.e. jQuery,
bootstrap.css, bootstrap-theme.css and bootstrap.js). I can tell that
the Bootstrap css is being imported as the it is applied to my portlet.
I can also see the jQuery working when the portlet is not in a maximized
state on a tab. When the portlet is maximized, my jQuery instance is not
recognized. When viewing the source, I can see that there is a
syntactically correct import statement for jQuery and that the source
for jQuery is there. Whenever I access jQuery via $ or something
similar, the console states 'undefined is not a function.' Importing
jQuery manually directly from the jQuery website (i.e. http://code.jquery.com/jquery-1.9.0.js";>) everything works
perfectly.

What exactly is going on?

Any help is appreciated.

Thanks,
Steven Wiggins
Oakland University


On Thu, May 15, 2014 at 3:48 PM, Steven Wiggins mailto:scwig...@oakland.edu>> wrote:

Hey everyone,


--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Post-conference collaboration

[Drew Wills]

Tim,

I'm 100% game for improving the UI-based management features in uPortal. 
 I agree that there's plenty of room for growth, and that these 
features would be a significant benefit for driving platform adoption.


At the same time, I never want to loose the ability to check all my 
configuration, design, and content choices into Git for a 100% 
repeatable, single shell-based command, completely-from-scratch build 
(and promotion to prod) process.  I would prefer not to go in a 
direction where keeping several deployments up to date means repeating a 
bunch of manual steps.


I'm happy to further this discussion in the dev days and throughout the 
conference (or really any time).  :)


drew

On 05/09/2014 07:41 AM, Tim Raymond wrote:

I will be there... hoping for a seat at the adults table :-)

I have added the following to the document on a separate page in case this is 
not the appropriate forum for my thoughts. My page could then be easily deleted.

Is there a current strategy document or "guiding principles" for the project? 
If not are such things a good idea? I am looking at this from a VERY big picture 
perspective.
As a new adopter, most of my focus is on the barrier to adoption of uPortal, 
both from the documentation (I know Laura is updating that) and use 
perspectives.
The platform is powerful, but (IMHO) unless or until more can be done through 
an online interface (no xml config/import required), we will never breakout 
into larger adoption. Imagine how awesome it would be to have the ability to 
create a new layout, with an interface that allows the admin to drag and drop 
any portlet into ANY region, and define the page and region properties all 
though their browser, no XML required! Maybe this touches on Andrew's point 
about beyond DLM?

I like to think about Wordpress as an example. From a Wordpress adopter 
standpoint, files very rarely (if ever) need to be touched. Aside from rare use 
cases, the entire system can be configured, extended, and administered through 
an online interface.
I received a direct email from someone at another institution that was 
evaluating uPortal at the same time we were... they chose to use Wordpress 
instead and tried to convince me we should too. I was not swayed to the dark 
side, but his argument is a compelling one for potential adopters. If the 
platform does not evolve into a more user friendly format, a format that people 
expect in today's web environment, it will at best maintain current adoption 
rates, and at worst see adoption erode.

Tim Raymond
Director, Central Applications
Instructional and Information Technology
California State Polytechnic University, Pomona
Phone: 909.869.6851
Cell: 909.260.3200
Fax: 909.979.6406

PGP Public Key: 
https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x2FDBD1EADDC19329

-Original Message-
From: bounce-35088618-81920...@lists.wisc.edu 
[mailto:bounce-35088618-81920...@lists.wisc.edu] On Behalf Of Andrew Petro
Sent: Friday, May 9, 2014 6:29 AM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Post-conference collaboration

Worth using a Google Doc to organize who's there when and what to discuss/work 
on?

https://docs.google.com/a/apereo.org/document/d/1cTErN-DwtILPv8L2jlhIzIlUEjMv7FgIhDAFaUBEgYE/edit#

Anyone with the link can edit that, but better if you log in!

Andrew


On 5/9/14, 8:14 AM, Drew Wills wrote:

I believe I will be there.

drew

On 05/09/2014 05:14 AM, Jim Helwig wrote:

Who is planning on remaining in Miami on the Thursday following the
conference for additional collaboration time?

Thoughts on topics to focus post-conference collaborative development
and/or discussion around?

JimH






--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
tjraym...@csupomona.edu To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Post-conference collaboration

[Drew Wills]

I believe I will be there.

drew

On 05/09/2014 05:14 AM, Jim Helwig wrote:

Who is planning on remaining in Miami on the Thursday following the
conference for additional collaboration time?

Thoughts on topics to focus post-conference collaborative development
and/or discussion around?

JimH



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Proposal to use full-width Respondr theme in 4.1

[Drew Wills]

I am okay with the proposal.

FWIW I had previously been thinking we should talk about either going 
this direction or at least widening the fixed width.


drew

On 05/07/2014 10:42 AM, James Wennmacher wrote:

Hi,

I propose that we change the Respondr theme to be fluid width (e.g. full
width) instead of the fixed-width format where Bootstrap have a
fixed-width for the rows and centers the content in the viewport for
devices >= 768px (see http://getbootstrap.com/css/#grid). We can
consider asking the uportal-user community, but from talking to a few
people it seems there was not a strong design decision to limit the
viewing to the fixed-widths.  I
personally have found it annoying and limiting.  Bootstrap's main site
uses fixed-width and so do many other bootstrap sites, but I'm told many
other bootstrap sites do not.

Advantages of full width:

  * Can display more information wider, especially with the
preponderance of wide-screen monitors where height is often limited
so you do more vertical scrolling.
  * With Bootstrap's general tendency to make items bigger so they are
more easily accessed by a finger on a mobile device, on a desktop
and some landscape-oriented tablets it would be helpful to have the
greater width to display content since you typically have 2 or more
columns.
  * Puts Respondr on-par with Universality in this aspect.

Disadvantages of full width:

  * If you are restricted to widths of <750px, 750px, 970px, and 1170px
it makes testing easier since you don't have to figure out how to
handle widths outside that restricted set.

To use full width is actually very easy.  We replace the class
'container' with 'container-fluid' on the markup generated by the XSL.
We could make it fairly easy to configure in the XSL with a default of
full width.

Thoughts?

--
James Wennmacher - Unicon
480.558.2420

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal 4.1 RC1 soon

[Drew Wills]

On 05/07/2014 08:57 AM, Tim Levett wrote:

Many thanks to all that are involved, this is very exciting!


Yes it is!

I can't wait to show all the cool new stuff off at Open Apereo.

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Nice work on Portlet Marketplace

[Drew Wills]

Glad to hear it.  Turns out we probably need it too, near-term.

drew

On 04/22/2014 12:18 PM, Andrew Petro wrote:

AP> inventing a ... permission activity ... to see an entry for any
given portlet in the marketplace.

Now a Pull Request.

https://github.com/Jasig/uPortal/pull/305

(Named the permission "BROWSE" rather than "VIEW_MARKETPLACE_ENTRY".)



On 4/18/14, 12:12 PM, Drew Wills wrote:

On 04/17/2014 06:46 PM, Andrew Petro wrote:

I agree we need to do something to hide some portlet marketplace entries
from non-admins.

I really like the idea of inventing a VIEW_MARKETPLACE_ENTRY permission
activity that one can be granted targeting portlets (or portlet
categories, of course), requiring VIEW_MARKETPLACE_ENTRY or MANAGE
permission to see an entry for any given portlet in the marketplace.


I can work with this vision.

drew






--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal 4.1 release march

[Drew Wills]

On 04/21/2014 07:34 AM, Andrew Petro wrote:

Public branch to start getting multiple eyeballs on it before it reaches
Pull Request stage?


I'm not opposed, but in my experience a pull request is the best way to 
get eyes on it.  We could make a note:  DO NOT MERGE UNTIL XXYY DATE FOR 
REVIEW & UPDATES.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Nice work on Portlet Marketplace

[Drew Wills]

On 04/17/2014 06:46 PM, Andrew Petro wrote:

I agree we need to do something to hide some portlet marketplace entries
from non-admins.

I really like the idea of inventing a VIEW_MARKETPLACE_ENTRY permission
activity that one can be granted targeting portlets (or portlet
categories, of course), requiring VIEW_MARKETPLACE_ENTRY or MANAGE
permission to see an entry for any given portlet in the marketplace.


I can work with this vision.

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Nice work on Portlet Marketplace

[Drew Wills]

I'm looking at the Portlet Marketplace in a local dev environment today, 
now that it's in the master branch -- nice work!


One item of feedback:  I think it really should honor the feature 
whereby non-categorized portlets are hidden from browsing and direct access.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal 4.1 release march

[Drew Wills]

On 04/17/2014 01:22 PM, Andrew Petro wrote:


Who's got in flight features that they desperately want included in 4.1
such that it's worth further delay before feature freeze and squishing?
Or are we all on board for this?


I would love to get the Tenant Manager/Milti-Tenancy stuff sponsored by 
IlliniCloud in.


It's...

  - Non-invasive;  use of it is completely optional, and adding it 
doesn't change existing components

  - Pretty well baked at this point

I'd like to organize a pull request for it asap.

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Making uPortal skins dynamic rather than static

[Drew Wills]

ESS in css3patterns:
https://github.com/LeaVerou/css3patterns/issues/6

[1]: Cf. Atwood's Law.
http://blog.codinghorror.com/the-principle-of-least-power/


On 3/3/14, 12:07 PM, Andrew Petro wrote:

James, Drew, others,

Thanks for the conference call just now.  Here's some of what's in my
brain coming out of it:

* Importance of the new dynamic skin features being optional,
traditional crafted skinning working, it being apparent and
straightforward how to drop the skin manager portlet from an
implementation and yet have skinning work properly.

* Relatedly, opportunity in getting more careful about what goes in
"default" vs what goes in "quickstart" namespaced entity files, with
a goal of it being possible to init a portal with just the "required"
and "default" entities and thereby get that mythical "empty portal"
on which to build.  "quickstart" as the thing you want to demo, want
to jump into to understand the potential, but zapping to zero the
contents of the quickstart directory as a plausible way to go about
building a for real uPortal implementation and, for upgrades, an
ability to focus on what changed in required and default and ignore
what's in quickstart except to the extent that you want the features
or have already adopted those features and need to understand how
they've then changed.

* Opportunities in multi-tenant more generally, and value for
single-tenant adopters of some of the multi-tenant features in that
that single tenant might still be a tenant worth managing.
Opportunity in aligning ideas like this:
https://wiki.jasig.org/display/~levett/System+Feature+Configuration
with the scripted/templated tenant generation that Drew Wills et al.
have been exploring.

* Tactical followup on the code details of the pending dynamic skins
pull request, with gratitude to Misagh Moayyed and others for review.

Others on the call, or even not on the call, please add your thoughts
too, and then some of this needs tracking to completion...

Andrew



On 02/28/2014 02:03 PM, James Wennmacher wrote:

I've really appreciated all the comments on the pull request and
additional ideas.  I'm excited to see the energy this feature
enhancement is generating.

I wrote up a brief overview of the big picture that drove the
current design approach at
https://wiki.jasig.org/display/UPC/Skin+Manager+and+Dynamic+Skins+for+Respondr.
The intent is that this feature enhancement provide a base of a
small, but helpful push toward a more dynamic skin management
feature for both non-tenant and tenant scenarios, recognizing that
there is much room for enhancement to the current feature needs.

Andrew P I like the dream you outlined below.  It is more along the
lines of the dynamic capabilities of Drupal and other dynamic
management systems.  In writing up the big picture above I am
rethinking the idea of storing the skin files on the file system vs.
storing them in the database, or perhaps a hybrid approach might be
better of compiling them once and storing them in the database, and
hydrating them onto the file system as needed similar to the way
attachments works.
James Wennmacher - Unicon
480.558.2420
On 02/28/2014 10:00 AM, Andrew Petro wrote:

I had a dream about making uPortal skins more dynamic last night
[1], prompted by this feature branch and pull request.

https://github.com/jameswennmacher/uPortal/tree/UP-3940

https://github.com/Jasig/uPortal/pull/239


I'm eager to have a conversation about the big picture.

So.  Here's what I hope is the best next nudge I can give this:

# A couple of motivating user stories: [2]

## 0. Many more skins

As a portal service owner I would like to be able to offer and
manage hundreds of (slightly different) skins rather than just one
or a few.

The bigger picture context here is supporting massively more
multi-tenant uPortal.  That entails, among I imagine many other
considerations, supporting potentially hundreds of skins rather
than the one or a handful that are currently typical in uPortal
adoptions.

## 1. Editing a skin live via admin UI in portal

As a user with privileges over some skins, I would like to be able
to edit those skins live in the portal via a friendly UI rather
than having to edit raw source code (text editors?! Ew!) and run it
through a build process (Ant that invokes Maven that invokes a Ruby
gem? Ew!).  I would like immediate visual feedback about what my
changed skin feels like.

## 2. Skin edited in live portal takes effect immediately

As a portal service owner I would like the live edits to skins to
take effect immediately-ish.  That doesn't necessarily mean having
to tickle active end-user uPortal sessions with changed skins, but
it does mean I don't want to have to restart the servlet container
to pick up a skin tweak.

# Some background:

uPortal has Skins.  Users can pick among them in the Customize
Drawer in Universality and I imagine they&

Re: [uportal-dev] Portal Activity Portlet, Statistics stopped working a while ago

[Drew Wills]

On 03/24/2014 03:43 PM, Cindy Duggan wrote:

The suddenly - a few months ago - the Portlet was no longer displaying
anything.


Cindy,

Do you mean it displays nothing at all?  Or zeroes?

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Ant version for uPortal 4.1

[Drew Wills]

In the past, we've seen it happen that some patch releases would work 
but others wouldn't.  For example, 1.8.2 would work, but 1.8.3 might not.


drew

On 03/21/2014 09:03 AM, Andrew Petro wrote:

Emmett,

Thanks for working on this.  Shaking that Ant 1.8.2 dependency and
moving on to a later Ant would be great.


On what the antversion task supports


Yes, the `` task supports an `atleast` attribute in place
of `exactly`.

https://ant.apache.org/manual/Tasks/antversion.html


On where to find Ant documentation
---

https://ant.apache.org/


On defining successful ant build
---

If `ant clean initportal` successfully goes from zero to deployed to
Tomcat, with the database appropriately loaded, that sounds like success.


Kind regards,

Andrew



On 3/21/14, 10:50 AM, Emmett Culley wrote:

I am successfully building uPortal using ant 1.9.2.  To do that I
needed to modify the bootstrap/build_includes.xml file to allow
building with that version.  I have three questions

1)
Is it possible to have the antversion tag specify a "greater than or
equal" attribute, instead of "exactly"?



to something like:



2)
I suppose there is some documentation on build_includes.xml tags and
their attributes.  None of the XSD files in the project refer to
antversion.  Where can I find either generic ant build XML file
documentation or uPortal specific ant build XML file documentation, or
both?

3)
How can I verify that using ant 1.9.2 actually builds correctly? Is it
enough that the build is successful and uPortal loads and functions.

Emmett






--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] 4.1.0-M1 Released

[Drew Wills]

No questions -- just "woot!"

drew

On 03/20/2014 01:55 PM, Tim Levett wrote:

Milestone 1 of 4.1 has been released. Congratulations & thank you to
everyone who has contributed toward a responsive design and other great
features.

/Note:/ I am not going to mark the issues in Jira since this is not an
official release, but it is basically everything with version of 4.1
that is closed.

JQL query : project = uPortal AND fixVersion = 4.1.0 AND status in
(Resolved, Closed)

Please let us know if you have questions.

Thanks,

Tim Levett
lev...@wisc.edu



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] (temporarily) dropping Calendar Portlet from master

[Drew Wills]

On 03/13/2014 10:50 AM, Andrew Petro wrote:

Does this mean that the

 
 xalan
 serializer
 

in CalendarPortlet's pom.xml ought to be dropped?


Yes, I think so.  Afaik.

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] (temporarily) dropping Calendar Portlet from master

[Drew Wills]

Folks,

I believe issue with the (offline) builds.osafoundation.org repo is fixed.

  - https://issues.jasig.org/browse/UP-4024
  - 
https://github.com/Jasig/uPortal/commit/99851d10babb88e8c9c795faa959d327d08a9412


It turned out to be much less sinister than originally thought.

Yes, the xalan:serializer jar is natively hosted in a non-M2 Central 
repo that is currently defunct.


But...

  - Calendar doesn't actually appear to be using it;  and
  - uPortal was never getting its copy from there anyway

The copy of xalan:serializer that gets deployed with uPortal *actually 
does* come from M2 Central -- it's at 'WEB-INF/lib/serializer-2.7.1.jar' 
within the org.jasig.portlet:CalendarPortlet:war:2.1.3-M4 artifact. 
(Deep in the WAR it overlays.)


The build issue was owing to the following 
uportal-portlets-overlay/CalendarPortlet dependency (which pulls in the 
CalendarPortlet Java code in JAR form):



org.jasig.portlet
CalendarPortlet
${CalendarPortlet.version}
classes
jar
provided


Adding...



xalan
serializer



clears up the issue.

drew

On 03/11/2014 05:29 PM, Drew Wills wrote:

Thanks Tim.

Vicky was able to build today as well, on a new machine, by adding only
the 1 dependency.

But I also tried just removing the dependency that breaks the build --
xalan:serializer:2.7.0 -- and it succeeds!  It looks like that
dependency is no longer needed.

I can probably cut a new release tomorrow.

drew

On 03/11/2014 12:28 PM, Tim Raymond wrote:

Drew,
I'm not sure if this answers your question; I added the content of the
xalan dir from one box to my new local .m2 dir, and after doing so the
build worked.


Tim Raymond
Director, Central Applications
Instructional and Information Technologies
California State Polytechnic University, Pomona
Phone: 909.869.6851
Cell: 909.260.3200
Fax: 909.979.6406

PGP Public Key:
https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x2FDBD1EADDC19329




On 3/11/14, 11:04 AM, "Drew Wills"  wrote:


On 03/11/2014 10:37 AM, Andrew Petro wrote:

So, I still think the medium-term solution here is to step through this


https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifact

s+to+The+Central+Repository



+1 for this approach in the medium term.

For the long term, James submitted a ticket to the caldav4j project
requesting that they push to M2 central.  I think we should add our
voices to that -- and maybe help them somehow.

The only question is the short term.

I'd be delighted to work on the medium- or short-term solution, but I
can't promise that I will have the opportunity to do that between now
and any certain date.  (Are you available for that by chance?)

Pulling the Calendar may mean that it's not included in 4.1.  I don't
want to check the caldav4j jar into the git repo any more than you do,
but I think it's preferable to loosing the Calendar for the 4.1 release.

The Calendar is a useful function for the platform that helps us make
the case that the platform has features that you want.  Being bundled,
moreover, gets the Calendar in front of new people who way want to
enhance, document, beautify, or troubleshoot it.

Can anyone confirm or deny that the caldav4j jar is the only dependency
causing the the issue?

There is another approach we can take.  We could factor the caldav
support into a separate Maven sub-module and include it optionally -- in
other words, not include it with the overlay -- until we can organize
the medium- or long-term solution.

drew


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
tjraym...@csupomona.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev







--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] (temporarily) dropping Calendar Portlet from master

[Drew Wills]

Thanks Tim.

Vicky was able to build today as well, on a new machine, by adding only 
the 1 dependency.


But I also tried just removing the dependency that breaks the build -- 
xalan:serializer:2.7.0 -- and it succeeds!  It looks like that 
dependency is no longer needed.


I can probably cut a new release tomorrow.

drew

On 03/11/2014 12:28 PM, Tim Raymond wrote:

Drew,
I'm not sure if this answers your question; I added the content of the
xalan dir from one box to my new local .m2 dir, and after doing so the
build worked.


Tim Raymond
Director, Central Applications
Instructional and Information Technologies
California State Polytechnic University, Pomona
Phone: 909.869.6851
Cell: 909.260.3200
Fax: 909.979.6406

PGP Public Key:
https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x2FDBD1EADDC19329




On 3/11/14, 11:04 AM, "Drew Wills"  wrote:


On 03/11/2014 10:37 AM, Andrew Petro wrote:

So, I still think the medium-term solution here is to step through this


https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifact
s+to+The+Central+Repository



+1 for this approach in the medium term.

For the long term, James submitted a ticket to the caldav4j project
requesting that they push to M2 central.  I think we should add our
voices to that -- and maybe help them somehow.

The only question is the short term.

I'd be delighted to work on the medium- or short-term solution, but I
can't promise that I will have the opportunity to do that between now
and any certain date.  (Are you available for that by chance?)

Pulling the Calendar may mean that it's not included in 4.1.  I don't
want to check the caldav4j jar into the git repo any more than you do,
but I think it's preferable to loosing the Calendar for the 4.1 release.

The Calendar is a useful function for the platform that helps us make
the case that the platform has features that you want.  Being bundled,
moreover, gets the Calendar in front of new people who way want to
enhance, document, beautify, or troubleshoot it.

Can anyone confirm or deny that the caldav4j jar is the only dependency
causing the the issue?

There is another approach we can take.  We could factor the caldav
support into a separate Maven sub-module and include it optionally -- in
other words, not include it with the overlay -- until we can organize
the medium- or long-term solution.

drew


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
tjraym...@csupomona.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] (temporarily) dropping Calendar Portlet from master

[Drew Wills]

On 03/11/2014 10:37 AM, Andrew Petro wrote:

So, I still think the medium-term solution here is to step through this

https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository



+1 for this approach in the medium term.

For the long term, James submitted a ticket to the caldav4j project 
requesting that they push to M2 central.  I think we should add our 
voices to that -- and maybe help them somehow.


The only question is the short term.

I'd be delighted to work on the medium- or short-term solution, but I 
can't promise that I will have the opportunity to do that between now 
and any certain date.  (Are you available for that by chance?)


Pulling the Calendar may mean that it's not included in 4.1.  I don't 
want to check the caldav4j jar into the git repo any more than you do, 
but I think it's preferable to loosing the Calendar for the 4.1 release.


The Calendar is a useful function for the platform that helps us make 
the case that the platform has features that you want.  Being bundled, 
moreover, gets the Calendar in front of new people who way want to 
enhance, document, beautify, or troubleshoot it.


Can anyone confirm or deny that the caldav4j jar is the only dependency 
causing the the issue?


There is another approach we can take.  We could factor the caldav 
support into a separate Maven sub-module and include it optionally -- in 
other words, not include it with the overlay -- until we can organize 
the medium- or long-term solution.


drew


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] (temporarily) dropping Calendar Portlet from master

[Drew Wills]

Andrew,

I'd like to explore doing something like...


  caldav4j
  caldav4j
  1.0.0
  system
  ${project.basedir}/lib/caldav4j.jar


in the overlay.

drew

On 03/11/2014 07:30 AM, Andrew Petro wrote:

uPortal developers,

Thoughts on (temporarily) dropping the Calendar portlet outright from
master so as to un-break the uPortal build pending its inability to get
its dependencies from Central?

Pursuing in parallel getting those dependencies up as third-parties in
Central so the build un-breaks, at which point the portlet could return
to the quickstart?

I think it's the prudent move to minimize friction on other open
development loops.

Andrew





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] (temporarily) dropping Calendar Portlet from master

[Drew Wills]

How many dependencies is it?  Is it only caldav4j?

drew

On 03/11/2014 07:30 AM, Andrew Petro wrote:

uPortal developers,

Thoughts on (temporarily) dropping the Calendar portlet outright from
master so as to un-break the uPortal build pending its inability to get
its dependencies from Central?

Pursuing in parallel getting those dependencies up as third-parties in
Central so the build un-breaks, at which point the portlet could return
to the quickstart?

I think it's the prudent move to minimize friction on other open
development loops.

Andrew





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Tim Vertein now a uPortal committer

[Drew Wills]

welcome!

On 02/20/2014 12:49 PM, Andrew Petro wrote:

I believe we have critical mass:

+1 Andrew Petro
+1 Eric Dalquist
+1 James Wennmacher
+1 Andrew Wills
+1 Tim Levett

Tim V., I have gone ahead and emailed infrastructure@ requesting
execution on the permission grants that should give you the additional
access that comes with uPortal committership and let's pursue working
out details on that thread.  Congratulations and welcome.

Andrew



On 2/8/14, 11:44 AM, Tim Levett wrote:

+1

On 02-07-14, Andrew Petro  wrote:

Proposed:
Add Tim Vertein as uPortal committer.

Tim has joined the UW-Madison My UW Madison (uPortal) infrastructure
team and was at the Apereo Camp 2014 meeting other uPortal project
participants and sharing some of his work. Recently Tim has been
working particularly on the new Marketplace portlet and more
generally on the UW-Madison portal redesign.

https://wiki.jasig.org/display/UPC/Marketplace

Proposing that he be granted uPortal project committership so as to
be more able to directly participate in uPortal development.

GitHub profile:
https://github.com/vertein

Tim, care to reply further introducing yourself?

Andrew



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
lev...@wisc.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] proposed: Tim Vertein for uPortal committership

[Drew Wills]

+1

It was great to meet you, Tim.  I hope to see you in Miami.

drew

On 02/07/2014 10:12 AM, Andrew Petro wrote:

Proposed:
   Add Tim Vertein as uPortal committer.

   Tim has joined the UW-Madison My UW Madison (uPortal) infrastructure
team and was at the Apereo Camp 2014 meeting other uPortal project
participants and sharing some of his work.  Recently Tim has been
working particularly on the new Marketplace portlet and more generally
on the UW-Madison portal redesign.

https://wiki.jasig.org/display/UPC/Marketplace

Proposing that he be granted uPortal project committership so as to be
more able to directly participate in uPortal development.

GitHub profile:
https://github.com/vertein

Tim, care to reply further introducing yourself?

Andrew





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] pre-1.5.0 version of Fluid

[Drew Wills]

James,

I did some quick testing on my pre-fluid 1.5 Respondr and added some 
notes to the pull request page.


drew

On 02/03/2014 04:53 PM, James Wennmacher wrote:

I built a pre-1.5.0 release of fluid for testing Respondr with pre-1.5.0
fluid, jQuery 1.10.2, jQueryUI 1.10.3.  There are a number of issues
that will need to be worked through though.

On the positive, portlet drag and drop and tab drag and drop are now
working.  On the negative there are a number of other things that are
not, some of which are documented in the resource server pull request.
I've started to look into them, but I know others have an interest in
kicking the tires and trying to resolve issues as well. I haven't
written up Jira items for the things I've found yet, but I will do so
tomorrow morning.

If you'd like to kick the tires and/or aid in the troubleshooting and
fixing of issues, pull down and use:

https://github.com/Jasig/resource-server/pull/21
https://github.com/jameswennmacher/uPortal/commit/ae6198d930817fc1b83e38eb44d024bc807254c6

The gallery does not work with the new version of fluid due to an API
change on how events fire model updates so you'll be using Universality
a bit to modify layouts.  I spent some time on that and set it aside to
get a better idea in general of how well the new fluid will work.  Since
drag and drop is now working and jQuery 1.10.x appears to be OK (within
the context of the issues I've noted so far), I think we will continue
this path since Bootstrap 3 requires jQuery 1.9.x+ anyway.

Thanks,

--
James Wennmacher - Unicon
480.558.2420

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Entering CONFIG mode outside the Portlet Manager?

[Drew Wills]

That's a great answer!

It sounds like it was done originally in a sound, future-proof way.

drew

On 01/24/2014 10:06 AM, Eric Dalquist wrote:

So CONFIG is baked into various framework bits so that the portal knows
how to make the portlet APIs behave when in this mode. As a protection I
believe there is a permission check associated with the ability to
render a portlet in CONFIG.

Give it a try, make CMS render a CONFIG portlet url, click on it and see
what happens :)


On Fri, Jan 24, 2014 at 9:00 AM, James Wennmacher
mailto:jwennmac...@unicon.net>> wrote:

More broadly, is this a case of delegated admin (e.g. for
tenant-based delegated admin use case) that should be accessible for
these tenant-contained sets of portlets?

Do the delegated admins need to do only the rich config, full
portlet configuration (add/remove porlets), or limited portlet admin
(some but not all the properties configured by the Portlet Manager)?

James Wennmacher - Unicon
480.558.2420 


On 01/24/2014 09:50 AM, Drew Wills wrote:

Thanks for chiming in.

On 01/24/2014 09:44 AM, Eric Dalquist wrote:

Normal users can never use CONFIG. It is only usable by
portal admins
and requires specific permissions to even work for a user.
Beyond that,
a portlet might be able to just set CONFIG as the mode on a
URL. I never
actually tried that.


Within the Portlet Manager, I know that the things that get
entered/created in CONFIG mode can become a part of the
portlet-definition record -- e.g. text entered in the WYSIWYG
editor for SimpleCMS.

That integration would still need to work.  This example is
actually one of the more compelling imho -- allow privilaged
users to edit the content of a SimpleCMS portlet "in situ"
(without going through the Portlet Manager).

drew



--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as: eric.ape...@dalquist.org
<mailto:eric.ape...@dalquist.org>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/__display/JSG/uportal-dev
<http://www.ja-sig.org/wiki/display/JSG/uportal-dev>


--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Entering CONFIG mode outside the Portlet Manager?

[Drew Wills]

Thanks for chiming in.

On 01/24/2014 09:44 AM, Eric Dalquist wrote:

Normal users can never use CONFIG. It is only usable by portal admins
and requires specific permissions to even work for a user. Beyond that,
a portlet might be able to just set CONFIG as the mode on a URL. I never
actually tried that.


Within the Portlet Manager, I know that the things that get 
entered/created in CONFIG mode can become a part of the 
portlet-definition record -- e.g. text entered in the WYSIWYG editor for 
SimpleCMS.


That integration would still need to work.  This example is actually one 
of the more compelling imho -- allow privilaged users to edit the 
content of a SimpleCMS portlet "in situ" (without going through the 
Portlet Manager).


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Entering CONFIG mode outside the Portlet Manager?

[Drew Wills]

Hey folks,

Is there anyone on the list who has a good sense of how hard it would be 
to enter CONFIG mode directly from the portlet itself?  (Not via the 
Portlet Manager)


drew


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Respondr Favorites portlet

[Drew Wills]

Anthony & Andrew,

On 01/22/2014 08:24 AM, Andrew Petro wrote:

AC> It might be nice if you could also favorite any web content.

Might.  It's something that's been discussed around here but I don't
think we have concrete plans around that yet.


Perhaps this idea could line up somehow with the work we've been doing 
toward the AUXILIARY window state (though we've taken Eric's suggestion 
and gone the route of incremental enhancement on the DETACHED state). 
In a nutshell, we're looking to display one portlet at a time and give 
it 100% of the width and around 95% of the hight -- all but a thin 
"sticky header."  Intentions for this feature are primarily around 
displaying external apps as iframes within the portal decently.


Fovoriting non-portal web content could mean -- under the hood -- that 
you create an iframe portlet pointing at the external content and add it 
to your layout.  Accessing the content in your favorites would mean 
viewing it in DETACHED state with these enhancements.


I don't think there's currently a way to associate a preferred/default 
window state with a portlet node within a layout, but adding that 
capability might pay dividends in other ways.


Food for thought.

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Some Respondr updates

[Drew Wills]

Hey folks,

There's been a great deal of work recently on Respondr, and it seems as 
though we're heading into the "home stretch."


Regions are in (though not all of them we hope for down the line) and 
functioning decently.  Here's a beginning writeup on that topic, 
including a graphic: 
https://wiki.jasig.org/display/UPC/Respondr+Regions+Feature


Also the gallery is in and "working."  It looks pretty poor atm 
(mostly?) because element placement-related styles are not being 
applied, but (nearly*) all the functions appear to be working.


*One item that is not currently working is drag-and-drop -- not anywhere 
on the page.  We're waiting on some fluid updates that James mentioned 
in his email earlier today.


Comments, discussions, suggestions, and fixes are encouraged and 
appreciated.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Potential JDK Upgrade Breakage

[Drew Wills]

On 01/21/2014 09:25 AM, Eric Dalquist wrote:

I figured it would be good to warn people when I saw the notification go by


It is good -- thanks!

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] meta fragments, identifying and naming

[Drew Wills]

Andrew

On 01/13/2014 09:17 AM, Andrew Petro wrote:

So, the Favorites portlet needs a meta-fragment into which to shove the
user's favorites.  The meta-fragment doesn't display as a tab, but it
benefits from all the features of DLM for providing users a default set
of Favorites (not entirely clear that we're actually going to provide
any default favorites here at Wisc, but it's a nice feature that falls
out from using DLM fragments for this.)



Is this one portlet (i.e. Favorites) that needs to go on a fragment, or 
a whole fragment-worth of portlets?



I'm attracted to a convention-over-configuration flavored solution of
naming such meta fragments starting with _ and then filtering out such
fragments in non-meta contexts.



I think we can use just a regular fragment, but place this content 
within a  element with type=something_besides_regular.  (This is 
an approach/pattern we're already using... see below)



I see some other meta-fragments in trunk that I don't yet understand
(Authenticated?  Resondr?  NonRespondr?).  I'll go understand those
better before the end of Favorites, I'm sure.



Those are for use with Regions.  For Respondr, the portlets in those 
fragments are placed in  elements with 
type=emergency|highlighted|greeting|etc.  Non-"regular" folder types are 
not rendered in the tab/column area -- they are dropped into regions.


drew


But: is uPortal already doing something interesting to identify and
filter out meta-fragments?  How do others feel about a "meta fragments
start with underscores" approach to make this more convention-driven?

Andrew





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Short writeup of the Regions feature in Respondr

[Drew Wills]

Hey folks

https://wiki.jasig.org/display/UPC/Respondr+Regions+Feature

We've been discussing this approach on our calls, but I'm not sure any 
of the info has made it to the wiki before.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Adjustments to recommended git workflow procedures

[Drew Wills]

This seems to be a sensible change.

drew

On 01/02/2014 10:15 AM, Andrew Petro wrote:

Rebasing on local feature branches and even on shared feature branches
the purpose of which is to get clean and merge to master (preferably
with communication and collaboration via pull request): great!  Cleaner
history! Less noise!

I don't see a downside to changing the recommendations for keeping up to
date to rebase rather than merge.

Andrew

On 12/23/13, 11:19 AM, James Wennmacher wrote:

Are there any negatives to changing the procedures 'Keeping Up To
Date' at
https://wiki.jasig.org/display/UPC/Git+Workflow+for+Committers and
https://wiki.jasig.org/display/UPC/Git+Workflow+for+Non-Committers to
switch to rebase from merge?

|# retrieve the updates from the upstream repository|
|$ git fetch upstream -p|
|# switch to the master branch|
|$ git checkout master|
||
|# merge the incoming changes into your local branch|
|$ git merge upstream||/master|
|# now you're ready to update your fork|
|$ git push origin master

to
|
|# retrieve the updates from the upstream repository|
|$ git fetch upstream -p|
|# switch to the master branch|
|$ git checkout master|
||
|# merge the incoming changes into your local branch|
|$ git _rebase_ upstream||/master|
|# now you're ready to update your fork|
|$ git push origin master|

Especially on a feature branch this would reduce the number of 'Merge
branch 'master' of github.com:Jasig/uPortal' messages that would
appear in the commit stream.  We don't have as many of these as I
remember (probably because I used to create a bunch of them but don't
anymore), but I thought it might be a better procedure. Thoughts?
--
James Wennmacher - Unicon
480.558.2420
--

You are currently subscribed touportal-...@lists.ja-sig.org  as:ape...@wisc.edu
To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev


--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] A little housecleaning in JIRA

[Drew Wills]

Hey folks,

I want to let everyone know I'm planning to do some housecleaning in the 
uPortal JIRA space.


Currently there are...
  - 262 open issues;  and
  - 5 reopened issues

I think that's a lot to look through, should you want to review them (I 
do, occasionally).


I'm betting that there are many that can be resolved/closed because...

  - They're duplicates
  - They can't be reproduced
  - They apply to features that have been rebooted, removed, or replaced
  - They _only_ apply to versions of uPortal that are no longer under 
active maintenance (there's a "closed:will not fix" option for this very 
situation)


I suggest that we'd be better served resolving/closing as many of these 
as possible to make it easier to find and review the most important 
issues.  (And of course the data is all still there;  you will still be 
able to find historical JIRA issues that apply to previous releases.)


Should anyone want to pitch in -- big thanks!

Should anyone have thoughts or concerns -- please send them in.

drew wills

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Take BookmarksPortlet out of 4.1?

[Drew Wills]

On 12/10/2013 03:02 PM, Jim Helwig wrote:

We can probably dig up some data on usage. To be honest, I don't see it
having prominent position in our redesigned portal. Perhaps it is old
school and I support taking it off the default welcome tab.


When I made the suggestion at first I thought this issue was going to be 
a "no brainer," but I don't want to take something away that people are 
genuinely interested in having.


Maybe we could hear from a few more folks?  For those of you who have 
the Bookmarks, do you have any data on how much it's used?


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Take BookmarksPortlet out of 4.1?

[Drew Wills]

On 12/10/2013 02:15 PM, Jim Helwig wrote:

Very simple portlets might not require regular commits. What is the
motivating rationale?


Nothing more than a desire to de-clutter, if we're not interested in it 
any longer.  A chance to save a modest amount of disk space, build time, 
and ongoing maintenance & documentation efforts.


We have many more bundled portlets these days than originally, with the 
likelihood of more in the future.


The Bookmarks portlet is in competition with tools like delicious, 
pinterest, social networks, and the browser itself.  Feature-wise, it 
doesn't measure up.  I just don't see many folks wanting to enter their 
bookmarks into their school portal.


And yet it's on the Welcome tab of the quickstart data.  I would be 
delighted to learn that I have it all wrong -- but I'm concerned that 
we're not putting our best foot forward by giving real estate to this 
empty tool when it comes to new folks evaluating the portal.  I'd be 
happier giving the real estate to portlets like Notification, Calendar, 
Courses, Email, Contacts, etc., where it's easy to showcase 
pre-configured content, and it's easier to provide valuable content in 
the portlet the first time a user logs in.


And so I suppose we could consider taking it off the Welcome tab, but 
not de-bundling it.  But we know only a fraction of users find portlets 
that are not on their original layout (their fragments).  In a way that 
approach would exacerbate the issue -- what portion of the user 
population would both (1) find the Bookmarks if it weren't on their 
layout originally and (2) be interested in entering their data?


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Take BookmarksPortlet out of 4.1?

[Drew Wills]

On 12/10/2013 02:04 PM, AUXEPAULES Ludovic wrote:

We use the Bookmarks Portlet at UPMC.


Is the Bookmarks blank when a new portal user first views it?  Do you 
have any records or insights concerning how many portal users use it?


I don't propose we remove it if schools are using it and getting value 
out of it.  I get a chance to speak with many schools -- though not all 
of them -- and it struck me that I hadn't heard of any new adopters 
interested in rolling out the Bookmarks for quite some time.


I have seen much more interest in presenting pre-selected, pre-arranged 
links -- that include custom text, titles, images, formatting and so 
forth.  These needs are nice to address with something like Simple CMS 
or SimpleJSP.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Take BookmarksPortlet out of 4.1?

[Drew Wills]

Hey folks,

Would anyone object to removing (de-bundling) the BookmarksPortlet for 
the upcoming 4.1 release?


We have largely moved away from portlets that start out blank and 
require users to do data entry -- which is what Bookmarks is.  Meanwhile 
we're building & bundling more and more compelling portlets, which 
gradually increases to build times and needs for PermGen space.


Bookmarks hasn't received commits since Feb 2012.  I think we're better 
off trimming it for the next release.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] uPortal 4.0.13 release

[Drew Wills]

Excellent -- thanks for the heads up.

Tim Levett  wrote:

>I'm going to try and get a 4.0.13 release cut during our next 2 week 
>sprint (10/15 to 10/29).  Keep that in mind if you have pending 
>changes/fixes you'd like to see make it into the release.
>
>Thanks,
>
>- Tim
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Vote: uPortal Steering Committee Representative

[Drew Wills]

Enthusiastic +1!

drew

On 09/18/2013 07:43 AM, Eric Dalquist wrote:

+1


On Wed, Sep 18, 2013 at 7:19 AM, Andrew Petro mailto:ape...@unicon.net>> wrote:

+1

I agree emphatically that Anthony will make an excellent uPortal
Steering Committee member.  He's already a leader and I look forward
to his further leadership in this additional role.


On Wed, Sep 18, 2013 at 8:31 AM, Jim Helwig
mailto:jim.hel...@doit.wisc.edu>> wrote:

We have one nominee for the vacant developer representative on
the uPortal Steering Committee: Anthony Colebourne. To make it
official, would committers please respond with a "+1" if you
agree that Anthony should join the uPSC? Voting will close at
5pm PT Friday, September 20, 2013.

Thank you,
Jim Helwig
uPSC Chair



--
You are currently subscribed to uportal-dev@lists.ja-sig.org
 as: ape...@unicon.net


To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/__display/JSG/uportal-dev



--

You are currently subscribed touportal-...@lists.ja-sig.org  
  as:eric.ape...@dalquist.org  


To unsubscribe, change settings or access archives, 
seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev


--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Proposal to change portal's default render timeout from 5000ms to 20000ms

[Drew Wills]

Perhaps one thing we need is a manageable way to configure different 
timeout values for production and everything else.


drew

On 08/28/2013 01:26 PM, Anthony Colebourne wrote:

Hi James,

In my experience I would recommend extreme caution when raising portlet
timeouts.

Under heavy load, it is very easy to use up all the portlet rendering
threads.

Just this morning I accidentally mis-configured a portlet who's time out
is 1 and brought down our servers. We're pretty strict about timeout
values and almost all of our portlets use the 5s default.

We in many cases use ajax to load content from long-running processes.
I'm some of these cases I have reluctantly raised to timeout of the
resource requests only.

I would like to see documented the relationship between rendering
threads and timeout values, also how this relates to tomcat threads and
apache threads where applicable. (I guess db connection pools are also
impacted, both portal and portlet?).

Some guidance on how to choose sensible thread/timeout values based on
averages such as portlets per page / server resources would be useful.

I'm happy to provide information and statistics from our production
cluster if it helps?

-- Anthony.



On 28/08/13 20:08, James Wennmacher wrote:

I propose we change the portal's default render timeout from 5000ms to
2ms.  There are portlets that tend to take long time (such as email
preview) or custom portlets connecting to back end systems where 5000ms
is sometimes too short a time.

I think the user experience in general would be better to have a longer
default so:
- The portal doesn't display an unpleasant message to the user for
longer-running scenarios
- The portal is more tolerant of operational issues such as uPortal or
dependent systems running a bit slow
- Longer-running processes should typically use ajax requests to obtain
the data for a better user experience, so the urgent user response is
less important in these situations since the entire UI is not impacted

This would affect new portlets that are created via the UI (or imported
without a timeout value I believe) but not existing portlet instances.

Thoughts?




--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Proposal to change portal's default render timeout from 5000ms to 20000ms

[Drew Wills]

+1 for the change.

We commonly see situations where new portlet developers accept the 
defaults, get a timeout the first time the portlet they're working on 
renders, then get confused and chase phantoms for a few hours that could 
have been productive.  (It's easy to go more than 5000 ms in 
"bootstraping" for a portlet with even modest complexity.)


drew

On 08/28/2013 12:08 PM, James Wennmacher wrote:

I propose we change the portal's default render timeout from 5000ms to
2ms.  There are portlets that tend to take long time (such as email
preview) or custom portlets connecting to back end systems where 5000ms
is sometimes too short a time.

I think the user experience in general would be better to have a longer
default so:
- The portal doesn't display an unpleasant message to the user for
longer-running scenarios
- The portal is more tolerant of operational issues such as uPortal or
dependent systems running a bit slow
- Longer-running processes should typically use ajax requests to obtain
the data for a better user experience, so the urgent user response is
less important in these situations since the entire UI is not impacted

This would affect new portlets that are created via the UI (or imported
without a timeout value I believe) but not existing portlet instances.

Thoughts?


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Backbone version in uPortal 4.0

[Drew Wills]

On 06/10/2013 12:37 PM, Eric Dalquist wrote:

I completely agree with you Drew, I was asking for a framework portlet
where it would be silly to not just use the uPotal loaded JS libraries.


Ah -- roger.

And I agree 100% as well about framework portlets.

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Backbone version in uPortal 4.0

[Drew Wills]

Eric, Matt, et al.,

I just want to throw in $.02 on this topic...

I think the practice of worrying about what portlets might or might not 
do with JS provided by the portal is unsustainable.  I think it will tie 
us in knots and prevent us from doing what we need to and from moving 
forward.  I think, if we start to worry about it, it will become the 
same issue we used to have with IChannels:  we don't know what APIs are 
in use "in the wild," so we become fearful to touch anything.


IMHO portlets are 100% responsible for their own JS.  Every portlet 
should be developed such that it is prepared to load every line of JS it 
may need on it's own.  As a means of improving performance, however, 
portlets _may_ provide a _configurable option_ to piggyback on one or 
more portal JS libs... but anyone wishing to use this strategy is 
obligated to test it thoroughly (1) as they develop the portlet, and (2) 
_any time they upgrade the portal sources_.


If the portal changes what it's using, and that's no longer compatible 
with what a portlet is using, it's the responsibility of the _portlet_ 
to disable the piggyback feature until the portlet can be enhanced to 
work with the new version.


I think this is a sensible approach for these issues.

drew


On 06/10/2013 09:26 AM, Matt Polizzotti wrote:

Eric,

Sorry it took me a while to get back to you. I don't believe the core framework 
is using backbone, but some portlets are using it. For instance, the News 
Reader Portlet is using Backbone to render its views. Off the top of my head, I 
am not sure which version the portlet is using but it may be looking toward the 
portal first to see if the backbone library exists. This would be the only 
concern that I can think of in terms of upgrading.

Thanks,
Matt



- Original Message -
From: "Eric Dalquist" 
To: "Matt Polizzotti" , "uportal-dev" 

Sent: Friday, June 7, 2013 9:17:45 AM
Subject: Backbone version in uPortal 4.0

I see that uPortal 4.0 is pulling in backbone 0.9.2 but I don't see any
where that we are actually using it in the core framework. Do you see
any problems with my upgrading to the latest version of backbone?

-Eric




--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] [VOTE] Tim Levett for uPortal Committer

[Drew Wills]

+1

Drew

Eric Dalquist  wrote:

>+1
>
>On 6/6/13 8:08 AM, Eric Dalquist wrote:
>> I'd like propose Tim Levett for a uPortal committer, he has been 
>> working on uPortal and portlets at UW for 6 months now and will just 
>> continue to get more involved in the project.
>>
>> This vote needs 3 +1 votes and no -1 votes in the next 72 hours to 
>> pass. All existing uPortal committers can cast binding votes, all 
>> other votes are advisory but still good to get.
>>
>> -Eric
>>
>
>

-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] James Wennmacher for uPortal committer

[Drew Wills]

Hey folks,

We have a very seasoned and capable Java developer here at Unicon who 
has recently become quite involved with uPortal -- and whom we expect to 
be even more involved going forward -- named James Wennmacher.  He's 
also been very active and helpful on the uportal-user, uportal-dev, and 
portlet-dev lists... I hope several of you will recognize the name.


I'd like to nominate James for uPortal committer.  You can look at some 
of the work he's contributed here...


  - https://issues.jasig.org/secure/ViewProfile.jspa?name=jameswennmacher

and here...

  - https://github.com/jameswennmacher?tab=activity

James has submitted numerous pull requests to uPortal and Apereo 
portlets.  In particular, he played a big role in increasing the number 
of reports in the Statistics Portlet, and in improving the statistics 
subsystem generally.


+1

drew


--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re:[uportal-dev] Very interested in your question...

[Drew Wills]

Julien,

I'm going to move this discussion over to uportal-dev because I think 
it's a great one.



So I have some questions about customization permissions that you
introduced, because it's one of our needs and that we already did some
little things, and more I'm trying to make it available in our next
version of uportal (migration from 3.2.4 to 4.x in july/august).



Fantastic.  I knew this feature would be of interest to more schools.

We should absolutely talk and coordinate.


So firstly I would like to know what are you plans about "customization
permission", because I'm doing this work at this moment for our context
for the version 4.0.x that I'm adapting for the migration of our version
3.2.4, and to say I've modified nearly sames things than you.



For the immediate future, I had no further plans than what I checked in...

  - 2 new permissions, 1 for access to the Add Tab button, 1 for access 
to the Customize (gallery) interface
  - Users without the permission have the HTML _removed_ in the XSLT 
process
  - For the Add Tab, there is also a permissions check in the REST API 
that prevents a sophisticated user from bypassing the UI with a clever URL
  - The default data says that Authenticated Users may access both 
functions (anyone else may not)
  - In both cases, this permissions check _replaces_ the 
isAuthenticated() check that was in the XSL previously


And this change was added only to 4.1 (master), since existing 4.0 
deployments won't have the data, and therefore users would suddenly 
loose the ability to personalize their layouts.


But it's easy to pull the changes down to 4.0.x (use $git cherry-pick).


Else to explain our needs, in our context we deploy one portal (with
different virtual domain) for all colleges of our "région" in center of
France, and some higth school of "département" of our "région", it
represents around 200 education's organization with around 100k
students, and for all organization we delegate the rigths to define DLM
of the organization to some peoples, all other people don't have the
rigths to add/modify/delete any element in their layout.



That's a very impressive portal.

I think this enhancement will serve your needs -- just grant the 2 new 
permissions only to the same people who have rights to manage DLM fragments.



So if you want i can share our experience, talk about our needs and
could provide some help in development or other things for this feature.



Yes, please.

I'm especially keen to tap the talent of the French uPortal community 
for helping uPortal live up to its potential.  I've seen some very 
impressive things from them.


Please tell us about your requirements and the 
enhancements/customizations you've done or are about to do for uPortal 
and Apereo portlets.  Often there are universities here that would love 
to do the same things, but "put them on the back burner" (delay them) 
because they believe they'd have to do all the work themselves.


drew wills

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] USD Portal Statistics Portlet

[Drew Wills]

Aaron,

Thanks man!

I'm a big fan of that portlet.

drew

On 04/03/2013 06:25 AM, Aaron Grant wrote:

Just wanted to add a little blurp, we added this portlet to our
production portal. This is fantastic and fun to watch. Thanks for all
your hard work USD and others. :)

Aaron

On Mon, Mar 11, 2013 at 9:18 AM, Dijkstra, Sijo mailto:s.w.a.dijks...@uva.nl>> wrote:

+1
Sijo Dijkstra



-Original Message-
From: bounce-27668626-15299...@lists.wisc.edu
<mailto:bounce-27668626-15299...@lists.wisc.edu>
[mailto:bounce-27668626-15299...@lists.wisc.edu
<mailto:bounce-27668626-15299...@lists.wisc.edu>] On Behalf Of James
Wennmacher
Sent: dinsdag 5 maart 2013 19:09
To: uportal-dev@lists.ja-sig.org <mailto:uportal-dev@lists.ja-sig.org>
Cc: Eric Dalquist
Subject: Re: [uportal-dev] USD Portal Statistics Portlet

That is great. I love the idea. It looks very useful.

James Wennmacher
Unicon

On 03/05/2013 10:39 AM, Eric Dalquist wrote:
 > Looks awesome, +1 from me
     > On 03/05/2013 10:23 AM, Drew Wills wrote:
 >> Hey folks,
 >>
 >> University of South Dakota has this really cool "Portal Statistics"
 >> portlet that they show on their guest page.  It shows how many users
 >> logged in recently, as well as the most popular search terms
recently.
 >>
 >> They like it because it helps emphasize and communicate the value of
 >> the portal -- it illustrates just how much the portal is used.
  (Heads up:
 >> they're on spring break atm, so the screenshot has a very low
 >> number.)
 >>
 >> I think it's a great widget, and I'd like to fold something like
this
 >> into uP as a framework portlet and tie it to the uP4 stats
infrastructure.
 >>
 >> drew
 >>
 >>
 >>  Original Message 
 >>
 >> Below is a screenshot of our portal statistics portlet.  Upon login
 >> to our portal, we log the user's information (username,
affiliations,
 >> ip, etc).  Every 15 minutes we update the statistics to show logins
 >> broken down by affiliation.  We also capture the search terms from
 >> our custom portal search and display the top 10 search terms
from the last week.
 >>
 >>
 >>
 >>
 >


--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as: s.w.a.dijks...@uva.nl
<mailto:s.w.a.dijks...@uva.nl> To unsubscribe, change settings or
access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev

--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as: asgr...@oakland.edu
<mailto:asgr...@oakland.edu>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev




--
Aaron Grant
Project Coordinator and Systems Integrator
Oakland University - UTS <http://oakland.edu/uts>

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] USD Portal Statistics Portlet

[Drew Wills]

Hey folks,

University of South Dakota has this really cool "Portal Statistics" 
portlet that they show on their guest page.  It shows how many users 
logged in recently, as well as the most popular search terms recently.

They like it because it helps emphasize and communicate the value of the 
portal -- it illustrates just how much the portal is used.  (Heads up: 
they're on spring break atm, so the screenshot has a very low number.)

I think it's a great widget, and I'd like to fold something like this 
into uP as a framework portlet and tie it to the uP4 stats infrastructure.

drew


 Original Message 

Below is a screenshot of our portal statistics portlet.  Upon login to
our portal, we log the user’s information (username, affiliations, ip,
etc).  Every 15 minutes we update the statistics to show logins broken
down by affiliation.  We also capture the search terms from our custom
portal search and display the top 10 search terms from the last week.




-- 
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev<>

[uportal-dev] Please help us review pull #109 -- UP-3650

[Drew Wills]

Folks,

https://github.com/Jasig/uPortal/pull/109

Chris Waymire recently opened an important pull request.  It's the 
contributed implementation of the uportal-platform-api.  It was first 
developed for SSP (where it's currently called uportal-java-api).


It's offers easy-to-use, effective, *greatly enhanced* access to...
  - Groups
  - Permissions
  - Person attributes

(NOTE:  The Person Attributes stuff is delayed slightly -- it's pending 
some work being done by Eric on person-directory v2.)


It would be very helpful to get more eyes on this work an make it as 
polished as possible.  Owing to it's nature as an API, we have greater 
responsibility to support it (without breaking changes) going forward.


Thanks,

drew wills



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Enhancement to place (optionally) some config outside uPortal build/deploy process

[Drew Wills]

On 1/25/2013 3:31 PM, Laura McCord wrote:

Awesome! The page also looks great. I'll scatter some references to it
where relevant.


Thanks Laura -- that would be great!

drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Enhancement to place (optionally) some config outside uPortal build/deploy process

[Drew Wills]

** UPDATE **

This work is complete.

I quickly added a new manual page here:

  - 
https://wiki.jasig.org/display/UPM40/Properties+Files+and+Properties+Overrides


Please feel free to...
  - Move it
  - Rename it
  - Rewrite it
  - Ask me to add something to it

Cheers,

drew

On 1/23/2013 9:11 AM, Drew Wills wrote:

Folks,

One of the ideas we discussed at the Unconference was an emphatic
suggestion from the SSP folks that uPortal should allow for placing some
configuration settings outside the uPortal webapp or outside Tomcat
altogether.  This idea, furthermore, has come up before;  I know OHIO
University brought it up when we were working with them.

I have a version of this enhancement working...

   - https://gist.github.com/4608582

I would be delighted to:
   - Whip up a JIRA
   - Commit to master and rel-4-0-patches
   - Update the uPortal Manual to document the use of this feature

There's one minor drawback I want to bring to light:  the files are 100%
optional but, as written, it puts the following in the log on startup
for each one that's not used...

WARN  [main] o.s.c.s.PropertySourcesPlaceholderConfigurer 2013-01-23
08:41:54,293 - Could not load properties from URL
[file:/${PORTAL_HOME}/overrides.properties]:
\${PORTAL_HOME}\overrides.properties (The system cannot find the path
specified)


drew wills






--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] Enhancement to place (optionally) some config outside uPortal build/deploy process

[Drew Wills]

Misagh,

I would wager we could eliminate the warning by subclassing something in 
Spring.  I don't know if it's worth the trouble -- both immediately and 
in future maintenance.


drew

On 1/23/2013 1:02 PM, Misagh Moayyed wrote:

Drew,
+1, this is very useful.

About the log entry, could we potentially circumvent the line by perhaps
writing a custom property configure that ignores the warning?

-Misagh



-Original Message-
From: bounce-26750363-57692...@lists.wisc.edu [mailto:bounce-26750363-
57692...@lists.wisc.edu] On Behalf Of Drew Wills
Sent: Wednesday, January 23, 2013 9:12 AM
To: uportal-dev@lists.ja-sig.org
Subject: [uportal-dev] Enhancement to place (optionally) some config
outside uPortal build/deploy process

Folks,

One of the ideas we discussed at the Unconference was an emphatic
suggestion from the SSP folks that uPortal should allow for placing
some configuration settings outside the uPortal webapp or outside
Tomcat altogether.  This idea, furthermore, has come up before;  I know
OHIO University brought it up when we were working with them.

I have a version of this enhancement working...

- https://gist.github.com/4608582

I would be delighted to:
- Whip up a JIRA
- Commit to master and rel-4-0-patches
- Update the uPortal Manual to document the use of this feature

There's one minor drawback I want to bring to light:  the files are
100% optional but, as written, it puts the following in the log on
startup for each one that's not used...

WARN  [main] o.s.c.s.PropertySourcesPlaceholderConfigurer 2013-01-23
08:41:54,293 - Could not load properties from URL
[file:/${PORTAL_HOME}/overrides.properties]:
\${PORTAL_HOME}\overrides.properties (The system cannot find the path
specified)


drew wills



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
mmoay...@unicon.net To unsubscribe, change settings or access archives,
see http://www.ja-sig.org/wiki/display/JSG/uportal-dev





--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Enhancement to place (optionally) some config outside uPortal build/deploy process

[Drew Wills]

Folks,

One of the ideas we discussed at the Unconference was an emphatic 
suggestion from the SSP folks that uPortal should allow for placing some 
configuration settings outside the uPortal webapp or outside Tomcat 
altogether.  This idea, furthermore, has come up before;  I know OHIO 
University brought it up when we were working with them.


I have a version of this enhancement working...

  - https://gist.github.com/4608582

I would be delighted to:
  - Whip up a JIRA
  - Commit to master and rel-4-0-patches
  - Update the uPortal Manual to document the use of this feature

There's one minor drawback I want to bring to light:  the files are 100% 
optional but, as written, it puts the following in the log on startup 
for each one that's not used...


WARN  [main] o.s.c.s.PropertySourcesPlaceholderConfigurer 2013-01-23 
08:41:54,293 - Could not load properties from URL 
[file:/${PORTAL_HOME}/overrides.properties]: 
\${PORTAL_HOME}\overrides.properties (The system cannot find the path 
specified)



drew wills



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] VOTE - Misagh Moayyed for uPortal Committer

[Drew Wills]

+1

Misagh has been a valuable Jasig portlets committer for some time now, 
as well as a presenter at Jasig conferences and important CAS contributor.


You can get a sense for his committment to Jasig at the following URLs:

  - https://github.com/mmoayyed?tab=activity
  - https://issues.jasig.org/secure/ViewProfile.jspa?name=mmoayyed
  - https://wiki.jasig.org/users/viewuserprofile.action?username=mmoayyed

drew wills

On 1/22/2013 5:44 PM, Eric Dalquist wrote:

I'd like to propose Misagh Moayyed as a committer for the uPortal
project. Misagh has been doing portlet development and providing uPortal
patches for several months now. The voting will be open until the 26th
and 3 +1 votes with no -1 votes are needed from existing uPortal
committers.

-Eric




--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] VOTE - Chris Waymire for uPortal Committer

[Drew Wills]

+1

Chris is very capable and has solid track record in Jasig portlets as well.

You can look at his contributions in JIRA here:

  - https://issues.jasig.org/secure/ViewProfile.jspa?name=cwaymire

and in GitHub:

  - https://github.com/waymirec?tab=activity

and in the wiki:

  - https://wiki.jasig.org/users/viewuserprofile.action?username=cwaymire

drew wills

On 1/22/2013 5:41 PM, Eric Dalquist wrote:

I'd like to propose Chris Waymire as a committer for the uPortal
project. Chris is relatively new but has already provided some great new
features and refactoring in uPortal on the stats system. The voting will
be open until the 26th and 3 +1 votes with no -1 votes are needed from
existing uPortal committers.


-Eric




--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

[uportal-dev] Hibernate 4.1.9 & the jTDS (SQL Server) driver

[Drew Wills]

Hey folks,

Kostya at SCSU brought an issue to my attention that I think is worth 
noting...


It seems that -- starting with v4.1.7 -- Hibernate requires JDBC4 support:

  - https://hibernate.onjira.com/browse/HHH-7778

But the jTDS driver is targeting JDBC4 for their 1.3 line:

  - 
http://sourceforge.net/p/jtds/news/2012/10/jtds-jdbc-driver-127-and-130-released/


JTDS is a popular 3rd-party driver for MS SQL Server.

The issue is that 1.3 also (apparently) _requires_ Java 7.  I know there 
has been much recent work to support Java 7... where are we on that?  Is 
that (as I seem to remember) a uP 4.1 only thing?


The uP4 manual still says Java 7 not supported:

  - https://wiki.jasig.org/display/UPM40/Requirements

I have suggested that _perhaps_ rolling the version of hibernate back 
(from 4.1.9 currently) to 4.1.6 would allow the most recent jTDS 1.2 
driver to work.


drew

--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Re: [uportal-dev] What are Transient Portals Please?

[Drew Wills]

Matt,

(Responses below...)

On 01/08/2013 05:46 AM, Matthew Mize wrote:

Okay, that's about what I thought, we are having trouble with using one
of our portlets in transient mode.  Our problem comes when we try to
include one of our portlets in our custom skin using the  tag.


Do you mean a  tag in a [fragment-]layout.xml file?  That's the 
customary way to do what you're after.


Here's a breakdown of how I would do this task:

  - Use  somewhere within the Universality theme to place 
the portlet just where I want to (see tips, emergency-alerts for examples)
  - Add the portlet to a DLM fragment using a  element within 
a header folder (with hidden=false) within a fragment-layout.xml file 
(see tips, emergency-alerts for examples)
  - Make sure "allow expanded content" is turned on (for uP3;  it's on 
by default in uP4)

  - Make sure your users are in the audience of the fragment

That's essentially it.  I believe your portlet should recognize and 
honor the user's state.


drew wills



We added a home-grown search portlet to the layout so
all users will have access to that portlet on all of their tabs.  The
default view comes up just fine but when a user actually tries to search
for something, the results are not displayed.  We can workaround this by
simply adding the portlet to the users' layout which I believe causes
the portlet to not be loaded as transient.

My question is, can a transient portal have and respect states so the
search results are shown?  If so, what's preventing our portlet's state
from being updated with the users' search results?


On Mon, Jan 7, 2013 at 3:54 PM, Drew Wills mailto:awi...@unicon.net>> wrote:

Matt,

IIRC, a transient portlet (or channel, earlier) is one that's not in
your layout.  There are many circumstances where a user can
essentially 'leave' his/her layout and go instead to a specific,
named portlet.  In such cases, the framework wraps the single
portlet in some form of transient layout node.

drew


On 01/07/2013 12:07 PM, Matthew Mize wrote:

I've just spent the morning trying to understand what transient
portlets
are but haven't been able to find any complete documentation.  I was
hoping someone on this list could help me better understand what the
difference is between a transient channel and a regular channel.

We are using uPortal 3.2.x.

Thanks in advance.


--__--__
Matt Mize, Senior Developer, BFFF
   - Pay no attention to the man in the back office
   - Pee-mo-weck is a Dead Fish (tm)
mmi...@udayton.edu <mailto:mmi...@udayton.edu>
<mailto:Matt.Mize@notes.__udayton.edu
<mailto:matt.m...@notes.udayton.edu>>

(937) 229-1024 

UDit Department, University of Dayton
300 College Park, Dayton, OH, 45469-2230

--

You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as: awi...@unicon.net
<mailto:awi...@unicon.net>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/__display/JSG/uportal-dev
<http://www.ja-sig.org/wiki/display/JSG/uportal-dev>


--
You are currently subscribed to uportal-dev@lists.ja-sig.org
<mailto:uportal-dev@lists.ja-sig.org> as: mmi...@udayton.edu
<mailto:mmi...@udayton.edu>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/__display/JSG/uportal-dev
<http://www.ja-sig.org/wiki/display/JSG/uportal-dev>




--

Matt Mize, Senior Developer, BFFF
  - Pay no attention to the man in the back office
  - Pee-mo-weck is a Dead Fish (tm)
mmi...@udayton.edu <mailto:matt.m...@notes.udayton.edu>
(937) 229-1024

UDit Department, University of Dayton
300 College Park, Dayton, OH, 45469-2230

--

You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
awi...@unicon.net
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev



--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev