You are not logged in.
Lars-sh wrote:There should be php constants in settings.php - just as we'd done it for LDAP support some time ago.
I was considering attempting to do it in a way that would permit admins to choose their user config management system from eyeControl. That's part of the reasoning behind my abstraction layer idea.
Lars-sh wrote:s0600204, could you maintain this topic? I really like your work
I can try. And thanks.
Peter wrote:I'm not your boss but having it before 2013
I've started work on my abstraction-layer idea. Its proving to be easier to implement than I thought it would be. I'll try to get a usable version of it up on my oneye fork on Github soon.
you are the best!
Offline
you are the best!
Thank you.
I've created a page over on the wiki: http://wiki.oneye-project.org/development:mysql. What's written there is a possible way of doing it, but not the only way, nor the best. I (cautiously) open the floor to debate.
Offline
* Why do you give varchar fields a length?
* Shouldn't quotas be integer insetad of smallint? It's in byte!
* There might be additional values, such as maintainer, administrator, maintain, ...
Sorry, just need to minimize my list of delayed answers...
Best regards,
Lars Knickrehm
The oneye project.
Offline
Why do you give varchar fields a length?
Because although the varchar type is intended for use with variable-length strings, mySQL still needs to know a maximum length for those fields. (Presumably so it knows where the field ends and the next one begins.)
Shouldn't quotas be integer instead of smallint? It's in bytes!
Now you mention it, that would make more sense. 
There might be additional values, such as maintainer, administrator, maintain, ...
...yes...I'm not sure how I missed those out. I'll add them to the wiki page when I get time later. Done.
Thanks for the feedback!
Edit: To reflect changed status of wiki.
Last edited by s0600204 (2012-11-26 21:11:26)
Offline
A quick update on things:
Firstly, I think I may have completed the coding for my abstraction-layer idea. *Tries to think if I forgot anything.* Apologies for it taking so long. Anyway, using the code I have just finished, it is now possible for the oneye root user to switch methods via eyeControl, with oneye taking care of conversions between methods automatically. Here's a picture of the interface in eyeControl (the mySQL entry is just a dummy for now) (bigger image):
Of course, that's not much use without something to change over to, so within my fork on GitHub there's a branch containing a functional 'test' module that people may try out. It's nothing special, and the only difference between it and the default xml module is that it saves the files in a different (specially created) folder. Usual warnings about possible data loss apply, and it is not intended for use on production systems.
Now to start work on the mySQL module. I've updated the relevant page on the wiki with some specifics.
You can find the work done so far here: https://github.com/s0600204/oneye/tree/userConfig , and the test module here: https://github.com/s0600204/oneye/tree/userConfig-test . To try, just install as you would from Git normally.
Comments?
Offline
Dear s0600204,
it's been a long time since I last contributed to oneye, due to my business (meaning just "being busy" doing things, not "making money", unfortunately 
) and I still don't have the time to evaluate this modifications and contribute, for the moment. But I just wanted to write this short message to congratulate with you for all your efforts about this implementation and all the other oneye contributions you're making (sometimes I come and read some forum pages).
Hoping to come back again in the future to give my contribution too, I thank you (and of course Lars and the other developers) for continuing developing this amazing webos!
Have a nice day!
Luca
Offline
A quick update on things:
Firstly, I think I may have completed the coding for my abstraction-layer idea. *Tries to think if I forgot anything.* Apologies for it taking so long. Anyway, using the code I have just finished, it is now possible for the oneye root user to switch methods via eyeControl, with oneye taking care of conversions between methods automatically. Here's a picture of the interface in eyeControl (the mySQL entry is just a dummy for now) (bigger image):
http://s06eye.co.uk/img4forum/userconfig-sm.pngOf course, that's not much use without something to change over to, so within my fork on GitHub there's a branch containing a functional 'test' module that people may try out. It's nothing special, and the only difference between it and the default xml module is that it saves the files in a different (specially created) folder. Usual warnings about possible data loss apply, and it is not intended for use on production systems.
Now to start work on the mySQL module. I've updated the relevant page on the wiki with some specifics.
You can find the work done so far here: https://github.com/s0600204/oneye/tree/userConfig , and the test module here: https://github.com/s0600204/oneye/tree/userConfig-test . To try, just install as you would from Git normally.
Comments?
Why did you put The username as Primary key?
Offline
I just wanted to write this short message to congratulate with you for all your efforts
Thank you, your post brightened my day! It's nice to see you again on the forums.
Why did you put The username as Primary key?
Because on an oneye system, a username is unique - no two users may have the same one. Do you think something else should be the Primary Key? Or that we should auto-generate one?
With regards to maintainers, what do people think about moving the mngUsers field out into a separate table by itself: ie. using the maintainer field as a trigger so that if it is '1', then oneye looks at a second table laid out something like:
Maintainer | User
------------|-------
Maint_1 | User1
Maint_1 | User2
Maint_1 | User3
Maint_2 | User1and acquire the users that the maintainer maintains from there? I only think that the mngUsers field (which would probably end up being a comma separated list) would go out of bounds very easily and, rather than lengthen the field size, this may be a better solution.
We could probably do the same or similar for the maintain and group fields too.
Offline
Or that we should auto-generate one?
I'd like to have a generic key for all tables. Just to make sure we're able to change things as we like. The username should instead be marked as "unique" and "index".
We could probably do the same or similar for the maintain and group fields too.
Actually we should do so, don't we? But one more things to ids: instead of column "user.id" and "maintainer.id" we should use "user_id" "maintainer_id". That way we can simply do
user JOIN maintainer USING(user_id)PS: Happy to see you back here in the forums Luca. Don't know who of us is away from it more often 
...
Best regards,
Lars Knickrehm
The oneye project.
Offline
Firstly, Merry Christmas everyone! (Or whichever mid-winter celebration you observe.)
Secondly, I would like to announce this: A working mySQL module for oneye.
If you feel like giving it a go, then there are two ways you may go about that:
The first is simply to install from GitHub as you would normally, but using a system taken the relevant branch on GitHub.
The other way is to use this installer - just like the one used for the official releases, only patched so it installs a mySQL-ready system instead. Note: This installer will not update a pre-existing system.
Either way you choose to install oneye, you will also need to create a database and a user within mySQL (no tables are required, as they are created automatically). The user must be granted full access to that database (and, for security reasons, preferably that database only).
A walkthrough guide to all the above is planned, although if someone else wishes to write one (or contribute to the writing of one), I'd be very happy.
Comments, queries, concerns, suggestions and other feedback are more than welcome.
Have fun with it, and I hope you all enjoy your respective festivities!
Disclaimer: I do not take responsibility for data loss. If you attempt to apply this to a production system and lose all your data it is your own fault. I said it works, not that it is bug-free.
Edit: To add Installer method of installing.
Last edited by s0600204 (2012-12-30 22:46:17)
Offline
s0600204 wrote:Or that we should auto-generate one?
I'd like to have a generic key for all tables. Just to make sure we're able to change things as we like. The username should instead be marked as "unique" and "index".
Agreed. Names are no good Primary keys.
Also you think its ready to be pulled? Or did you pull it already?
Offline
Linking to the Pull Request: https://github.com/oneye/oneye/pull/17
Best regards,
Lars Knickrehm
The oneye project.
Offline
?!