Re: [uportal-dev] DLM restrictions and uPortal 2.6 Ajax preferences

[Andrew Petro]

Hi Jen, I hate to make work for you.  Contributing to uPortal should be a joyful and rewarding, and not administratively tedious, activity. Nonetheless, my effectiveness as a release engineer would be noticeably better and saner if it became true that the 2.6.0 RC2 wiki page report on bugs affecting 2.6.0 RC2 accurately reflected the bugs.  These outstanding bugs in the AJAX UI not respecting DLM restrictions need Jira issues that are marked as "affects-version" including 2.6.0 RC2.  Would you be willing to take a look at making that happen? That really helps me to understand and articulate where we're at with the release.  Otherwise I'm drowning in this state of knowing there are issues but not being clear on what they are. If I'm doing something in the workflow around Jira releases that's making it harder than it has to be to get Jira issues with the right metadata to produce the meaningful reports, I'd be thrilled to learn to use the tool better... Thanks, Andrew Jennifer Bourey wrote: Hi all, I've fixed a number of the outstanding uPortal 2.6 bugs involving the Ajax UI not respecting DLM restrictions.  However, I'm unclear on the best way to fix a number of the remaining scenarios. In particular, the UI we created for column editing presents conflicts with DLM's internals that don't seem easy to reconcile.  To simplify the interface for our users, we changed from a model where users create and remove individual columns to one where users simply choose between one and some fixed number of columns.  When columns are eliminated, the contained channels are appended to the new last column, rather than deleted from the layout.  In our user testing, this seemed to eliminate confusion. This works great at Yale, where we never lock columns.  However, what do we do when DLM restrictions for columns have been set?  The ajax UI currently does the following: 1. When the user decreases the number of columns, delete columns as needed from the right-hand side, and append all contained columns to the end of the last preserved column. 2. When the user increases the number of columns, append columns as necessary to the right-hand side. I can envision a number of potential conflicts between this model and that of DLM: 1.  User tries to change from two columns to one column.  The second column is deleteable, but the first column is locked down such that the user can't add new channels.  The AJAX UI would try to delete the second column and move all the channels to the first column (which isn't allowed). 2.  User tries to change from two columns to one column.  The second column is not deletable, but the first column is.  In this case, the AJAX UI would try to delete the second column and fail, although if it tried to delete the first instead, it could decrease the column count to one, as the user requested. I hate to design a user interface based on the internal layout representation of the java code, but I'm not sure how to sort out the conflicts between these two models.  What do we want to do? - Jen --------------------------------- Jennifer Bourey Technology and Planning Yale University ITS 203.432.5718 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: %%emailaddr%% 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: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev