I have created a funnel in mixpanel for a certain flow in my project and there are about 8-10 steps which consists of custom events.
There is a necessity that I have to duplicate the funnel and tweak 2-3 steps by changing the custom events. I have searched in mixpanel and I don't see an option to do save-as and change the steps. It is time consuming process to create the funnel every time with the same steps.
So, I wanted to know if anyone have faced this issue and found out a solution for this?
I have gone through the below link while searching for solution and found no solution,
Import funnels (structure) between projects (not data)
Related
We have a large solution that we are trying to import into another one of our Dynamics 365 online environments. However, the solution is missing around 3 pages worth of required components when we try to export it. If we try to add the required components through the "Add required components" button in the solution, then we can only do it 1 record at a time. This would take a very long time to do. Is there a better way to import these required components? If not, what is recommended in this situation and what are some best practices for managing solutions in a Dev -> Test -> Prod environment scenario?
There are so many reasons why a solution might fail on import, and even more "best practices" for pushing a solution from DEV to TEST to PROD.
Firstly, always make sure that each of your environments is as close to the same as possible. What do I mean by this? Mainly, make sure the managed solutions from each environment match up. Many times, dependencies are pulled in from managed solutions due to bad solution design. WHich brings me to...
Secondly - when you are adding components (entities) to your solution, are you clicking the "add all assets" button? If so - stop doing this. There is no need to pull in 'all assets' on ANY OOB CRM entities. Of course, a custom entity, you may want to pull in all assets. But say you're pulling the Contact entity into your solution, to build a few new fields and customize a form. Instead of all assets, just bring in the shell of account (no assets selected). If you want to clone a form, and make changes, include that form ONLY, then open it and save as, and you will have it in your solution. If you "add all assets", then you're bringing in every relationship in the Contact entity, which is typically where your dependencies will go wonky. Only include those assets you truly need - and always try to avoid including OOB relationships.
In the long run, there is no 'short way' or quick way, to identify and fix your dependencies. What I typically do is take a few screenshots, and go through them 1 by 1 and resolve them. The error should tell you what artifact is causing the error, and which element requires that artifact. You have to resolve each of these, and then re-attempt the import.
If you post some screens, Ill try to help you resolve the issues.
I have some questions regarding the registering/updating of 3rd party plugins that were previously loaded via a managed solution by a 3rd party.
The issue we are having is that they(3rd party) sent us a plugin update and a new plugin outside of the Managed Solution and had us register it manually though the registration tool. Then, next time we tried to import a later version of their solution, the Managed solution import failed. We eventually realized that there where duplicate rows in the pluginassembly and pluginassemblytype table that had the same Pluginassemblyid and plugintypeid respectively with different solutionids.
These solutionids were "Active" which I assume came from the manual registration and "IPM Global" which is our 3rd Party Managed Solution. The only way we were successful in getting the solution to import was to change the overwrite time
on the table(s) to 0 and then delete the "Active" pluginassembly and plugintype records.
Is there any other way to accomplish this same thing that is supported?
BTW. We did try to unregister the plugins before trying this, but there were too many dependencies in our workflows.
Wow, this is a thorny problem. Since you mention updating the tables directly, I'll assume that the system is on-prem.
Registering a plugin that exists in a managed solution outside of that managed solution is something I've never done, and while I have directly updated the plugin registration table, it is certainly something to minimize.
As unpleasant as it sounds, to get back to a good state in a supported way you may be looking at having to:
Backup the SQL database
Backup all the data from any managed solution entities.
Undo all dependencies on the managed solution (i.e. edit all the workflows so they no longer depend on the managed solution). To ease the pain of this piece you might want to experiment with exporting the affected workflows via an unmanaged solution. Then you could delete them rather than trying to weed out the dependencies. Then after you have the managed solution back in the system, you could theoretically import the unmanaged workflow solution to restore the workflow. But, admittedly this working depends on workflows finding the plugin assemblies they depend on by name rather than Id, which I'm not sure is the case - so like I said, experiment.
Unregister the "out-of-band" plugin
Uninstall the managed solution
Install a clean copy of the managed solution, INCLUDING the previously problematic plugin.
Restore/reconfigure the workflows
Restore the managed entities data
It's a lot... so much in fact that I would consider opening a Microsoft support ticket to see if they can provide any alternative methods to correct the situation.
In this situation I personally might also consider unsupported methods like using SQL to copy the tables of any managed entities before deleting the managed solution and then using SQL to copy the data back after the managed solution is fixed. Of course I (almost) never recommend using SQL in an unsupported way, so explore that option at your own risk (and with copious backups).
First, try to avoid direct DB updates in system tables whenever possible. You never know when it will hit you (next solution import, next CRM upgrade, moving to cloud, etc).
I assume that yours vendor solution contains entities and attributes and not only assemblies with SDK message processing steps. Thus you can't just simply remove that managed solution cause there will be data loss. Also I assume there are no workflow activities in their assemblies.
Ask them for solution with properly registered assemblies and SDK message processing steps. Then go into your organization with plugin registration tool (https://msdn.microsoft.com/en-us/library/gg309580.aspx) and unregister their assemblies. Then just import their latest solution. It should be able to import their assemblies with whatever is inside them.
It's good idea to restore copy of prod organization and playthrough whole process in safe environment first.
Is there a way to create a custom reporting system under the Phrequent section in Phabricator?
In the Maniphest app there is a report feature. However, it only counts total number of task by person or project. My organization still requires total time spent on a project and task.
Inside Phrequent you can already sort by user, however, I need one step further total time spent on a task by user or project. Currently it requires a manual process of totaling each time entry per task by hand.
This is not "yet" a feature and there is no implemented way of doing it right now.
Phrequent is still in its early stage of development and a lot of work remains on it.
The tracking per project is definitely a must feature and is being logged here:
https://secure.phabricator.com/T4853
Finally, the current focus for Phabricator right now seems to be the CI part (Harbormaster and Drydock) so the roadmap does not mention incoming work in the short term:
https://secure.phabricator.com/w/roadmap/
but only in the long term:
https://secure.phabricator.com/w/starmap/
On a side note, I considered using phrequent but I believe it's too far from being production ready right now so using other time tracking system seems to be the only viable solution.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I hope that somebody with more experience (bad or good) can help me out here: I am setting up a project tracked in JIRA. The whole process with user stories, documentation, sprints, workflows, bamboo and fisheye integration, etc. is set up. But now I have a rather administrative question:
Where should developers log their work in meetings, such as stand-ups and retrospectives and for writing specifications (detailed descriptions of user stories to come)? I really cannot see what makes sense here, as I need the developers (obviously) to track this work, too. As far as I can see, the possibilities are:
Separate PROJECT-ADMIN JIRA project with simple, non-agile issues
Separate and parallel sprint with admin tasks
Administrative tasks for each sprint
Other versions??
Option 2 seems very hackish, as parallel sprints are just in a beta-stage for the JIRA agile (former Greenhopper) module. Option 3 seems a bit much work to setup for each sprint, and I am not sure, how this influences my velocity (ideally, I want to see the possible amount of story points that can be achieved in a sprint). Option 1 seems the most reasonable to me, but others have advised against it, unfortunately, without offering a solution. I haven't really looked into option 4, as IMHO this is very similar to option 2.
I couldn't see any best practices anywhere, so I would very much welcome any advice from more experienced people. Thank you very much.
We use Tempo to log our billable work against JIRA issues, whether a single Epic for a small project or individual tasks for a larger project. For non-billable work we have a single project where people can optional log work, and we also use it for planning our time. So option 1 is the closest there. We could also have categories for different work logged in Tempo and handle this case that way.
So I face this exact issue with my team and this is what is working for us (for now) YMMV.
Our current structure is that we have a Roadmap type project (call this Planning) where all issues come into at first. Thereafter we create issues in related product projects (call this Product).
In the beginning of the lifecycle, any meetings, scoping, etc will have sub-tasks created and the time will be tracked on Planning. Once scoped and scheduled for work a new issue is created on Product and linked to this original issue.
Once the Product issue is assigned and the dev is called to any meetings whilst this issue is in a sprint we will create a sub-task on Product and assign the time. If the issue is not in a sprint we go ahead and create a new sub-task in Planning and assign the time there.
When then also have a project where we do Housekeeping type work. So if we need changes to JIRA, Stash, Confluence we will create the issues here. We will then create a new issue on Planning, link the issue and schedule that accordingly.
We have a meta project that acts as a bucket for anything that doesn't fall into the other categories which we sift through every now and again to identify if we need to create separate projects.
I have created a custom field that rolls up all the times of any linked issues found on the Planning board
Have a look at the Twitter blog Visualizing Epics and Dependencies in JIRA by Nicholas Muldoon maybe this can help you in some way too.
One caveat we are still exploring the best way to do this. Each environment is different and what works for us might not work for you.
I have faced the same issue trying to track team member hours that are unrelated to the project or related to the project but not to a specific story or task.
Initially we went with option 3 & had several administration tasks that persisted across sprints. While this was relatively easy to implement it failed for us as we had team members that sat across multiple projects & as a result these administrative tasks that resided in each project were impossible to manage / report on for these team members.
In the end we went with what you have described as option 1. By creating a separate project with "non task related" issues such as Planning Meetings, Technical Issues & Client work then installing the JIRA Misc Time Log & Report Extensions plugin we could provide users with an easy means of logging times without having to change projects or boards (since the plugin adds a dropdown menu to the top navigation).
The plugin then allowed us to get reports on where team members we logging time off project regardless of how many projects they worked on concurrently.
I was having the same issue, and I know some time has passed since the moment this question was posted but maybe this is useful for a lot of people:
Tempo has a dedicated feature for that thing you want to achieve and is called Internal Issues. not to be confused with Internal activities.
You can go there by navigating to Config>System and then click on the add-ons tab. Then scroll down to the Tempo section in the menu on the left bar and there you'll find a link that reads Internal Issues. There you can create the issues. Please keep in mind that before creating internal issues you have to create the tasks, for instance "Sprint Planning" or "Retrospective" in the project without assigning to anyone, just to the project.
When your users go to log their time for those "Internal Issues" they go to Tempo > Timesheets and then click in the upper right button that reads log work. There, in the right menu they'll see the "internal issue" option where they can pick those internal issues you previously created and log the time that the team spend on SCRUM Ceremonies.
I'm working on a website at the moment that has three separate "area's" to it. Firstly, there's the main website, then there is a User control panel, and finally an Admin Control Panel.
At the moment, I am working with three separate solutions which is less than ideal, as I can imagine updating this in the future will become rather messy.
What I would like to do ideally, is create a solution, and then include the three separate projects within that solution. I don't have a problem doing that, what I can't seem to figure out however is the publishing side of things.
I've searched around and been unable to find a solid answer to my question, which is:
If I am using multiple projects in one solution, can each one be published to a separate FTP Server Directory? -- I would also welcome any ideas on how this could be done better.
My apologies if this question has been asked before, but during my searching I have been unable to find anything that relates to this situation.
Thanks in advance,
Dave
This is definitely possible, since publishing occurs at a project level rather than at a solution level. What I like to do is go to Tools->Customize->Keyboard... and set a custom key binding for "Build.PublishSelection". Whichever project you have highlighted in your Solution Explorer will be published when you push the key binding. You can save multiple publish configurations in the publish dialog as well.