Re: [uportal-dev] FREEZE master for 4.1.0 release
Le lundi 07 juillet 2014 03:02:33 Andrew Petro a écrit : Made some good progress towards 4.1.0 release […]. Andrew Hi uPortal developers, During a rebasing of a forked uportal-4.0.14…uportal-4.0.6.SR1¹ onto uportal-4.1.0-RC2, I came across 4 specific commits from 4.0 branch where I didn't found a matching² commit/code in 4.1 timeline. — UP-3640 → https://issues.jasig.org/browse/UP-3640 seems to be resolved differently by UP-3298 in 4.1 line. — UP-3665 → https://issues.jasig.org/browse/UP-3665 seems to me, to be related to ↑UP-3640 so may be irrelevant to 4.1 line. — UP-3642 → https://issues.jasig.org/browse/UP-3642 UP-3981 removed console.log(…) lines from personLookup.jsp, but not from the three other files (grep -rF console.log .)… UP-3642 might be cherry-picked if relevant (there's only one unchecked console access left in entity-selector.js I guess) $ git cherry-pick $(git rev-list --grep=UP-3642 uportal-4.0.14) $ git checkout HEAD -- uportal-war/src/main/webapp/WEB-INF/flows/person- lookup/personLookup.jsp $ git cherry-pick --continue — UP-4106 → https://issues.jasig.org/browse/UP-4106 CVE-2014-3417 (Illicit access to Config mode) is marked as fixed in JIRA but the commit still may be cherry-picked without many unresolvable conflicts (through my non-expert eyes however). I thought that these ↑ might eventually interest some of you, so I shared that here. Sorry for the noise if not. Regards, -- Léa Raya DÉCORNOD —— ¹: common ancestor btw 4.0 and 4.1 is ↓ $ git describe $(git merge-base uportal-4.0.13 uportal-4.1.0-RC2) uportal-4.0.6.SR1-10-gfd0248e ²: git log --grep='\(UP-3640\|UP-3642\|UP-3665\|UP-4106\)' --oneline uportal-4.0.14 26aa4b4 UP-4106 Enforce CONFIG permission. cdd2623 UP-3665 Fix non-servlet3 proxied req references b459805 UP-3642 Removing unnecessary console.log statements 3ba9ea6 UP-3640 Get uP40 working on TC7 $ git log --grep='\(UP-3640\|UP-3642\|UP-3665\|UP-4106\)' --oneline uportal-4.1.0-RC2 $ -- 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] https://issues.jasig.org/browse/UP-3899
Opening up to a broader discussion among uportal-dev because it begs more wisdom than I have. :-) Though a rare operational error, it causes event aggregation to fail. I'm not sure if it skips the bad record(s) or just locks up and continuously fails on that record. What is the downside of incorporating the change into uPortal 4.0? Does something special have to occur to update the database? I believe the user would need to run an additional ant command to update the database and I'm not familiar with whether we have to do something special to get it so ant knows how to update the DB. Of course we'd have to make note that a database update is needed in the patch release notes. Thoughts from others on whether to incorporate this into 4.0 and effort required? James Wennmacher - Unicon 480.558.2420 On 07/07/2014 11:29 AM, Tim Levett wrote: Hi James, I did not apply it to 4.0 because it is a database change which is kind of frowned upon I thought. An easy fix is to update the old record in UP_AGGR_PORTLET_MAPPING so that the new record can be inserted. - Tim *From:* James Wennmacher jwennmac...@unicon.net *Sent:* Monday, July 7, 2014 11:54 AM *To:* Tim Levett *Cc:* Andrew Petro *Subject:* https://issues.jasig.org/browse/UP-3899 Hi Tim. Did you have a chance to look into adding https://issues.jasig.org/browse/UP-3899 https://issues.jasig.org/browse/UP-3899 to uPortal 4.0.x? The change looks straight forward and useful. What I'm not sure about is if anything special needs to occur related to updating the database schema. -- James Wennmacher - Unicon 480.558.2420 -- 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] In which branches to fix UP-3899 portlet fname change breaking event aggregation
Let's accept UP-3899, as annoying as it is, as a defect affecting all 4.0 versions, mark it fixed for 4.1, and focus on upgrading folks to 4.1 to pick up this and much other goodness.? I'd rather not try to make a schema change in 4.0-patches at this late date in that very long-running patch series. -Andrew From: bounce-35646735-81063...@lists.wisc.edu bounce-35646735-81063...@lists.wisc.edu on behalf of James Wennmacher jwennmac...@unicon.net Sent: Monday, July 07, 2014 1:48 PM To: uportal-dev@lists.ja-sig.org Subject: Re:[uportal-dev] https://issues.jasig.org/browse/UP-3899 Opening up to a broader discussion among uportal-dev because it begs more wisdom than I have. :-) Though a rare operational error, it causes event aggregation to fail. I'm not sure if it skips the bad record(s) or just locks up and continuously fails on that record. What is the downside of incorporating the change into uPortal 4.0? Does something special have to occur to update the database? I believe the user would need to run an additional ant command to update the database and I'm not familiar with whether we have to do something special to get it so ant knows how to update the DB. Of course we'd have to make note that a database update is needed in the patch release notes. Thoughts from others on whether to incorporate this into 4.0 and effort required? James Wennmacher - Unicon 480.558.2420 On 07/07/2014 11:29 AM, Tim Levett wrote: Hi James, I did not apply it to 4.0 because it is a database change which is kind of frowned upon I thought. An easy fix is to update the old record in UP_AGGR_PORTLET_MAPPING so that the new record can be inserted. - Tim From: James Wennmacher jwennmac...@unicon.netmailto:jwennmac...@unicon.net Sent: Monday, July 7, 2014 11:54 AM To: Tim Levett Cc: Andrew Petro Subject: https://issues.jasig.org/browse/UP-3899 Hi Tim. Did you have a chance to look into adding https://issues.jasig.org/browse/UP-3899 to uPortal 4.0.x? The change looks straight forward and useful. What I'm not sure about is if anything special needs to occur related to updating the database schema. -- James Wennmacher - Unicon 480.558.2420 -- 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
RE: Re:[uportal-dev] https://issues.jasig.org/browse/UP-3899
Just to provide a little more info, it does lock up and continuously error on that record in 4.0, fixed in 4.1. You can see that fix here: https://github.com/Jasig/uPortal/commit/e21c18f1038ceea2083c44076aaf0ea7221750b8. We just made the change to master since it involved a DB change. - Tim From: bounce-35646735-70367...@lists.wisc.edu bounce-35646735-70367...@lists.wisc.edu on behalf of James Wennmacher jwennmac...@unicon.net Sent: Monday, July 7, 2014 1:48 PM To: uportal-dev@lists.ja-sig.org Subject: Re:[uportal-dev] https://issues.jasig.org/browse/UP-3899 Opening up to a broader discussion among uportal-dev because it begs more wisdom than I have. :-) Though a rare operational error, it causes event aggregation to fail. I'm not sure if it skips the bad record(s) or just locks up and continuously fails on that record. What is the downside of incorporating the change into uPortal 4.0? Does something special have to occur to update the database? I believe the user would need to run an additional ant command to update the database and I'm not familiar with whether we have to do something special to get it so ant knows how to update the DB. Of course we'd have to make note that a database update is needed in the patch release notes. Thoughts from others on whether to incorporate this into 4.0 and effort required? James Wennmacher - Unicon 480.558.2420 On 07/07/2014 11:29 AM, Tim Levett wrote: Hi James, I did not apply it to 4.0 because it is a database change which is kind of frowned upon I thought. An easy fix is to update the old record in UP_AGGR_PORTLET_MAPPING so that the new record can be inserted. - Tim From: James Wennmacher jwennmac...@unicon.netmailto:jwennmac...@unicon.net Sent: Monday, July 7, 2014 11:54 AM To: Tim Levett Cc: Andrew Petro Subject: https://issues.jasig.org/browse/UP-3899 Hi Tim. Did you have a chance to look into adding https://issues.jasig.org/browse/UP-3899 to uPortal 4.0.x? The change looks straight forward and useful. What I'm not sure about is if anything special needs to occur related to updating the database schema. -- James Wennmacher - Unicon 480.558.2420 -- 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
