In Greenhopper, is it possible to find all issues that were assigned to a specific user at a specific step in the work flow?
We have a "testing" step, and I want to find all issues that we assigned to a specific user in that step. I have gone through the advanced search documentation, but there is nothing to this effect.
This should work:
status was "Testing" by USERNAME
Unfortunately the was operator was only introduced in Greenhopper 5.5 and JIRA 4.3, which is newer than our version so I can't test it.
[Original answer was by Tomas-S on Atlassian Answers.]
Related
I am using RIDE IDE for Robot Framework, however whenever I try to type in a cell in the test menu, it only lets me type one letter. any subsequent letters just reaplce the previous letters. My keyboard is not on insert mode. Does anyone know a solution to this problem?
You don't give any details about Operating System, Python and RIDE's versions, so it is very hard to help you.
My guess is that you are using RIDE with wxPython 4.1, and not the recommended version, 4.0.7.post2.
If this is the case, then you should go to the project page and read README.adoc or the F.A.Q. at wiki.
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.
I want to evaluate some statistics of my Plone installation and first of all I wanted to know how the total number of Pages of my Plone changing over time.
I had a look at the existing Plone statistics addons. Unfortunately there are none for Plone 5.0. I got quintagroup.analytics running. This addon has interesting metrics, but does not help me seeing the development over time.
So i started programming myself. In order to get the current number of Pages I plan to use a catalog query like this:
catalog = getToolByName(self.context, 'portal_catalog')
catalog.searchResults({'portal_type': 'Document'})
return len(results)
The python script should be run by a cron job every hour and write the result to a log file for me to evaluate later.
My question for you is: Are there any simpler solutions I did not see? Would my solution work? Do you see any conceptual errors in that?
I wonder that there are not more questions like that on the internet. Are people not that much interested in the metrics of their CMS, or did I ignore an obvious simple solution for that?
At the moment the solution does not yet ron, because of my inexperience with the structure of the plone addons, especially calling a python script, but I am working on that.
If you go to "Site Setup" -> "Dexterity Content Types" you can see how many objects of a certain content type currently exist in your site, e.g.:
http://plonedemo.kitconcept.com/##dexterity-types
There is no out-of-the box way to gather or present those statistics over time though.
You could use the data the catalog itself provides:
portal_catalog.Indexes['portal_type'].uniqueValues(withLengths=True)
gives you counts for all types, as a list of (name, count) tuples:
(('CaptchaField', 2), ('Collection', 2), ('Document', 676), ...
I've not double-checked if this avoids searching and len-ing the results, but it's easier than catalog searches if you think you might be interested in more than one type.
(I've only checked this on 4.3.x/Archetypes, but I see no reason it would not work with 5.x/Dexterity as long as it still uses portal_catalog.)
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.
I'm storing information in a custom property sheet for one of my custom products (I'm then using that information in a javascript file). I want this product to uninstall cleanly, but I can't seem to figure out how to remove a custom property sheet on uninstall using genericsetup. I know that remove="True" doesn't work, but I'm not having much luck figuring out the correct way (or any way for that matter) for removing this. Any suggestions would be greatly appreciated.
This is confusing for at least two reasons:
We have both "old style" and "new style" technologies actively in use. Old style refers to Extensions/Install.py (Python code) and new style refers to profiles/default (GS XML + setuphandlers.py Python code).
Successfully installing and uninstalling add-ons in all possible cases still requires the use of both old and new style technologies.
If you don't care about uninstall, you never need to use Extensions/Install.py. If you do care about uninstall, create an Extensions/Install.py with install and uninstall methods.
Also create an "uninstall" profile (in addition to the "default" profile) e.g. profiles/uninstall. Configure the Extensions/Install.py:install() method to execute your "normal" profiles/default steps on installation. Now comes the "fun" part.
Because some technologies can be uninstalled "properly" via GS i.e. they respect the remove=True parameter, your Extensions/Install.py:uninstall() method should execute the "proper" GS profiles to do the uninstall. But if your add-on uses technologies that cannot be uninstalled "properly" via GS i.e. those that do not respect the remove=True parameter, then you will need to write Python code to perform the uninstall.
See:
http://plone.org/documentation/kb/genericsetup/creating-an-uninstall-profile
for more information.