adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

[users & groups] Add user status "Editor" which is allowed to administrate all Photos and Albums, but not Plugins, Tools, Configuration (and Users) #1061

New Issue
Open
opened 2026-10-05 00:30:02 +02:00 by adam · 25 comments
adam commented 2026-10-05 00:30:02 +02:00
Owner
Copy link
Copy source

In an enterprise setting, it is important to be able to distinguish between content administrators and technical administrators.

Usually, distinguished, trained users will be responsible for content administration like setting up albums, uploading, renaming, deleting photos etc., while the IT department is responsible for the technical administration like configuration and maintenance, maybe also user management.

Currently, in Piwigo, you can only distinguish between Users who can do basically nothing except from viewing photos and Administrators who are allowed to mess up everything. Even with the Community plugin, Users can only create albums and upload photos, but they cannot rename or delete them.

An additional user status in-between these two would be useful. I would suggest to call it Editor (as in Wordpress) and give it access to the Administration panel sections "Photos" and "Albums".
Access to the "Users" section might be granted optionally to individual Editors, but all other sections stay accessible by Administators only.

In an enterprise setting, it is important to be able to distinguish between content administrators and technical administrators. Usually, distinguished, trained users will be responsible for content administration like setting up albums, uploading, renaming, deleting photos etc., while the IT department is responsible for the technical administration like configuration and maintenance, maybe also user management. Currently, in Piwigo, you can only distinguish between _Users_ who can do basically nothing except from viewing photos and _Administrators_ who are allowed to mess up everything. Even with the [Community plugin](https://piwigo.org/ext/extension_view.php?eid=303), _Users_ can only create albums and upload photos, but they cannot rename or delete them. An additional [user status](https://piwigo.org/doc/doku.php?id=user_documentation:use:features:user_status) in-between these two would be useful. I would suggest to call it _Editor_ (as in [Wordpress](https://wordpress.com/support/user-roles/)) and give it access to the Administration panel sections "Photos" and "Albums". Access to the "Users" section might be granted optionally to individual _Editors_, but all other sections stay accessible by _Administators_ only. <!-- github-sync-id:714669578 -->
adam commented 2026-10-05 00:30:03 +02:00
Author
Owner
Copy link
Copy source

Hi @chovyy

2 user status let you access the administration panel : webmaster and administrator. The difference between the 2 is that a webmaster is the technical administrator and the administrator is the content administrator, to use your own words. A simple administrator should not be able to: manage plugins or change configuration settings.

Note: we consider "users" as content, meaning a simple administrator can add/edit/remove users.

I think we could improve the distinction. For example, an administrator should not even see the menu [admin>configuration] or pages like [admin>tools>maintenance].

Hi @chovyy 2 user status let you access the administration panel : webmaster and administrator. The difference between the 2 is that a webmaster is the technical administrator and the administrator is the content administrator, to use your own words. A simple administrator should not be able to: manage plugins or change configuration settings. Note: we consider "users" as content, meaning a simple administrator can add/edit/remove users. I think we could improve the distinction. For example, an administrator should not even see the menu [admin>configuration] or pages like [admin>tools>maintenance]. <!-- github-comment-id:703588470 -->
adam commented 2026-10-05 00:30:04 +02:00
Author
Owner
Copy link
Copy source

Dear @plegall, thanks a lot for your answer.

To reduce the permissions of the existing Administrator user status might be an option. But some other questions come up with that:

  1. What a about those Piwigo users that rely on the current model?
  2. When "users" are considered content, are "simple" Administrators allowed to assign or revoke this status to/from others?
  3. What about the extensions? For some it might make sense to be usable/configurable by those "simple" Administrators, for others not.
Dear @plegall, thanks a lot for your answer. To reduce the permissions of the existing _Administrator_ user status might be an option. But some other questions come up with that: 1. What a about those Piwigo users that rely on the current model? 2. When "users" are considered content, are "simple" _Administrators_ allowed to assign or revoke this status to/from others? 3. What about the extensions? For some it might make sense to be usable/configurable by those "simple" Administrators, for others not. <!-- github-comment-id:707550574 -->
adam commented 2026-10-05 00:30:05 +02:00
Author
Owner
Copy link
Copy source

Something new on this one? Still a big issue for us.

Something new on this one? Still a big issue for us. <!-- github-comment-id:1024088902 -->
adam commented 2026-10-05 00:30:05 +02:00
Author
Owner
Copy link
Copy source

Hello,

Here the problem is that user statuses are "hard coded" : the code checks whether you are admin or webmaster and acts accordingly with specific things like :

  if (is_admin())
  {
    return true;
  }

and the statuses are even hard coded in the database where the status field is an ENUM :

desc piwigo_user_infos;
+-------------------------+------------------------------------------------------+
| Field                   | Type                                                 |
+-------------------------+------------------------------------------------------+
| user_id                 | mediumint(8) unsigned                                |
| nb_image_page           | smallint(3) unsigned                                 |
| status                  | enum('webmaster','admin','normal','generic','guest') |
| language                | varchar(50)                                          |
| expand                  | enum('true','false')                                 |
| show_nb_comments        | enum('true','false')                                 |
| show_nb_hits            | enum('true','false')                                 |
| recent_period           | tinyint(3) unsigned                                  |
| theme                   | varchar(255)                                         |
| registration_date       | datetime                                             |
| enabled_high            | enum('true','false')                                 |
| level                   | tinyint(3) unsigned                                  |
| activation_key          | varchar(255)                                         |
| activation_key_expire   | datetime                                             |
| last_visit              | datetime                                             |
| last_visit_from_history | enum('true','false')                                 |
| lastmodified            | timestamp                                            |
| preferences             | text                                                 |
+-------------------------+------------------------------------------------------+
18 rows in set (0,003 sec)

This reflects the way coders were thinking at that time :

  • Webmaster is for the local "super tech" who installs the Piwigo, tunes it and debugs it if needed
  • Administrator if for the "real user" :
    • Create albums hierarchy
    • Create users / groups for people who can view albums & pictures
    • Manage level of privacy
    • Manages all albums and all visitors
  • Visitors are for authenticated viewers
  • Generic is an other Visitor but with password locked (shared account) : the first time i see such thing

The idea that other people than admins (like, let's say photographers) could contribute was not in the global analysis of the need.
Same thing for the idea that an admin would be allowed only to manage only some albums and some specific groups of users.

This "choice" does not cover some of the frequent use cases involving contribution by less privileged persons :

If let's say a family owns a Piwigo instance they will have in the long run several cases needing this "contribution" approach :

  • Big family events (new year's Eve ? Traditional yearly meeting ?) where several members of the family will be invited to share their photos for all through the Piwigo instance
  • Weddings or big celebrations where the family will hire professional photographers and ask them to publish through the Piwigo instance
  • Professional shootings (for, let's imagine, LinkedIn, or an important birthday with a pro hired to take pictures, or if the gallery is owned by a top model...) where the photos could be delivered by the photographer through Piwigo

You dont want a photographer you hire to be able to create users in your instance, in fact you dont event want him/her to be able to manage ALL the albums and pictures.
You just want him/her to be able to upload pictures, manage the tagging and the photos properties (event mass-manage them, mass-upload them through various means) but in no way manage your users, even less create users, access history, use maintenance tools, manage other albums etc.

If the Piwigo is owned by a Photographer the problem is the same but with sub-contractors or employees : you dont want them to be able to be admins... just manage the pictures in the albums they are supposed to work on.

All these kind of "business cases" were probably not in the mind of creators at the time (which is not something we should blame them for... it was just not the target use they imagined at the time)

But the result is that, now, it would be complicated to switch from a hard coded approach to something more fine grained and "privilege based" approach instead of "status based" we have see currently in the code.
That would need a rather big amount of work. Something maybe between 30 days and 60 days of delicate and surgical work (including the reverse engineering part if it's made by somebody who does not know the internal subtleties of Piwigo) to bring this new "philosophy" to the software without breaking anything
And it would after that need a cautious campaign of tests to make sure nothing is broken.

I guess it would be complicated to do that without being paid for.

Regards,

Hello, Here the problem is that user statuses are "hard coded" : the code checks whether you are admin or webmaster and acts accordingly with specific things like : ```php if (is_admin()) { return true; } ``` and the statuses are even hard coded in the database where the status field is an ENUM : ``` desc piwigo_user_infos; +-------------------------+------------------------------------------------------+ | Field | Type | +-------------------------+------------------------------------------------------+ | user_id | mediumint(8) unsigned | | nb_image_page | smallint(3) unsigned | | status | enum('webmaster','admin','normal','generic','guest') | | language | varchar(50) | | expand | enum('true','false') | | show_nb_comments | enum('true','false') | | show_nb_hits | enum('true','false') | | recent_period | tinyint(3) unsigned | | theme | varchar(255) | | registration_date | datetime | | enabled_high | enum('true','false') | | level | tinyint(3) unsigned | | activation_key | varchar(255) | | activation_key_expire | datetime | | last_visit | datetime | | last_visit_from_history | enum('true','false') | | lastmodified | timestamp | | preferences | text | +-------------------------+------------------------------------------------------+ 18 rows in set (0,003 sec) ``` This reflects the way coders were thinking at that time : - Webmaster is for the local "super tech" who installs the Piwigo, tunes it and debugs it if needed - Administrator if for the "real user" : - Create albums hierarchy - Create users / groups for people who can view albums & pictures - Manage level of privacy - Manages all albums and all visitors - Visitors are for authenticated viewers - Generic is an other Visitor but with password locked (shared account) : the first time i see such thing The idea that other people than admins (like, let's say photographers) could contribute was not in the global analysis of the need. Same thing for the idea that an admin would be allowed only to manage only some albums and some specific groups of users. This "choice" does not cover some of the frequent use cases involving contribution by less privileged persons : If let's say a family owns a Piwigo instance they will have in the long run several cases needing this "contribution" approach : - Big family events (new year's Eve ? Traditional yearly meeting ?) where several members of the family will be invited to share their photos for all through the Piwigo instance - Weddings or big celebrations where the family will hire professional photographers and ask them to publish through the Piwigo instance - Professional shootings (for, let's imagine, LinkedIn, or an important birthday with a pro hired to take pictures, or if the gallery is owned by a top model...) where the photos could be delivered by the photographer through Piwigo You dont want a photographer you hire to be able to create users in your instance, in fact you dont event want him/her to be able to manage ALL the albums and pictures. You just want him/her to be able to upload pictures, manage the tagging and the photos properties (event mass-manage them, mass-upload them through various means) but in no way manage your users, even less create users, access history, use maintenance tools, manage other albums etc. If the Piwigo is owned by a Photographer the problem is the same but with sub-contractors or employees : you dont want them to be able to be admins... just manage the pictures in the albums they are supposed to work on. All these kind of "business cases" were probably not in the mind of creators at the time (which is not something we should blame them for... it was just not the target use they imagined at the time) But the result is that, now, it would be complicated to switch from a hard coded approach to something more fine grained and "privilege based" approach instead of "status based" we have see currently in the code. That would need a rather big amount of work. Something maybe between 30 days and 60 days of delicate and surgical work (including the reverse engineering part if it's made by somebody who does not know the internal subtleties of Piwigo) to bring this new "philosophy" to the software __without breaking anything__ And it would after that need a cautious campaign of tests to make sure nothing is broken. I guess it would be complicated to do that without being paid for. Regards, <!-- github-comment-id:1420536588 -->
adam commented 2026-10-05 00:30:06 +02:00
Author
Owner
Copy link
Copy source

Hello there,

I was curious about this question so i started to dig to see if my understanding was really correct...

And one try leading to the next my changes in the code started to look like something worth digging further... and here I am with a proposal.

It's still a work in progress or maybe just a proof of concept...

So here we are dear Piwigo team... if the change seems promising to you I can try to work under the directions you'll give me to transform this try into something clean, fully working and mergeable.

Kind regards,
P

Hello there, I was curious about this question so i started to dig to see if my understanding was really correct... And one try leading to the next my changes in the code started to look like something worth digging further... and here I am with a proposal. It's still a work in progress or maybe just a proof of concept... So here we are dear Piwigo team... if the change seems promising to you I can try to work under the directions you'll give me to transform this try into something clean, fully working and mergeable. Kind regards, P <!-- github-comment-id:1435701958 -->
adam commented 2026-10-05 00:30:07 +02:00
Author
Owner
Copy link
Copy source

Currently, there is some kind of "contributor-like" status where a user can add/edit/delete his photos, but not access the administration. Plugin Community does this job. To achieve this, the strategy in Community code is to be a fake admin on some very specific actions. This is a trick and it's far from perfect. To avoid this, @EddyLB has asked for a long time an intermediate status "contributor". I think it's a good idea to have it in Piwigo core but manage its permissions in plugin Community. A bit like we have images.latitude and images.longitude but they are handled by map plugins (Google Maps and OpenStreetMap).

What I don't want to go into is the "partial administrator" status, meaning "user Paul is administrator of album Christmas Party" and can edit users of group "Paul's friends". Piwigo is already enough complex to avoid this.

We work with many organizations and the feedback we get is that they have administrators and are fine with the "fake admin" status provided by the Community plugin for external contributors. When they need "partial administrators" their need can be filled by several instances of Piwigo (most of the time).

Currently, there is some kind of "contributor-like" status where a user can add/edit/delete his photos, but not access the administration. Plugin Community does this job. To achieve this, the strategy in Community code is to be a fake admin on some very specific actions. This is a trick and it's far from perfect. To avoid this, @EddyLB has asked for a long time an intermediate status "contributor". I think it's a good idea to have it in Piwigo core but manage its permissions in plugin Community. A bit like we have `images.latitude` and `images.longitude` but they are handled by map plugins (Google Maps and OpenStreetMap). What I don't want to go into is the "partial administrator" status, meaning "user Paul is administrator of album Christmas Party" and can edit users of group "Paul's friends". Piwigo is already enough complex to avoid this. We work with many organizations and the feedback we get is that they have administrators and are fine with the "fake admin" status provided by the Community plugin for external contributors. When they need "partial administrators" their need can be filled by several instances of Piwigo (most of the time). <!-- github-comment-id:1435735503 -->
adam commented 2026-10-05 00:30:08 +02:00
Author
Owner
Copy link
Copy source

Hello Pierrick,

Thanks for this in-depth answer... I think my proof of concept can do both and with the correct default setup nothing would change for users who are used to the current way.

By default we could just add a "Photographer" and/or "Editor" role with less privileges than Admin.

The advanced admin interface allowing to tweak (remove or add privileges) roles could even not be present by default (it could be a plugin) to completely replicate the current way.

Would you be so nice as to have a look at my PR and tell what you think and if it could have a chance to be merged after the required amount of rework / cleaning / improvements / etc ?

Kind regards,
P

Hello Pierrick, Thanks for this in-depth answer... I think my proof of concept can do both and with the correct default setup nothing would change for users who are used to the current way. By default we could just add a "Photographer" and/or "Editor" role with less privileges than Admin. The advanced admin interface allowing to tweak (remove or add privileges) roles could even not be present by default (it could be a plugin) to completely replicate the current way. Would you be so nice as to have a look at my PR and tell what you think and if it could have a chance to be merged after the required amount of rework / cleaning / improvements / etc ? Kind regards, P <!-- github-comment-id:1435737612 -->
adam commented 2026-10-05 00:30:09 +02:00
Author
Owner
Copy link
Copy source

Hi there, something new on this?

Hi there, something new on this? <!-- github-comment-id:1737446879 -->
adam commented 2026-10-05 00:30:10 +02:00
Author
Owner
Copy link
Copy source

Hello,
Piwigo 13.x has evolved from 13.6 to 13.8... i'll rebase my draft and try to code a plugin to manage permissions.
If some of you want to play with me on this, feel free to get in touch :)

Hello, Piwigo 13.x has evolved from 13.6 to 13.8... i'll rebase my draft and try to code a plugin to manage permissions. If some of you want to play with me on this, feel free to get in touch :) <!-- github-comment-id:1751674857 -->
adam commented 2026-10-05 00:30:11 +02:00
Author
Owner
Copy link
Copy source

Ok I created a special branch 13.x_FGP on my cloned repository : https://github.com/pvi-github/Piwigo/tree/13.x_FGP

You can install and test it : the behavior should be exactly the same as standard Piwigo. But if you play with table piwigo_status_privilege you can fine tune who can do what and add new kind of statuses with customized privileges like "editor" or "photographer" with access to all albums (or only some albums) but no admin privileges (no setup, no themes, no updates, no user management...)

I started to use it for my own needs... it still needs testing, feedback, improvement, etc before i can submit a decent pull request.

Ok I created a special branch 13.x_FGP on my cloned repository : https://github.com/pvi-github/Piwigo/tree/13.x_FGP You can install and test it : the behavior should be exactly the same as standard Piwigo. But if you play with table piwigo_status_privilege you can fine tune who can do what and add new kind of statuses with customized privileges like "editor" or "photographer" with access to all albums (or only some albums) but no admin privileges (no setup, no themes, no updates, no user management...) I started to use it for my own needs... it still needs testing, feedback, improvement, etc before i can submit a decent pull request. <!-- github-comment-id:1751769220 -->
adam commented 2026-10-05 00:30:12 +02:00
Author
Owner
Copy link
Copy source

Nota : I will also have to make user edition form dynamic.

At the moment possible statuses in UI are still hard coded in admin/themes/default/template/user_list.tpl

So you can change statuses in database to put "editor" or "guyfrommars" and it will work (provided the correct privileges are also setup for this in piwigo_status_privilege table) but you cannot do that yet with admin web interface .

As i'm always a bit scared at the idea of anoying users i tend to delay the moment when i touch UI

Nota : I will also have to make user edition form dynamic. At the moment possible statuses in UI are still hard coded in admin/themes/default/template/user_list.tpl So you can change statuses in database to put "editor" or "guyfrommars" and it will work (provided the correct privileges are also setup for this in piwigo_status_privilege table) but you cannot do that yet with admin web interface . As i'm always a bit scared at the idea of anoying users i tend to delay the moment when i touch UI <!-- github-comment-id:1751778306 -->
adam commented 2026-10-05 00:30:13 +02:00
Author
Owner
Copy link
Copy source

hi @pvi-github can you create a master fork version with your modification.
(install version master and modus master)
Kind regards,

hi @pvi-github can you create a master fork version with your modification. (install version master and modus master) Kind regards, <!-- github-comment-id:1752160357 -->
adam commented 2026-10-05 00:30:13 +02:00
Author
Owner
Copy link
Copy source

Hello,

I guess i can at least try... no idea at the moment about the differences between 13.x and master... it could be as well straight forward and as well a nightmare.

Give me at least 2 weeks for a first try... i have to make place for that time.

Hello, I guess i can at least try... no idea at the moment about the differences between 13.x and master... it could be as well straight forward and as well a nightmare. Give me at least 2 weeks for a first try... i have to make place for that time. <!-- github-comment-id:1752167737 -->
adam commented 2026-10-05 00:30:14 +02:00
Author
Owner
Copy link
Copy source

hi
My test error :
[mysql error 1071] Specified key was too long; max key length is 1000 bytes

CREATE TABLE piwigo_status_privilege(sp_idint(11) NOT NULL auto_increment,statusvarchar(100) NOT NULL,privilegevarchar(255) NOT NULL,contextvarchar(100) NOT NULL,target_id int(11) NOT NULL DEFAULT 0, PRIMARY KEY (sp_id), UNIQUE KEY status_privilege_UN (status,privilege,context,target_id), KEY status_privilege_status_IDX (status,privilege), KEY status_privilege_context_IDX (context), KEY status_privilege_target_id_IDX (target_id) ) ENGINE=InnoDB;

it's blocking to UNIQUE KEY ??? why ? what ? where ? etc...
what data should be added in: sp_id ? status ? privilege ? context ? target_id ?

Piwigo is formating Engine=MyISAM (look at piwigo_structure-mysql.sql)

Kind regards

hi My test error : [mysql error 1071] Specified key was too long; max key length is 1000 bytes `CREATE TABLE `piwigo_status_privilege` ( `sp_id` int(11) NOT NULL auto_increment, `status` varchar(100) NOT NULL, `privilege` varchar(255) NOT NULL, `context` varchar(100) NOT NULL, `target_id` int(11) NOT NULL DEFAULT 0, PRIMARY KEY (`sp_id`), UNIQUE KEY `status_privilege_UN` (`status`,`privilege`,`context`,`target_id`), KEY `status_privilege_status_IDX` (`status`,`privilege`), KEY `status_privilege_context_IDX` (`context`), KEY `status_privilege_target_id_IDX` (`target_id`) ) ENGINE=InnoDB;` it's blocking to UNIQUE KEY ??? why ? what ? where ? etc... what data should be added in: sp_id ? status ? privilege ? context ? target_id ? Piwigo is formating Engine=MyISAM (look at piwigo_structure-mysql.sql) Kind regards <!-- github-comment-id:1752362200 -->
adam commented 2026-10-05 00:30:15 +02:00
Author
Owner
Copy link
Copy source

Hello,

The indexes on the table i'm adding seem too big for MyISAM. Currently i'm using InnoDB for this table but maybe there's a better way.

But you should not have this error as i'm creating the table with InnoDB engine: it worked when i installed it from scratch.

Hello, The indexes on the table i'm adding seem too big for MyISAM. Currently i'm using InnoDB for this table but maybe there's a better way. But you should not have this error as i'm creating the table with InnoDB engine: it worked when i installed it from scratch. <!-- github-comment-id:1752444968 -->
adam commented 2026-10-05 00:30:16 +02:00
Author
Owner
Copy link
Copy source

ok @pvi-github now I am changing in varchar(132) in privilege with MyISAM

Now I am testing that maybe for the first admin user, I cannot create a tag and not modify the themes configuration

its ok ?

ok @pvi-github now I am changing in varchar(132) in privilege with MyISAM Now I am testing that maybe for the first admin user, I cannot create a tag and not modify the themes configuration its ok ? <!-- github-comment-id:1752702894 -->
adam commented 2026-10-05 00:30:17 +02:00
Author
Owner
Copy link
Copy source

Hello,

Seems ok.

Here is the current default setup :

$default_statuses['webmaster'][]='access_front';
$default_statuses['webmaster'][]='add_photos';
$default_statuses['webmaster'][]='do_maintenance';
$default_statuses['webmaster'][]='extend_for_templates';
$default_statuses['webmaster'][]='manage_albums';
$default_statuses['webmaster'][]='manage_batch_global';
$default_statuses['webmaster'][]='manage_batch_unit';
$default_statuses['webmaster'][]='manage_categories';
$default_statuses['webmaster'][]='manage_cat_options';
$default_statuses['webmaster'][]='manage_cat_perm';
$default_statuses['webmaster'][]='manage_comments';
$default_statuses['webmaster'][]='manage_configuration';
$default_statuses['webmaster'][]='manage_groups';
$default_statuses['webmaster'][]='manage_menus';
$default_statuses['webmaster'][]='manage_picture_coi';
$default_statuses['webmaster'][]='manage_picture_formats';
$default_statuses['webmaster'][]='manage_plugins';
$default_statuses['webmaster'][]='manage_ratings';
$default_statuses['webmaster'][]='manage_site';
$default_statuses['webmaster'][]='manage_sync';
$default_statuses['webmaster'][]='manage_themes';
$default_statuses['webmaster'][]='manage_updates';
$default_statuses['webmaster'][]='manage_users';
$default_statuses['webmaster'][]='modify_photo';
$default_statuses['webmaster'][]='notify_albums';
$default_statuses['webmaster'][]='notify_users';
$default_statuses['webmaster'][]='rank_images';
$default_statuses['webmaster'][]='see_admin_help';
$default_statuses['webmaster'][]='see_history_stats';
$default_statuses['webmaster'][]='see_user_activity';

$default_statuses['admin'][]='access_front';
$default_statuses['admin'][]='add_photos';
$default_statuses['admin'][]='manage_albums';
$default_statuses['admin'][]='manage_batch_global';
$default_statuses['admin'][]='manage_batch_unit';
$default_statuses['admin'][]='manage_categories';
$default_statuses['admin'][]='manage_picture_coi';
$default_statuses['admin'][]='manage_picture_formats';
$default_statuses['admin'][]='manage_ratings';
$default_statuses['admin'][]='modify_photo';
$default_statuses['admin'][]='notify_albums';
$default_statuses['admin'][]='rank_images';
$default_statuses['admin'][]='see_admin_help';
$default_statuses['admin'][]='see_history_stats';
$default_statuses['admin'][]='see_user_activity';
Hello, Seems ok. Here is the current default setup : ```php $default_statuses['webmaster'][]='access_front'; $default_statuses['webmaster'][]='add_photos'; $default_statuses['webmaster'][]='do_maintenance'; $default_statuses['webmaster'][]='extend_for_templates'; $default_statuses['webmaster'][]='manage_albums'; $default_statuses['webmaster'][]='manage_batch_global'; $default_statuses['webmaster'][]='manage_batch_unit'; $default_statuses['webmaster'][]='manage_categories'; $default_statuses['webmaster'][]='manage_cat_options'; $default_statuses['webmaster'][]='manage_cat_perm'; $default_statuses['webmaster'][]='manage_comments'; $default_statuses['webmaster'][]='manage_configuration'; $default_statuses['webmaster'][]='manage_groups'; $default_statuses['webmaster'][]='manage_menus'; $default_statuses['webmaster'][]='manage_picture_coi'; $default_statuses['webmaster'][]='manage_picture_formats'; $default_statuses['webmaster'][]='manage_plugins'; $default_statuses['webmaster'][]='manage_ratings'; $default_statuses['webmaster'][]='manage_site'; $default_statuses['webmaster'][]='manage_sync'; $default_statuses['webmaster'][]='manage_themes'; $default_statuses['webmaster'][]='manage_updates'; $default_statuses['webmaster'][]='manage_users'; $default_statuses['webmaster'][]='modify_photo'; $default_statuses['webmaster'][]='notify_albums'; $default_statuses['webmaster'][]='notify_users'; $default_statuses['webmaster'][]='rank_images'; $default_statuses['webmaster'][]='see_admin_help'; $default_statuses['webmaster'][]='see_history_stats'; $default_statuses['webmaster'][]='see_user_activity'; $default_statuses['admin'][]='access_front'; $default_statuses['admin'][]='add_photos'; $default_statuses['admin'][]='manage_albums'; $default_statuses['admin'][]='manage_batch_global'; $default_statuses['admin'][]='manage_batch_unit'; $default_statuses['admin'][]='manage_categories'; $default_statuses['admin'][]='manage_picture_coi'; $default_statuses['admin'][]='manage_picture_formats'; $default_statuses['admin'][]='manage_ratings'; $default_statuses['admin'][]='modify_photo'; $default_statuses['admin'][]='notify_albums'; $default_statuses['admin'][]='rank_images'; $default_statuses['admin'][]='see_admin_help'; $default_statuses['admin'][]='see_history_stats'; $default_statuses['admin'][]='see_user_activity'; ``` <!-- github-comment-id:1752717866 -->
adam commented 2026-10-05 00:30:18 +02:00
Author
Owner
Copy link
Copy source

hi @pvi-github can you create a master fork version with your modification. (install version master and modus master) Kind regards,

hello @klaoun here you are for the basic cherry picking : https://github.com/pvi-github/Piwigo/tree/14.x_FGP

branches 13.x_FGP and 14.x_FGP are nearly aligned. 14.x_FGP is slightly in advance because (if i'm not mistaken) I solved the "Specified key was too long" problem.

Now i need to adapt hard coded templates (maybe i'll need one more table to list statuses : webmaster, admin, editor... guest).

The step after would be to create a plugin to fine tune privileges for each status (without the need to play manually with values in database).

In most cases this plugin would not be necessary. But for specific needs it would allow to grant (or remove) specific privileges for statuses (including defining privileges only for specific albums for example).

> hi @pvi-github can you create a master fork version with your modification. (install version master and modus master) Kind regards, hello @klaoun here you are for the basic cherry picking : https://github.com/pvi-github/Piwigo/tree/14.x_FGP branches 13.x_FGP and 14.x_FGP are nearly aligned. 14.x_FGP is slightly in advance because (if i'm not mistaken) I solved the "Specified key was too long" problem. Now i need to adapt hard coded templates (maybe i'll need one more table to list statuses : webmaster, admin, editor... guest). The step after would be to create a plugin to fine tune privileges for each status (without the need to play manually with values in database). In most cases this plugin would not be necessary. But for specific needs it would allow to grant (or remove) specific privileges for statuses (including defining privileges only for specific albums for example). <!-- github-comment-id:1756338289 -->
adam commented 2026-10-05 00:30:19 +02:00
Author
Owner
Copy link
Copy source

Nota bene : i tried to mimic current behavior for Wembaster & admin but if i missed something tell me and i'll adapt the default values set up at install/upgrade.

_Nota bene_ : i tried to mimic current behavior for Wembaster & admin but if i missed something tell me and i'll adapt the default values set up at install/upgrade. <!-- github-comment-id:1756344416 -->
adam commented 2026-10-05 00:30:20 +02:00
Author
Owner
Copy link
Copy source

Yes normally the first to register when creating it must have all the rights of use (status webmaster).
But it lacks complete management of menu tags and themes.
For guests it's okay (guest status).
For administers, they access the administration with their account but only on photo, album, user, tags and groups content (admin status).
For register users, no administration access but can access private content and therefore access to its content (visitor status)

Kind regards

Yes normally the first to register when creating it must have all the rights of use (status webmaster). But it lacks complete management of menu tags and themes. For guests it's okay (guest status). For administers, they access the administration with their account but only on photo, album, user, tags and groups content (admin status). For register users, no administration access but can access private content and therefore access to its content (visitor status) Kind regards <!-- github-comment-id:1757556315 -->
adam commented 2026-10-05 00:30:21 +02:00
Author
Owner
Copy link
Copy source

ok thanks

ok thanks <!-- github-comment-id:1757637578 -->
adam commented 2026-10-05 00:30:21 +02:00
Author
Owner
Copy link
Copy source

hi @pvi-github in the 13.fgp when you add a user with generic status and then log in.
the user can log in but it gives an error.

kind regards

hi @pvi-github in the 13.fgp when you add a user with generic status and then log in. the user can log in but it gives an error. kind regards <!-- github-comment-id:1760692136 -->
adam commented 2026-10-05 00:30:23 +02:00
Author
Owner
Copy link
Copy source

I just fixed https://github.com/pvi-github/Piwigo/tree/14.x_FGP for this problem.

I'll backport the fix to 13.x_FGP right now

Thanks for your tests and feedback

I just fixed https://github.com/pvi-github/Piwigo/tree/14.x_FGP for this problem. I'll backport the fix to 13.x_FGP right now Thanks for your tests and feedback <!-- github-comment-id:1763333821 -->
adam commented 2026-10-05 00:30:24 +02:00
Author
Owner
Copy link
Copy source

It's done if I'm not mistaken.

It's done if I'm not mistaken. <!-- github-comment-id:1763365258 -->
adam commented 2026-10-05 00:30:25 +02:00
Author
Owner
Copy link
Copy source

You can modify admin.tpl & intro.tpl to Your needs.

This will show menu items for the specified user only, hide from others.

Piwigo_mod

webmaster-user = The Webmaster user.

 {if $USERNAME == "webmaster-user"}
  <dl>
		<dt><i class="icon-users"> </i><span>{'Users'|@translate}&nbsp;</span><i class="icon-down-open open-menu"></i></dt>
		<dd>
      <ul>
        <li><a href="{$U_USERS}"><i class="icon-user-add"></i>{'Manage'|@translate}</a></li>
        <li><a href="{$U_GROUPS}"><i class="icon-group"></i>{'Groups'|@translate}</a></li>
				<li><a href="{$U_NOTIFICATION_BY_MAIL}"><i class="icon-mail-1"></i>{'Notification'|@translate}</a></li>
      </ul>
		</dd>
  </dl>
  <dl>
		<dt><a href="{$U_PLUGINS}" class="admin-main"><i class="icon-puzzle"> </i><span>{'Plugins'|@translate}&nbsp;</span></a></dt>
  </dl>
  {/if}

Or You can modify PHP template files.

  • maintenance.php
  • plugins.php
  • stats.php
  • site_update.php
  • updates.php
  • user_list.php
if ('webmaster' != $user['status']) {
  $url = "admin.php";
  header("Location: " . $url);
  exit();
}
You can modify admin.tpl & intro.tpl to Your needs. This will show menu items for the specified user only, hide from others. ![Piwigo_mod](https://github.com/user-attachments/assets/cdcddd10-3657-4e5f-97b2-70fd3249c342) webmaster-user = The Webmaster user. ``` {if $USERNAME == "webmaster-user"} <dl> <dt><i class="icon-users"> </i><span>{'Users'|@translate}&nbsp;</span><i class="icon-down-open open-menu"></i></dt> <dd> <ul> <li><a href="{$U_USERS}"><i class="icon-user-add"></i>{'Manage'|@translate}</a></li> <li><a href="{$U_GROUPS}"><i class="icon-group"></i>{'Groups'|@translate}</a></li> <li><a href="{$U_NOTIFICATION_BY_MAIL}"><i class="icon-mail-1"></i>{'Notification'|@translate}</a></li> </ul> </dd> </dl> <dl> <dt><a href="{$U_PLUGINS}" class="admin-main"><i class="icon-puzzle"> </i><span>{'Plugins'|@translate}&nbsp;</span></a></dt> </dl> {/if} ``` Or You can modify PHP template files. * maintenance.php * plugins.php * stats.php * site_update.php * updates.php * user_list.php ``` if ('webmaster' != $user['status']) { $url = "admin.php"; header("Location: " . $url); exit(); } ``` <!-- github-comment-id:2481750329 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#1061