I have installed A2B but facing some problem while using DID. I configured DID and assigned to to one Extension but the Extension still using the DID even after I remove the DID.
I am not using that DID in sip.conf to define 'fromuser' but it seems something hardcoded and by default using the DID.
Is there anyone out there can suggest me the way to address this issue or put some light on it?
Last patched a2billing version for sure will not work if any of following not true:
1) User exists and ACTIVE, activated time not in future
2) Did exists, active, creation date not in future and not empty
3) did_destination have record for destination.
So you have done it not via a2billing or have all above TRUE.
Related
I have an "UpdateAttribute" processor that evaluates information in a JSON file. Originally, this would just check if a client had been updated and the statement looked something like this:
${literal(${allAttributes("client_attribute1", "client_attribute2"):equals("UPDATED")}):ifElse("UPDATED","UNCHANGED")}
However, the specifics of the client's status change now needs to be tracked - such that if the client goes from OFFLINE to ONLINE, then their status is "1". If they go from ONLINE to OFFLINE, then their status is "3". This would ideally be done in a single statement. I'm not sure exactly how this would work, any suggestions?
I think it would be better to use UpdateAttribute processor Advanced usage for this case.
Add all your rules you need to check then add the attribute which satisfied your rule.
Refer to this and this links for more details regards to UpdateAttribute Advanced usage.
With symfony console commands you can prefix/group each one by putting in the setName("group:command"), and this is great.
myown
myown:cool
myown:foo
myown:bar
But the problem is that some external dependencies dont use this format. Ex: Phinx Migrations.
Since I'm importing an dependency that has a console command called migrate, I dont want for it to show without prefix/group. Not just because I might have another command called migrate or just for readability. I don't event know if we have 2 with same command name which one will show (need to check).
My question is: Is there any away for me to force a group commands from an external depencency to be inside an prefix/group?
You can achieve that, I wouldn't recommend but that would be the approach:
Create a compiler Pass which removes the definitions of the Commands you don't like
Register again all those commands while setting the names you like
If you need information on compiler passes:
https://symfony.com/doc/current/components/dependency_injection/compilation.html#components-di-compiler-pass
Maybe there's an easier way which I'm not aware, but for now that's my answer to you, I can't post all the code because that would be a lot of code and if you do it maybe you can update with the solution.
Good luck
I'm working on a sniff for PHP_CodeSniffer 3.x. For example, the class declaration class NoInlineFullyQualifiedClassNameUnitTestInc extends \PSR2R\Base\AbstractBase should be split into a uses and class AbstractBase. The sniff detects similar issues for method signatures.
I believe the problem is that I'm generating and inserting multiple use statements at the same line (i.e., same token), but doing so in separate fixer->beginChangeset() ... fixer->endChangeset() sequences. The fixer treats multiple sets of changes to the same token as a conflict, and things get messy (and wrong).
The GitHub issue is here: https://github.com/php-fig-rectified/psr2r-sniffer/issues/9
Has anyone figured out how to do this writing custom sniffs for the latest 3.x CodeSniffer?
You can also use SlevomatCodingStandard\Sniffs\Namespaces\ReferenceUsedNamesOnlySniff
It turns this
Into this
How to use it?
The best is to use it with EasyCodingStandard like this:
# easy-coding-standard.neon
checkers:
- SlevomatCodingStandard\Sniffs\Namespaces\ReferenceUsedNamesOnlySniff
Install it:
composer require --dev symplify\easy-coding-standard
Run it:
vendor/bin/ecs check src
Fix it:
vendor/bin/ecs check src --fix
Enjoy and let me know how it works for you.
If any troubles come up, just create an issue here. I'm happy to improve this tool as much as possible.
The problem is multiple Sniffer (fixer) changesets editing the same token. I was able to get the Sniff to work by collecting a list of USE statements and inserting them at the end of the Sniff's processing.
I identified the end of processing by searching backwards from the last token to find the first token of the list of registered tokens.
Edit: Here is the sniff: https://github.com/php-fig-rectified/psr2r-sniffer/blob/master/PSR2R/Sniffs/Namespaces/NoInlineFullyQualifiedClassNameSniff.php
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
After google i found three ways:
1. static variables
2. extending Application and using getApplicationContext
3. SharedPreferences
EDIT: read comments pls, i don't want to delete it, because it may help other who fell into the same trap...
Be careful with static variables!! I wrote an app which uses them, but on some devices it works, on some it doesn't. the problem is, if one activity edits that variable, finishes and the focus returns to another activity, the changes are not recognized. i haven't found a solution for this and somehow i don't get it working with getApplicationContext either...
Usually i would say that i made a mistake, but in both cases, it is working on an SGSII with Android 4.0.4 but it isn't on SGSIII with 4.1... :(
So as a consequence i assume that they've changed the use of global variables, maybe out of security reasons, so that every activity gets an own instance of that variable or so, i have no idea