- Delete old files (cat_search.php and cat_search.tpl) and his tab un add_core_tabs.inc.php
- Add search field and result in albums.tpl
- Separate js code from template
- Reuse data of albums.tpl for jqtree for the search algorithm
- Implementation of a new modal for modifying a user or guest
- Addition of a function to allow plugins to add a tab to the new user modal
- Fix bug: "badger-number" is updated when a user is added or deleted
- Fix bug: When the user who is editing has permissions to delete the user he is modifying, the delete icon is now displayed correctly
- Added a new api method for modifying the main user and generating a link to reset a password
- Passed $conf[‘webmaster_id’] in database configuration
* remove temporary functions ws_gallery_getSearch and ws_gallery_updateSearch
* split get_search_array into sub-functions to use them in web API
* use search_uuid as search_id instead of the numeric search.id : better privacy
* only the creator of the search can update it
* if a visitors tries to open the search of another user, it (the search) gets forked into a new search
* migration task to update activity.performed_by (with object_id) for logout action (was always user guest instead of the real user)
* activities: use the actual regrouped lines to list filter users (instead of performing a separate SQL query)
* at the end of the upload of after a maximum duration, move the photos from the lounge to their actual categories.
* do not invalidate user cache when photos are added in the lounge, thus avoiding to rebuild cache on every photo uploaded
* the lounge system activates itself only beyond 50k (by default) photo
It was already this default value for Piwigo installed on version 2.9+. This upgrade script is for Piwigo installed previously. The 0000 default year might cause issues with MySQL 5.7+
Every 1000 log entry inserted, Piwigo performs an history summarize.
The summarize process has also been optimized: no longer used column
history.summarized (no longer need to update it, which took a lot in time),
we now save the history_id_from and history_id_to in history_summary table.
This way we know from where to start on next summarize.
For now, for a simple performance reason, we keep column history.summarized,
because removing it may take a long time on huge tables. Once we will have
automatic purge on history, it will be safer to drop this column.
This will speed up user edit popin opening, by avoiding to search in history for the last user visit.
The column user_infos.last_visit_from_history true/false says if the last_visit has already been search in history (to avoid making it twice). I could have implemented the search of last_visit for all users in the migration task 149 but in case of many users and long history, it would have taken years to execute...
