This behavior is mostly because of the way the system is designed, but I'd like to hear others thoughts on this issue. To me it doesn't seem to be a major issue because most people will be using the module infrequently. Debugging may be cumbersome, but most people will not be debugging...that's my two cents.

I agree it's annoying to have to resort it all the time. It would be nice to have it keeping the same order, but it's really low on the priority list.

This would be under the category of `nice to have`, but I'm not sure I feel compelled to make the change. jjacobs is correct I think; It may seemlike we spend a lot of time debugging, but its not that often.

I think its a little more important - especially when working in a situation where there are several sources active and being debugged or configured. It it can makes the debug/config process take a lot longer than it might otherwise take. I vote we size the job and see what might be doable.

I know what you mean.

However to debug, now I'm creating a new scheme called test where I'm putting only the sources I want to play with.
It avoid screwing up with my other working schemes.

Patrick - thats a great idea for workflow. Create a `sandbox` scheme for this kind of testing and planning. We need to make sure that gest into the online doucmentation for users.

Jeremy - could you review this and give a sensing of the size of the task involved in addressing this?

Keeping track of the order that disabled sources are in is a problem because of the way the database currently keeps track of sources. Currently the database has a single text field that is a comma separated list of the enabled sources in order. All sources not listed are by default disabled. In order to keep track of the order that disabled sources are in, we would have to have that list be more than a simple comma separated list. It would need to list both enabled and disabled sources, and their status.

I think this feature could be implemented, but I feel that it should be saved for a later release at this point. It would not require massive amounts of redesign work, but a significant enough to both caller_id.php and sources.php that I don't feel comfortable including it with this release.

An easier solution would be to have a button to copy a scheme to a new scheme..

You can use the new scheme for test purposes.
The copy is needed to avoid having to reenter all the optional info in each source (password, options, etc...)

That would be a potentially simpler. The delete function is already present - and it would make a BIG difference to complex CID situation trouble shooting.

Jeremy - how does that size as a task and rate for complexity?

I think making a copy of a scheme would be easier to implement. Is this an acceptable solution to everyone?

Yes. While it doesnt directly address HATs request (stopping the resort) - it DOES nicely limit some of the time needed to prepare and test specific CID scheme configs. Its a worthy measure to take - and I think it will indirectly improve the situation - and probably offer additional benefits also.
My vote: Yes.

The copy function does sound like very good idea. Why not take Patrick's idea of a test scheme and combine it with the copy idea. Create a default TEST scheme, make it so that it cannot be called on by any incoming route (if that's possible), make it mandatory that a real scheme must be created before using this test scheme, and, if multiple working schemes are created, have the ability to import and/or export a selected scheme via a check box into the test scheme. I have no clue about how complicated this addition would/can get. If this would get too complex, than I vote for the copy button.

Ok, I just committed a copy scheme function. I picked out an icon for the copy function, but I'm not entirely pleased with it. I'm also thinking that it might be better to put the copy function on the right side of the scheme name instead of the left side right next to the delete button. Give me your thoughts on where the copy button should be....and test it out.

I like the Icon where it is. But it looks like a little green water pistol :)
How about something showing two pages, one stacked behind the other - that might be a graphic to try.

Second try at a copy button.

Copy button looks great to me. The copy function works as hoped for and expected. No negatives have bee noted.

I do have an idea however. It would be good to be able to disable/enable schemes the same way we do data sources.

Why? OK - if I have to stop trouble shooting, or if i have a scheme that is built JUST for trouble shooting, it will always be active once created. It would be very helpful to be able to build a test scheme, and leave it built, but inactive - for use again later.

QA: Pass. Functions as expected.

This feature has been moved into 2.2.1 release - and can be included as is, if the additional functionality is not included.

More functionality has been requested. Holding ticket status as assigned untill determination is made for new requested functionality.

QA TESTERS BE AWARE¶

I have implemented the ability to enable and disable sources, however to do this it required minor tweaks to the database. If you attempt to use the On/Off feature on a database that has not been upgraded, it may cause problems.

1. run the following mysql query on your asterisk database: "update superfectaconfig set value = (value+1) where field='order';"
2. force the install file to run.
3. Deleting all existing schemes and starting from scratch. The new schemes will be created properly.

Basically what I've done is this: In the past the order was a zero based value, meaning that the top of the list had a value of zero in the database.
I switched to a one based value and have allowed values to become negative, with a negative number indicating that it is a disabled source and then sorting the list on absolute value of the the order.

When a source is disabled (new function), the source name goes grey. Its unfortunately the same shade of grey that the background of the cid scheme column is - and therefor the scheme name disappears against the background when the data source is turned off.

Please suggest an HTML color code for this text and I will get it updated or you can update it. I can see the gray fine on my screen, but I'm on an LCD and colors look different here than CRT. Additionally I'm color blind, so the colors will likely look different to you.

I can see it properly too on my LCD.

ok - here is the shot from ie:

When viewed in firefox, the text is allmost visible, but still virtualy invisible.

I suggest LIGHT RED for disabled sources.

Ok - Im updating this cosmetic issue now. Disabled Schemes will be light red.

Color updated to light red. Please see if it looks ok to you. Revision r180
(I should mention I am using LCD montiors also - so Im not sure whatthe difference has been?)

That color works for me

Jeremy - will a first time upgrader to v 2.2.1 need to be wary of the change in database situation that you outline in comment number 24 of this ticket, or will the nromal module upgrade routine handle it?

(I think the answer is the reglar upgrade will handle it - since it runs the installer - but I thought I shoudl make sure before closing this case.)

QS: Pass. Functions as expected, as per ticket notes.
Tested against PBXIAF, Trxbox CE, Foncordiax, EI8 and firefox.

Waiting clarification on end uper upgrade process before closing case.

tshif wrote:

Jeremy - will a first time upgrader to v 2.2.1 need to be wary of the change in database situation that you outline in comment number 24 of this ticket, or will the nromal module upgrade routine handle it?

(I think the answer is the reglar upgrade will handle it - since it runs the installer - but I thought I shoudl make sure before closing this case.)

No the upgrader will not need to be aware of this. The install file has the necessary code to upgrade the database when they install the new version.