> what is the functionality of "admin panenl"? Admins can view and manage all the models of the database. Add/Edit/Delete users/components, etc. Example screenshot of django adming panel: https://i.stack.imgur.com/SOnbL.png The rest of the users (the ones that you name as "owners" etc.) will be able to do content management through the the normal web interface of the application. > - "user management" functionality should be restricted to "user admins" (there is no need for a "sign up" functionality) So, only admins will be able to create new users? Will a user be able to request an account creation? > - "catalog management" functionality shuold be restricted to "catalog admins" What exactly to do you mean by catalog management? > - whoever creates a new spreadsheet, owns it. So, if there's something missing I can just add it? What permissions are requiered in order to add a new spreadsheet? For example, I'm "catalog admin" so I can create whatever component I want if it's missing and if I do so I'm automatically its owner. Do I get it correctly? Another question: Is it ok to state in my application that either custom user authentication or an LDAP service will be used and this will be decided/discussed on a later stage? Thank you. 2017-03-25 10:31 GMT+02:00 Alexios Zavras <zvr+eellak [ at ] zvr [ dot ] gr>: > Ηλίας Σταμάτης wrote [edited]: > > > no, it's not administrators only. > > > think of it as: > > > - few ("admins" as you call them) (let's say 10), can modify the > catalog > > > of simple components (adding zlib, openssl, etc.) > > > - some ("owners" if you will) (let's say 1000), can create complex > > > components and have permissions to modify their own components > > > - all ("viewers"?) (let's say 100.000) can view the information. > > > for them, even login may not be required. > > > > So to recap and see if I get it right: > > - Everybody can sign up. > > - If you have an account but not any permissions you can actually do > > nothing. > > - Admins will manage contents through the admin panel. (I'm planning to > use > > django that comes with a complete admin panel by default) > > - Owners will manage content through the normal web page (no access to > the > > admin panel for them). > > what is the functionality of "admin panenl"? > it's not a unique thing. > - "user management" functionality should be restricted to "user admins" > (there is no need for a "sign up" functionality) > - "catalog management" functionality shuold be restricted to "catalog > admins" > - "management of project X" functionality shuold be restricted to > "owners of project X" > - and of course, "CLIO management" (starting/stopping the server, > configuring the database, ...) should be restricted to "CLIO admins" > > that's a typical case where the bulk of all this is handled > by permission bits and group membership in LDAP > (user X is member of "user admins" and "catalog admins" > but not "clio admins", etc.). > only the "management of project X" access bits (who is owner of what) > has to be done internally in CLIO (cannot be done on LDAP). > > > > Follow-up questions: > > - An owner owns what? > > - How somebody get to be an owner? > > - Who gives permissions and on which case? > > all complex components are created and "owned" by someone. > > > think of it this way: each complex component has a table > of what it includes -- it's like a spreadsheet. > CLIO is a web system for online management of spreadsheets. > > - whoever creates a new spreadsheet, owns it. > - you can see all spreadsheets, you can change your spreadsheets, > but you cannot change *my* spreadsheets > - user and permission management (who can login and do what), > and catalog management (what can be entered in the spreadsheets) > are special functionalities (as is server management) > > > the "ideal" final result regarding permissions > would be that everything is totally configurable, > because whoever runs CLIO might decide differently on some cases > > - you can configure (upon software setup) to use LDAP or not > (i.e., whether user/permissions will be managed internally or externally) > - you can configure whether read-only access requires login or not > (maybe you want everythig viewable by defaul) > - you can configure whether anyone (once logged in) can create > new complex components or not (or have an access bit) > - you can configure whether new complex component are visible to all > by defauilt or not > - you can configure whether the access rights and visibilty > of components can be modified by the component owners or by the CLIO > admins > - etc. etc., > > but implementing all this is not mandatory, > as it's not the core of the project. > > some of it is obviously necessary (e.g. the idea of component owners > or catalog admins), but we can decide how much to extend towards the ideal > depending on how the rest of the work is going. > > > -- > -- zvr -- > -- +---------------------------+ Alexios Zavras (-zvr-) > | H eytyxia den exei enoxes | zvr [ at ] zvr [ dot ] gr > +-----------------------zvr-+ >
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Γενική λίστα αλληλογραφίας που απευθύνεται σε developers/contributors έργων ανοικτού λογισμικού - A general discussion list for developers/contributors of open-source projects, https://lists.ellak.gr/opensource-devs/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <opensource-devs+unsubscribe [ at ] ellak [ dot ] gr>.
