Photo Organizer

Users would ahve to explicitly enable "adult" content in order for that to show up in searches, rss feeds, etc etc.

Need to work through use cases of this more carefully.

Only location in advanced text is not work, others works fine.

I can't find the meaning of ||| by google. But I change ||| to || in file search.text.advanced.php at line 172

$sql_search_string['location'] = build_sql_search_string($keywords['location'], "(view_location.place||view_location.city||view_location.state||view_location.country)");

and change view_location all columns NULL value (if any) to '' by sql command, then it seems work.

Here is the sql command to change view_location

create view view_location as
select location.identifier, location.place, location.city,
COALESCE ( (select value from state where state.identifier=location.state), '' ) as state,
(select value from country where country.identifier=location.country) as country,
users, last_modified_date,
latitude, longitude, private
from location;

In tab My Folders or My Datebook, logged in user name displayed instead of owner user name under 'I am a client of the following users', nevertheless the link is correct. Here is my quick and dirty solution.

--- include/contacts.php.orig
+++ include/contacts.php
@@ -117,7 +117,8 @@
$owner = "";
}

- $all_subscribed_users = pg_query($database, " select identifier, users, last_name, first_name, date_of_creation, value from view_client where client='$my_user_id' and status!='4' $owner ");
+ $all_subscribed_users = pg_query($database, " select view_client.identifier, view_client.users, view_contact_info.last_name, view_contact_info.first_name, view_client.date_of_creation, view_client.value from view_client, view_contact_info where view_client.client='$my_user_id' and view_client.users=view_contact_info.identifier and status!='4' $owner ");
$num_of_subscribed_users = pg_num_rows($all_subscribed_users);

if ($num_of_subscribed_users) {

This will be a placeholder for the various ideas I have for reworking parts or all of PO's UI. Ideas that are fleshed out can be moved into their own tickets for actual implementation.

* AJAX-ish tabs on the photo page
- instead of a separate page reload for each tab, load all tab info at once and let the UI manage paging.
* Client-side sorting of all tabular data
- eg folder/album listings
* Dynamic client-side pagination of the slide view
- "dump" all slides at once, and let client-side manage their pagination?
- Probably can't sort this way though
* Lightbox-esque view of photos
- Intended for guest access, hiding details of photos.
- Slideshow capabilities
- Easy navigation (eg using left/right arrows)
* Replace ad-hoc toolbars with more coherent ones
* Replace hackish button/checkbox theming script with something saner.
* Replace wz_tooltips and js_calendar with better integrated stuff.
* Modal login/password form
- pops up on top of current page
- Can force current page to reload afterwards
- What to do about 401/403 errors?
* Replace all "confirmation" pages with modal dialogs.

I'm leaning towards Query and jQueryUI for actual implementations.

Initial implementation will probably require current themes to be taken out back and shot.

We need to enforce that rule to prevent the DB from going nuts.

Either via SQL:

1) Trigger to test that parent != id
2) the (folders|albums)_and_sub(folders|albums) function needs to abort if it sees it

or in PHP:

3) Test the values in the php pages [[ (album|folder).(add|edit).2.php ]] and kick back an error.

I don't think there's another way to mangle things.

This can result in a DoS.

It doesn't do any harm, it just bugs if it happens.

If you fill in user name and password and then realize, you don't want the preset language... Switching to another language clears out user name and password and you have to write them again.

Of course, this won't happen often to a new user because it trains to look first after the language, but... I would still call it a bug, even if not really major.

Rock on
Eckhard

PO has hooks for an external authentication mechanism. Once the user is authenticated it creates whatever's needed for local use.

OpenID seems to be a natural offshoot of this; not too useful for a single-user system but it would be quite handy for a site wanting to piggyback onto another user.

In effect, this would merge datebook entries with the folder/album hierarchies.

I don't know if this is ultimately a good idea or not, but I've noticed that a majority of folders are keyed off specific date(s).

It has ramifications for the permission system (do we tie folders to clients, or rely on datebook events?)

It would also allow us to sort folders based on "event date" rather than "date added/changed" which is frankly far more useful for my purposes.

Some programs like Raw Therapee creates a file to store all metadata to convert a raw file to a jpg file. To repeat the convert process (with or without slightly differences) it would be nice if I'm able to store such metadata with variants at the side of the original picture.

From other programs that storing data in a database, it would be possible to read out the data from the DB and storing metadata into xml-files and backwards.

if all pages are explicit redirects, we can use POSTs everywhere and still have navigability.

If we have a GPS tag, the odds are its timestamp is going to be more accurate than what the camera thinks.

Unfortunately, the GPS timestamp is reported in UTC. All dates in PO are stored sans timezone, but the odds are that you're not in GMT. So we'd need to add some sort of local time zone setting and convert the date/times as appropriate.

I think it would be a cool feature to make PO spatial enabled. I mean that it would be possible to use gps data (geolocated images) to search for "photo taken near some point" or "all the photo taken near some street". Or simply to create an interface a la panoramio for look/find for pictures. It should be not to difficult to implement.

> 'last X photos' could easily be implemented as a wrapper in include/site.php, much like the site_display_random_photos() function already is.

It's possible that you might not have a given piece of equipment (eg lens or body) any more, so add a flag to the equipment tables to have them ignore certian rows.

(This is precipitated by one of my lenses being broken in two; I plan to buy an identical replacement, but it'll have a different serial number...)

User would:

* Select some images
* Click on 'add keyword'
[ Window pops up prompting for a keyword ]
* User types in new ketword', clicks 'ok'
[ POST is sent in the background that adds a new keyword ]
* User is happy and sends PO developers lots of money.

A running statistic of most used focal lengths (can be expanded to any EXIF/IPTC property like most used lens, flash usage and so on).

Something like this: http://billigites.blogspot.com/2005/06/focal-length-statistics.html

Invaluable to decide which lens to buy next. :-)

My wife asked for this, actually.

Basically, it would be handy to assign an album to be a "child" of a given folder, instead of having a totally separate hierarchy.

I don't think the converse would be as useful.

This one probably relates to other search-related Feature Requests. But to be specific.

When I'm displaying my Profile pages, I can see for example how many photos were shot with a specific lens, how many were shot with a certain camera, how many were shot on a particular film. But there is no quick way to display the photos matching the one criterion - it does not need to be a complex search, it should display photos only according to the one condition. It could be accessed by a simple link next to the count of photos (or clicking the count number itself?)

Thanks a lot

Jiri Vasina

It would need a CAPTCHA or the like, to prevent spam..

This way people can easily contact a PO user, without having to publish real contact information.

It would be great if PO could make use of automated documentation tools such as Doxygen or PHP-Documentor.

It is now a time consuming task to start understanding the inner workings of PO as you need both an overview of the database schema and the logic in the code.

With a bit more documentation about the files and the routines in PO solving bugs or contributing code will become much easier.

I'm very happy to have an automatic slideshow in photoview with the options: interval in seconds (1, 3, 5, 10, 15, 30), start and stop button. The slideshow should start at the current photo after pressing the start-button and automatically stop at the last photo of the current folder/album or by pressing the stop-button.

This way individual versions and scaled resolutions can be given appropriate rights; If we have the individual files with fine-grained permissions, then we can do away with the 'original' field altogether, and the 'access' field can be inferred from these settings (via a DB stored procedure)

The original can be granted to be 'private' or 'protected', for example, while the watermarked preview is 'public', the non-watermarked preview is 'protected', and the thumbnail is 'public'.

If we have the individual files with fine-grained permissions, then we can do away with the 'original' field altogether.

If the viewer can access the thumbnails, then they can see the image on the browser list. If the viewer can access *any* of the preview images, the thumb links to the best-quality preview image. (ie resolution &| watermarking..). While looking at the preview, if they have access to the original, let them have it.

Right now, it's:

thumb = raw -> scale -> colorspace (+extras) -> sharpen
prev = raw-> scale -> colorspace (+extras) -> sharpen -> watermark

IT would be REALLY nice if we could create customized processing paths; that is to say:

type_1 = raw -> scale -> b&w -> normalize -> sharpen
type_2 = raw -> scale -> add_border, add_text -> sharpen

This could either be on-demand, or automatic on uploads.

http://www.sai.msu.su/~megera/wiki/Tsearch_V2_Readme

It's supposedly been part of the "core contrib" postgresql stuff since v7.4

This would let us perform a search on specific keywords across *all* indexed fields simultaneously.

it would be nice if we could show the disk usage for a given album/folder, including all of its subfolders.

Now that we have the files and their sizes stored in the database, this should be easy enough.

for example, folder #602 contains 363 images, taking up 2133MB of disk space.