Feature Request: Server Storage of Client State

Submitted by clavileno on 2007-06-18

I'm sorry if I have misunderstood, but it seems that the customisation of the display of the client (in my case Windows client) is being stored locally on the PC?

What I would like to have are default application preferences that are automatically rolled out to every client at the time they connect, and then user customisations (if allowed - we'd like to restrict this on a per-user basis) of these stored back on the server against the identity of the logged-in user.

The reasons for this are two-fold:

1. The benefit of a client-server system like this is the ability of a user to sit at any PC and connect - we just let them click-download-install the client on any PC they're sitting at. However their preferences need to follow them for this to be useful.

2. For non-technical users (I have many) we know that the application will be pre-configured in the most useful way for them on each login, so we can then issue simplified user instructions which suit the way we've configured the app.

Any support for this from others?

Edited to add: having played some more, it is obvious to me that this would have to include filters, so to set up a new user the administrator could

This ideally needs to be generalised some more, so that we could set up default filters using tokens for each folder we create. So, for instance, we might want to set up the filter "Assigned to Me" to always default to "Assigned To" = %logged-in-user% or somesuch. I appreciate this can't just be a global default (not every folder has an "Assigned To" attribute, for instance), but it is hard to roll this out to others without having to do lots of manual customisation, which could get impossibly complex when we have, say, more than 10 users.

Yes, all customizations including the columns and filters in the issues list, column widths and in the future also subscriptions and notifications are stored in a local configuration file (in ~/.local/share or Application Data on Windows).

A much simpler approach, without storing settings on the server side, would be to simply install a pre-defined configuration file along with the client application. That file could be simply copied from the administrator's PC after he sets up the views, filters, etc., or perhaps even generated by using some simple tool. So when a user installs the client application, he already has all settings configured the way you want.

And to answer your second questions - filters are not stored per folder, but per issue type. So even if you have a lot of folders, they automatically share the same filters and the same column settings. I don't think you have to create a separate type for each folder, so this shouldn't be a problem.

Regards,
Michał

Yes, all customizations including the columns and filters in the issues list, column widths and in the future also subscriptions and notifications are stored in a local configuration file (in ~/.local/share or Application Data on Windows).

A much simpler approach, without storing settings on the server side, would be to simply install a pre-defined configuration file along with the client application. That file could be simply copied from the administrator's PC after he sets up the views, filters, etc., or perhaps even generated by using some simple tool. So when a user installs the client application, he already has all settings configured the way you want.

I take your point, it is just that the user support angle of this is not ideal, and sometimes you do need an application that is properly "locked down" and not different on every PC that is used.

OK, so on Windows the location of the file is C:\Documents and Settings\[username]\Application Data\WebIssues\[server key]\server.conf

Is the location of that file stored in the Registry (on Windows) or elsewhere?

Looking at that file, there seem to be a number of issues (please correct me if I'm wrong):

1. Filters based on user seem to store the full name of the user (e.g. "John Smith") and not their userID. So if a user changes name (women get married quite often, for instance) then all the filters on all clients are going to break.

2. Same as above, except we might have two people of the same name. We'd give them different user IDs, and then have to use the "name" field to differentiate (so, for instance, "John Smith IT" and "John Smith Accounts") but if one of them moves department, or we rename the departments, or whatever, then the filters are going to break again.

3. Same as above. We might choose to do things differently and have users like "it.support.1" and "it.support.2" with names applied, but when the post-holder changes then we update the name (this keeps issues with the job-holder not with the person). Again, all the filters seem to break.

4. Where can I find a definition of the numeric variables used in the server.conf file?

And to answer your second questions - filters are not stored per folder, but per issue type. So even if you have a lot of folders, they automatically share the same filters and the same column settings. I don't think you have to create a separate type for each folder, so this shouldn't be a problem.

Err, I'm sorry, but that assumes that you're going to have a small number of Issue Types that don't change much (even if you do have lots of projects). I fear that assumption simply isn't going to be true for many, many users (in my case, after 24 hours of use, I already have 9 different Issue Types, and I imagine this list will continue to grow at the rate of 1-4 a week for a long time as so many projects are different). If there are new Issue Types introduced after a Client PC is configured, they're going to need a new server.conf file at the same time.

1. Filters based on user seem to store the full name of the user (e.g. "John Smith") and not their userID. So if a user changes name (women get married quite often, for instance) then all the filters on all clients are going to break.

For attributes of type "User" there are two additional filter conditions - "is me" and "is not me" which always match the user's current name, so it doesn't have to be stored in the filter itself.

On the other hand, attribute values are simple strings, so they don't change automatically when a user is renamed. So indeed, renaming a user may cause problems. But this is something that can be handled quite easily (imagine a module which gets called every time a user is renamed and changes the attribute values accordingly).

4. Where can I find a definition of the numeric variables used in the server.conf file?

In the client's sources. Columns are defined in src/models/abstracttablemodel.h and operators are defined in src/models/columncondition.h. Each condition consists of three values: column ID, operator ID and optional operand (which is a string).

(...) that assumes that you're going to have a small number of Issue Types that don't change much

That's right :). The issue type system is very simple as it is now. Obviously there could be some sort of meta-types, type templates or whatever one could think of, but that's not something likely to be done before version 2.0 :).

Why do your projects differ so much? Even if some attributes are not used in some projects or have slightly different meaning, it doesn't mean that you need to create so much separate issue types. If you're going to have, say, 50 different types, then administering them may become a nightmare if at some point you need to change an attribute in all of them. Isn't it possible to generalize them?

Regards,
Michał

For attributes of type "User" there are two additional filter conditions - "is me" and "is not me" which always match the user's current name, so it doesn't have to be stored in the filter itself.

Yes... except it doesn't look like the client decides if the User selected in the filter is "me" or not, so it doesn't take advantage of this in servers.conf - or am I missing something? But I take the point, this would be good for generating filters programmatically.

On the other hand, attribute values are simple strings, so they don't change automatically when a user is renamed. So indeed, renaming a user may cause problems. But this is something that can be handled quite easily (imagine a module which gets called every time a user is renamed and changes the attribute values accordingly).

With respect, adding a module to do this sounds like a very complex and potentially unreliable way of solving a problem which could equally be solved trivially by simply using UserID as the matching criterion rather than UserName. UserID will always be fixed, and sysadmins are used to the idea of things being tied irrevocably to a userid / login, whereas names are very transient things! The drop-down can still show the UserName to select, it just has to be bound to a different column in the underlying query.

In my case I could also map the UserID in WebIssues to other user ids in my systems towards a goal of single sign-in :-)

I appreciate that making the change at this stage would "break" existing filters being used by your users, so if there was a change then a migration script would be needed (but that would be pretty trivial - just a few lines of SQL to update the database).

I need to have a look at the code, since I really need to start implementing some of these things quite quickly - I can always make them available as patches for others to try if they like - in anticipation of there being a way to do it with plug-ins :-) I haven't looked yet - are all the compilation instructions included with the source?

That's right :). The issue type system is very simple as it is now. Obviously there could be some sort of meta-types, type templates or whatever one could think of, but that's not something likely to be done before version 2.0 :).

To be honest, although that would be great, at the moment all that would really help would be "create duplicate task type" to save a bit of typing. Far easier to implement in the client than changing the architecture.

Why do your projects differ so much? Even if some attributes are not used in some projects or have slightly different meaning, it doesn't mean that you need to create so much separate issue types. If you're going to have, say, 50 different types, then administering them may become a nightmare if at some point you need to change an attribute in all of them. Isn't it possible to generalize them?

Yes, administering them could become a nightmare, which is why I think the various things I've suggested might help quite a lot!

OK, basic example. I want to collect phone messages. I don't want everybody to see everybody else's phone messages (not in all cases, anyhow). And to save human error, I want each new message to be automatically assigned to the person it is left for.

So, I set up a project called Silas Messages (with permissions of Silas and my assistant). I create an Item Type Silas Messages. The only difference between Silas Messages and, say, Melanie Messages is that the default "Assigned To" is "Silas" and not "Melanie". But because there are no per-folder settings/attributes, I can only get this behaviour by having a completely different item type.

Of course I could just use the same item type of "phone message" but then I'm reliant upon human error - why should my assistant have to remember to assign the task to me each and every time?

Incidentally, this raises another issue (let me know if you think I should start a new thread): to be really useful, the permissions on the projects need to be quite granular: administrator, general full rights, add only, read only, etc. Otherwise right now if I want somebody to take phone messages for me (e.g. receptionist) then I have to give them the ability to read every phone message I've ever had (since you can't delete issues), which isn't very desirable.

Alternatively, allowing an issue to be hidden by the project manager would be helpful, so only project managers could see it.

Anyhow, that's just one example. For other projects, the problems are more to do with the inability to edit comments, so we need lots of fields in the issue to stop the whole thing becoming unreadable after a few revisions. Alternatively we need to be able to edit-in-place certain attachment types, or something else. If we could just have a long text field option as an attribute then some of this would go away for us. I set up an issue yesterday to store a text message to be sent to a client on successful completion of the issue (using a server-side script to query each issue), and I had to use 2 fields just to get 160 characters for the message!

Follow-up to my own post here. I could solve my phone message problem if I could set some system-wide filters as "read only" (so the user couldn't change them). Here's how I'd do it:

1. Phone message project, containing phone message folder
2. Phone message item type has "Assigned To" attribute.
3. User filter for this folder forces only issues created by that user and with status "pending" (or whatever) to be seen by that user.

In this way, any user can add a phone message, but he/she can only see the message that he/she has added, and then only those that haven't been picked up by the recipient.

So that's my firm proposal on filters - allow filters to be set up per-folder by administrators with a mechanism to prevent them being modified by normal users.

it doesn't look like the client decides if the User selected in the filter is "me" or not, so it doesn't take advantage of this in servers.conf - or am I missing something?

Did you look at the pre-defined filter called "Created by me"? It's defined like this: column = "Created By", operator = "is me", operand = none.

problem which could equally be solved trivially by simply using UserID as the matching criterion rather than UserName

The problem is not about filters, but about storing attribute values in the database. Attribute value are stored as plain text, just as you can see them. So the value of the attribute is simply the user name. The only way to map it to an identifier is to look for a user with such name.

To be honest, although that would be great, at the moment all that would really help would be "create duplicate task type" to save a bit of typing. Far easier to implement in the client than changing the architecture.

You're right, that might be useful.

OK, basic example. I want to collect phone messages. I don't want everybody to see everybody else's phone messages (not in all cases, anyhow). And to save human error, I want each new message to be automatically assigned to the person it is left for.

I don't understand one thing here. If you have your own project with your private stuff, then what's the point in having the Assigned To attribute? Even if you assign something to another person, that person won't be able to see it anyway. Unless there is some really complicated permissions system based on filters, like you described in the follow-up.

Besides I really don't think that duplicating the whole issue type for each user just to change the default value of a single attribute is a good idea. Imagine you have 200 issue types for 200 users and now you want to add an attribute to each of them... it's just not gonna work in the long term.

To summarize this, I don't think WebIssues, as it is, is well suited for the situation you're describing. It is a very basic system without advanced permissions, advanced issue type settings etc. Not because I don't want to implement what you're asking for, just because I have a full time job. Since I can spend at most 10-15 hours a week on developing WebIssues, for now I have to concentrate on simple tasks like reordering attributes or viewing attachments.

Regards,
Michał