WCI 2.1.x branch created and 2.1.1 released
by Matt Wringe
A new branch for WCI has been created (2.1.x) trunk is now for 2.2.x
development.
WCI 2.1.1-GA has been released, there was only very minor changes
(nothing in the code, just pom changes) since the last beta.
14 years
Adding new field displayName for User
by Marek Posolda
Hi,
We have customers who would like to have editable "displayName" of user.
Currently what's displayed in right top corner after login of user is
his fullName, which is hardcoded as 'firstName lastName' . So we have
suggestions to add new non-mandatory field displayName, which can be
something similar like in Thunderbird
https://wiki.mozilla.org/Thunderbird:Help_Documentation:Using_the_Address...
. So user can fill displayName during his registration and it will be
displayed in right top corner in UIUserInfoPortlet. If user won't have
displayName, it will fallback to old behaviour and it will show fullName
instead of it.
What do you think about it? I already created JIRA
https://issues.jboss.org/browse/GTNPORTAL-2358 with attached patches.
First patch is for required changes in
exo.core.component.organization.api . It's about adding 2 new methods
"getDisplayName" and "setDisplayName" to interface User and change
UserImpl implementation and other things according to it. Should I
create JIRA into EXOJCR project for it?
Second patch is for GateIn where needed changes are:
- Adding new field into all portlets for creating and updating of user
- Changing logic in UIUserInfoPortlet to use displayName with fallback
to fullName
Any objections?
Thanks,
Marek
14 years
mobile spec
by Julien Viet
Hi Matt,
I started to read the mobile specs, I feel there is a missing global spec that references the "sub" specs and provide more context and general information.
Would you mind to do it please ?
I tagged the existing specs with gatein-mobile.
thanks
Julien
14 years
Updating JCR version in GateIn trunk
by Marko Strukelj
It would be good to update JCR version we package with GateIn to the latest
one released.
That would be:
<org.exoplatform.kernel.version>2.3.6-GA</org.exoplatform.kernel.version>
<org.exoplatform.core.version>2.4.6-GA</org.exoplatform.core.version>
<org.exoplatform.ws.version>2.2.6-GA</org.exoplatform.ws.version>
<org.exoplatform.jcr.version>1.14.6-GA</org.exoplatform.jcr.version>
Anyone sees any possible issues with that?
- marko
14 years
Resource serving issue (fixed)
by Julien Viet
Hi,
while using resource serving for doing Ajax, I found out that the implementation was only handling basic resource serving (i.e a portlet that sends a stream on the response with status 200 OK).
This is not a problem for the server but rather for the user agent which is never able to be aware of non 200 OK responses.
I commited a fix which improves resource serving handling in other use cases:
1/ a response is always sent to the browser (previously in some case no answer was sent). When an error occurs a 500 (internal server error) status is sent, previously nothing was done.
2/ when a Portlet uses the ResourceResponse.HTTP_STATUS_CODE to set a status code on the response (to allow status other than 200, for instance 404 not found) this status code is sent to the user agent before streaming the headers and body.
This allows portlets relying on resource serving for ajax to become better http servers.
thanks
Julien
ps: I believe also that those use cases should behave correctly with WSRP. Chris could you tell us if this use case is correctly handled ?
14 years
Username restrictions?
by Christophe Laprun
Hi all,
I'm currently working on https://issues.jboss.org/browse/GTNPORTAL-1673 and I'm quite puzzled by the different rules that are in place to validate usernames. Not only are these rules not consistent across fields which display usernames (some are validated using UsernameValidator, some are validated using ExpressionValidator) but I'm also confused about the need to validate read-only fields (which presumably will only display valid information since it doesn't come from the user, right?). What are the rules for a valid username and where are they documented? What are the restrictions and why are they in place?
The second issue is that some of our users (rightly) want to validate user names according to their own rules instead of arbitrary and opaque rules that we impose on them for reasons that are entirely too unclear to me and probably to our users. To address this issue, I need to find a way to dynamically inject validators for some of the fields based on user-definable configuration. I'm currently thinking about using a service that would be initialized by the kernel and take its configuration from ${gatein.conf.dir}. Any opposition to this design? Any better idea?
Cordialement / Best,
Chris
==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm
14 years
long gadget descriptions.
by Matt Wringe
There is an issue in that we don't check if a gadget's description
length is too long when importing a gadget. See
https://issues.jboss.org/browse/GTNPORTAL-2282
I have a patch attached to the issue to just silently truncate the
description string if its too long.
But, it might just make more sense to remove the description length
requirement for gadgets/portlet. Other than an issue with not being able
to save a gadget, it seems to be working fine right now with extra long
descriptions.
Is there any real reason why we have a restriction on application
description lengths?
14 years
