Open Source Training Seminar FreePBX Paid Support

Ticket #1368 (new Feature Requests)

Opened 2 years ago

Last modified 8 months ago

Abstraction of astdb writes in web interface

Reported by: gregmac Assigned to:
Priority: blocker Milestone: 4.0
Component: Core Version:
Keywords: Cc:
Confirmation: Confirmed SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description

Originally brought up in #1356, the issue that modules are writing to astdb BEFORE "apply changes" is requested by the user can leave the pbx in an unusable/broken state. This should simply not be happening.

One solution is to exten the asterisk API class so that the functions that modify astdb or do anything live in asterisk are replaced with functions that simply queue the actions into a "transaction log" table, which can then actually be applied by retrieve_conf.

Change History

11/16/06 18:10:13 changed by gregmac

(from #1368:)

11/16/06 08:57:37 changed by p_lindheimer

while you are at it - you should actually be doing the same thing with updating astdb variables because otherwise the perceived separation of configuration changes and THE RED BAR isn't really there. In other words, extensions writes to astdb variables, followme and many others. So as soon as someone clicks submit, the pbx is in a partial inconsisten state until they apply. So what you really need is a transaction log that can be applied by retrieve_conf or similar, for anything that would change the state of the machines and generate a reload. This includes adding, deleting and changing astdb variables, file changes, etc. Voicemail would have to be looked at carefully - this one is a bit volatile and needs some thought.

11/16/06 18:14:18 changed by p_lindheimer

  • version changed from 2.2beta2 to SVN-HEAD.
  • type changed from Bugs to Feature Requests.

Greg, while I agree (having discussed it with you) we've been doing this since forever and I don't think there is anything that is to severe (or we would no about it). So I'm going to move this to 2.3. It is a big change and we are trying to stablilize so we can ship and move on to 2.3 where we can properly address it.

01/08/07 11:46:49 changed by

  • milestone deleted.

Milestone 2.3 deleted

01/08/07 12:06:10 changed by vgster

  • milestone set to 2.3.

07/30/07 02:47:30 changed by wvroger

  • engine_version changed.
  • svn_rev changed.
  • milestone changed from 2.3 to 3.0.

11/14/07 14:15:06 changed by p_lindheimer

  • confirmation set to Confirmed.
  • version deleted.
  • milestone changed from 2.4 to 4.0.

moving to 4.0 Milestone, about the time that we have bigger changes ala daemon, etc.

Donate



Support
Download
Develop
Forums
News
Documentation
Paid Support
About

Paid Ads