Bugzilla – Full Text Bug Listing
| Summary: | Personal information should include picture and blog url | ||
|---|---|---|---|
| Product: | Community | Reporter: | Bjorn Freeman-Benson <bjorn.freeman-benson> |
| Component: | Project Management & Portal | Assignee: | Karl Matthias <karl.matthias> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P4 | CC: | karl.matthias, nboldt |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 193176 | ||
|
Description
Bjorn Freeman-Benson
It should also include a "Location" field for a lat/lon if the City/State/Country is not filled in or they want to use a different location. (In reply to comment #1) The Location field should override the real Address for public consumption. Thus if someone does not want their City/State/Country to be public, they can put some other value in the Location field. The Location field can contain a Lat/Lon or an address that can geo-coded. Thus someone might choose to say "Canada" or "Ontario, Canada" instead of their specific city. Blog Url is now implemented and checked-in Hmm now that I started working on this (because of infra 194) I see that this has been assigned to Gabe. Leaving it to him. infra 217 I mean I have been working on the personal picture part of this bug and I have it working on my local box. I haven't checked the code into CVS because I had to create 2 new fields in the foundation People database (Picture Blob,Picture_mime varchar(32)). On Monday (May 19th 2008) I will work with Karl to get the new fields onto staging/production. 'AbstractComponent::html_show_fields' now can take a new parameter for images called 'custom_margin_action'. 'custom_margin_action' is set to a 'onclick_action_in_margin' object. This allow me to use the the default rendering the Portal uses instead of having to roll a custom inner_html/edit_html. I want to do some refactoring on 'organization_information.class.php' to use the new parameter 'custom_margin_action'. After my code for managing personal pictures is checked in the last thing to do is develop the REST api and then this bug can be closed. (In reply to comment #6) > I have been working on the personal picture part of this bug and I have it > working on my local box. Just curious ... is linking to a remote image OK too? Or do you prefer that people upload an image and it be stored in your db, than that we maintain them ourselves in CVS or on other servers (eg., as uploads to blogs or personal sites)? (In reply to comment #7) My original thought was "no, we want a copy", but then I realized that we don't need to have an archival copy of your picture (we do need an archival copy of address/contact information for legal reasons, but not the picture) so, sure, an url would be a fine feature. Also, Gabe, we need to make sure that this code can handle the case where someone uploads a 10Mb picture from their camera. Obviously it needs to resize the picture to something reasonable and small before saving it in the database. (In reply to comment #8) > (In reply to comment #7) > My original thought was "no, we want a copy", but then I realized that we don't > need to have an archival copy of your picture (we do need an archival copy of > address/contact information for legal reasons, but not the picture) so, sure, > an url would be a fine feature. Any legal / XSS impacts from linking to a remove site to host content served on an Eclipse.org site? > Also, Gabe, we need to make sure that this code can handle the case where > someone uploads a 10Mb picture from their camera. Obviously it needs to resize > the picture to something reasonable and small before saving it in the database. Given the many free tools out there for resizing images, I'd say limit the upload to 200-300K and make people provide their own reduced images. There's no point in your having to handle the upload bandwidth if you're just going to take it and resize it before storing it in the db. Also, it might be less pain to store the image in CVS and store only a URL (or file path) in the database. That way you don't need three columns for blob, mimetype, and URL, just ONE for URL (whether it's /images/foo.jpg on http://www.eclipse.org or http://myblog.yoursite.com/images/bar.png). That's what I do for the Modeling Team pics, which I hope to deprecate once the Foundation has a replacement for us to use. UI and schema links below. Source is in cvs, of course -- look for www/modeling/includes/team-common.php for the actual database query / markup code. http://www.eclipse.org/modeling/project-info/team.php http://build.eclipse.org/modeling/build/schema.php#developers http://build.eclipse.org/modeling/build/schema.php#teams http://build.eclipse.org/modeling/build/schema.php#groups (In reply to comment #9) > Given the many free tools out there for resizing images, I'd say limit the > upload to 200-300K and make people provide their own reduced images. True, but there's still the problem that a 200k image can still be too large to show on a webpage. > Also, it might be less pain to store the image in CVS and store only a URL (or > file path) in the database. Except that the portal is now for everyone involved with Eclipse (including members and people who submit talks to EclipseCon) and not just people with access to CVS. I suppose we could take the uploaded file and put it in CVS behind the scenes, but it's easier to just put it in the database. I will adjust my code to allow posting either a URL or uploading an image (since right now it only allows you to upload an image). Uploaded images are scaled down to a width of 220px (if they are wider than 220px). I have noticed that large images are not being uploaded correctly so I will look into that issue. We definitely want to put this in our database. We have too many places where we'll need to know for sure that a photo is available or not without relying on external hosting. Also, the web servers will not be able to make a call to an external system to download the image, so using an URL to upload them is not going to be available as a feature. This is for security reasons--we don't call out of network. And just to agree with Bjorn: the DB is the right place for us to keep this based on our infrastructure. We also need to limit the file upload size to something reasonable. 10MB is not reasonable and we shouldn't be have to rescale something from that size. I would say 2MB limit on file upload size is reasonable. Cool security for once means less work for me! Karl you confirm what the 'upload_max_filesize' is on the production server? I will adjust the file upload dialogue to display the max upload size allowed (pulled from the _SERVER['upload_max_filesize']). (In reply to comment #12) > We have too many places where > we'll need to know for sure that a photo is available Really? I can only think of places where we would show a picture if there is one, but if there isn't that's ok too. > Also, the web servers will not be able to make a call to an > external system to download the image, I figured the eclipse.org web server would just generate an html page that included an <img src="external url"> to include the picture. So the eclipse.org web server wouldn't need to call out to anything... ? (In reply to comment #15) > (In reply to comment #12) > > We have too many places where > > we'll need to know for sure that a photo is available > > Really? I can only think of places where we would show a picture if there is > one, but if there isn't that's ok too. I think there are lots of scenarios where this is not a good idea. Assume we're using the photos on our public pages. Without them being sourced locally we can't tell what has happened to the photos since the upload or what will show up on the page (porn because someone's site was hijacked, or domain expired and was bought?). E.g. board of directors page photos. Or what about correspondence of some kind that links a photo and the URL is not available or is inappropriate? I think it looks bad for us. At least if the image is in our control we can remove it immediately if we discover that it's inappropriate, but you can't take back a URL you mailed. Also for doing complicated page layout it is highly preferable to know if an image is available or not. Additionally, we have no control over page rendering speed if we're not hosting all of the content. I think in general we do not provide data sourced externally anywhere else. Or at least not in the same sense as this. We have a very successful implementation of photos used for corporate logos and I think we should stick to the same implementation plan here. For places where we don't care about whether or not the image is available we can just link to a php script that returns images from the DB by PersonID, much like the system used for logos. > > Also, the web servers will not be able to make a call to an > > external system to download the image, > > I figured the eclipse.org web server would just generate an html page that > included an <img src="external url"> to include the picture. So the eclipse.org > web server wouldn't need to call out to anything... ? I was saying that to use an URL as a source of an "upload" that it wouldn't work because the servers can't call off network. Just for the record you get the max file upload size by doing this:
ini_get('upload_max_filesize');
It is not stored in the super global $_SERVER.
In thinking about this some more, I just can't come up with a positive thing about allowing URL uploads other than that it saves us bandwidth and MAYBE that it would be slightly easier for small subset of users. Another negative: we can't control image size, either, something I forgot to mention earlier. I think the minimal bandwidth trade off is really outweighed by the negatives. (In reply to comment #18) > In thinking about this some more, I just can't come up with a positive thing > about allowing URL uploads other than that it saves us bandwidth and MAYBE that > it would be slightly easier for small subset of users. Another negative: we > can't control image size, either, something I forgot to mention earlier. I > think the minimal bandwidth trade off is really outweighed by the negatives. > And I can't type as fast as my brain. Make that "about allowing URLs instead of uploads". (In reply to comment #18) The biggest positive is that it allows users more control over their public presentation because it reduces the number of places that they have to remember to keep their picture up to date. It's the same reason that OpenID exists: to facilitate a better online experience. (In reply to comment #20) > (In reply to comment #18) > The biggest positive is that it allows users more control over their public > presentation because it reduces the number of places that they have to remember > to keep their picture up to date. It's the same reason that OpenID exists: to > facilitate a better online experience. To me that seems like a very minimal plus for a very minimal set of people and is outweighed by exposure. But if you think it's important, here's a proposal for a hybrid solution: We store images locally in the database and we serve them only locally. When someone uses an URL rather than a photo, then it takes until midnight that night to show up. We have a php job that runs in the middle of the night and stores the images in the database using wget to fetch the images (wget works). The Portal would have to maintain a table of last updates on the image field so that the script could check if it was updated in the last day. That script would cache the image when the URL changed, and once a month (or week or whatever) otherwise. (In reply to comment #21) > To me that seems like a very minimal plus We may just have to disagree then - I see controlling my own online identity to big a really big plus. > here's a proposal for a hybrid solution: This had turned into a policy question, so for now we'll just have photo uploads only. Mike and Janet and I will discuss the policy and then return with some more information. Eclipse has certain legal requirements to maintain contact information for committers and a few other classes of people. We do not have a legal requirement to maintain their picture. It would be a nice feature to have for our projects and committers, but we want to provide it in the right way. Today Karl added the 2 fields to the databases on staging/production and I checked the code into CVS. The picture feature will be live with the next roll out of the Portal. I am leaving this bug open until the REST API part of this bug is finished. This is waiting on the REST API Gabe, lets knock this out in in the next two weeks. It should take no more than an hour, I think. 1.5 years on and the REST API is not done. No one seems to be asking for it, either. Closing WORKSFORME for now. Please feel free to re-open if you disagree. 1.5 years on and the REST API is not done. No one seems to be asking for it, either. Closing WORKSFORME for now. Please feel free to re-open if you disagree. Released or closed for STAGING_324. Please see final comments for actual closure status. This message does not imply that any action was taken that has not already been described. |
