I know you stated that you wanted to wait, but I wanted to pass some info on that may or may not get done faster.

Is there a way that I can go ahead and give siggn a seperate access because there are alot of people that would like to config theirs withou having admin access

something I can do? I know your busy

There is not separate configs per person in siggen, it was not designed that way
If one person changes the look, it changes it for everyone

that would require one heck of a database override .... but .. is possable maybee ... if zanix dosent mind ial have a poke arround over the next week and see what i can come up with maybee it could be a new feature for him lol

edit:
I went back and looked more at the siggen program, more as a person that is not a programmer, so I could think how this could be considered

1. looking for a way to seperate what is needed just for the admin and what could be used for the member.
a. have the save and load dir's seperate, font paths set for admin
b. the rest of the util is controlled by the guild member

2. how can this be done without everyone having a seperate login?
a. dont
b. guild password is one, if you cannot trust your guild member then they dont need the password, or you can set the permission for them not to connect.
3. how can you make sure the person is only working on "their" char
a. without having seperate longin or specific checks you cannot
b. have it only save if profile is just uploaded. check is made to make sure that the person doing the edit and check to see if name is in the guilds roster, database check.
c. if sig is saved to roster then could it be checked for the member since it is the admin that can setup the update sig on guild update?
4. this may not be in order, but there is already a spot to pick the sig you want to view.
a. make this to choose the sig to work on

I could go on for the thoughts that I am having. I am not a programmer, but I have had the privilage to work with some, and I realize that sometimes just writing down what I would look for can sometimes help show the programmer what I am looking at and gives them a better way to explain how it could or couldnt be done.

Gator81,

The way you wrote down your analysis is actually the way a programmer works. Its part of the 'brainstorming' way of thinking.

True is that user identification will be asked and needed in the future.
To make this work for the entire roster, the entire roster should be considered; otherwise a comparable implementation will have to be re-invented for every nearly identical identification question.

I tend to say, first of all, the new roster model, as designed and present in V2 has to be taken out of dev/beta state - and settle down for a while.

Then, some sort of identification interface should be designed.
It exposes its function (methods?!) to the roster itself, like the uploading part, and the addons.
Every Addon project manager can then take advantage of it as he pleases, without disturbing the ident. UI to the end user - or admin.

Having one ident. interface makes it also easier to integrate the roster in an existing CMS system - which often already proposes an auth system.

Just my 2 cents.

I need to remember that there is a time and a place with everything and that I should be more patient with request beyond the core.
The way I seem to take what was being said is that it cannot be done unless it is a stand alone program because everyone would need their own login. I am sure later that it will be done

I might (just might) look at this this weekend. Siggen currently already supports two config profiles - sig and avatar. I've looked at that in the past, and it shouldn't be too hard to increase that number.

no it wouldent just need to add a new siggen profile for each user depected by there name ex: ulminia@zangarmarsh-us insted of signature or avatar lol

Which sounds similar to this idea I had for siggen 0.26. I got it working in the end too, all thanks to Zanix and Pleegwat.

EDIT: Meant to link to the post, that would help :s. so here it is!

nice!!!!

What you need is a user profile or something to configure those individual settings, that is best done in modifiying an existing profile database like your forum, cause you want your users to do the work themselves. Otherwise you end up administrating yourself to pieces.

To give you an example, I once wrote a hack that extended my phpbb2 forum profile settings for the name of the users main char, than screens my forum database on demand for users not having any avatars, if the avatar column in the user table for a user was empty it would check if the char name would be found in the roster tables, or if not check if it was equal username there, if the result was positive than fill it with a link pointing to the siggen avatar. But that is all outside of siggen and you can not do this without deeper php knowledge.

What would be needed first would be to publish different alternate backgrounds to the user somewhere, let the user choose it and make the choice persitant, meaning save it and important, give an option to change what was choosen.

Than isolate the final background pic variable in the siggen code and make that accessible as an overrideable varible for a called instance, (that is once you run the code or plain text: When the browser requests a picture ) You would have to specifically link the variable to the user: Something like this

have username ? than -> check for value of username.background.pic in user profile database -> if username.background.pic value does not exist than use default, else use value of username.background.pic .

Basically if you isolate all picture parameters as varibles upfront in a central storage location like a separate override file where they can be easily modified than such hacks are relatively easy, the problem is that this was never intended and the varibles are all over the place. You would have to rewrite siggen. And if you are not fluent in php than just forget about the idea.

I looked at siggen's code weekend before last. Extra config profiles (besides the default sig+ava) work. However there is no interface, and siggen's code hurts my head too much to try to write one.

Assuming this feature would be available in the interface, it would be possible to allow any member to configure this by allowing access to the siggen config using the guild- or officer pass. However every member/officer would have access to all profiles, because there is no real user management.

PleegWat wrote:and siggen's code hurts my head too much to try to write one.

Mine too, I wrote this when I was just starting in php

PleegWat wrote:Assuming this feature would be available in the interface, it would be possible to allow any member to configure this by allowing access to the siggen config using the guild- or officer pass. However every member/officer would have access to all profiles, because there is no real user management.

Indeed

so for this idea

have username ? than -> check for value of username.background.pic in user profile database -> if username.background.pic value does not exist than use default, else use value of username.background.pic .

this would be more that you have more of a choice for preset sigs/ava's? Just to make sure that I am understanding, this would be a option for the person to click a box to choose that they want 1 of 4 presets?

I would see that it would give more options without giving the permission, but I guess my question would be this:

why have a permission for siggen? Dont you already have a setting to allow someone to do a change? It already has a setting that seems to check that the person is in the guild on the specific server before letting the change.

Siggen is a great piece of work, but why not have it do this? have it make sure that your part of the guild and server, let them do their changes but only allow the change saved when they update their profile. Then their sig/ava could be saved as a .bmp file or whatever and loaded that way.

Just something to think about

Either you are not understanding us, or we are not understanding you.

In this version of roster, it is NOT POSSIBLE to allow members to do anything for themselves.
It is possible to allow members to configure something for everyone, or for any member (not just themselves)
It is possible to allow members limited configurability by offering a specific link to people. roster/char/siggen/type=azymyrta/member=azymyrta could produce a different sig than roster/char/siggen/type=azy2/member=azymyrta.
However, roster/char/siggen/type=azymyrta/member=pleegwat would produce the same sig for a different member, and if any member can modify any type they can modify all types. This follows directly from there being no real user authentication.

If this does not answer your question, please ask a specific question without pointing back to your earlier posts.