Photo Organizer

Right now there are three permissions -- public, private, and "protected", which equates to "public only to all of my clients"

This is pretty lousy; I can certianly envision scenarios where you'd want a client to only see stuff that's specific to that client. To do this now, you have to create separate accounts and mark clients for those specific accounts.

I'd like to see a more generic hierarchical user/group model. Only the photo owner can make changes to their images, but the permission model would break down as follows:

Permissions would be granted on a per-group basis, and individual users can be members of various groups. "Guest" access would just be another group, and would default to assigned.

A permission is inherited; so if "guest" is granted access to the top-level folder, they would be allowed to see everything below it unless a more restrictive permission was specified. This is sort of similar to unix permissions with the "sticky bit" turned on.

This gets a little tricky when talking about folders vs albums, as a user may not be allowed to browse the folder, but the image could be included in a public album. When viewing the image from the folder perspective, it would be disallowed, but from the album perspective, it would be allowed.

EDIT: see http://po.shaftnet.org/new_permission_model

Most database results are being indexed by position in a fixed array, rather than by column name. This may be slightly faster, but is hell to program around, especially when there can be twenty fields being returned.

* Convert all fetch_row() calls to fetch_assoc()

Secondly, using prepared statements would make the code a lot cleaner and eliminate the need to escape strings being passed in to the database. Unfortunately, this may require PHP 5.1 to pull off, depending on the maturity of the postgres bindings for earlier versions.

* Use prepared statements and SQL variables instead of inlined data.

RE-do the advanced search so it's more useful -- allow any field to be searched, not just title, caption, etc etc... then build the query on the fly. This is going to be complicated, but necessary...

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.

Currently the RAW settings are shared across all images. It would be nice if each image would contain with it the settings used to process the image. The problem is that the decoder often has defaults which change over time, and re-generating the same image can result in differences.

What we have now is a decent start, but it needs a backand (and instructions for making it all click together)

The eventual goal is to let us "search for images like this one" and have it JustWork(tm).

Right now GNU GIFT (http://www.gnu.org/software/gift/) looks like the best bet as a backend; I just need to figure out how to make it all work.

Note that we really need search result caching to make this usable with a large image database.

instead of <location id="23" />, we should say something like: <location id="23" name="downtown Nowhere, USA" />

for all non-textual datatypes.

Otherwise, we need to export the database tables for these values to mean anything, and this isn't currently possible.

1) Allow per-folder watermarks.
2) When "regenerating thumbnails" on bulk update, allow:
- existing watermark
- remove watermark
- new watermark
3) When performing an image rotation, preserve the existing watermarks.

Adding support for PTLens would be really nice -- we could automagically correct lens distortion etc as part of the image generation workflow.

PTLens needs the camera and lens model and the focal length to work properly.

I think it can use EXIF data directly.

right now "view counts" are part of the "photo" table.

It might be beneficial to split stats to a separate table.. we can track additional fields (views vs downloads vs ??) and also track it for each photo version etc.

We already copy over exif metadata to the preview images (#163) but we really need an explicit copyright notice and also a URL.

It would be nice to know at a glance whether or not we have a model release for a given person in a given photo.

releases are usually obtained in relation to specific events, so this should tie into the datebook.

To avoid having to do a page load/refresh for each of the sub-photo tabs (ie overview, technical, ratings, etc)

Eventually, I'd love to see the various sub-pages (eg rating.add/del/edit) also become "tabs" of the same master page; the majority of the code (and markup) on each page is duplicated. This may require us to use AJAX-type techniques however.

I'd still prefer basic photo navigation to be okay without javascript enabled.

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.

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.

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.

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.

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.

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.

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.

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.

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...)

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.

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