In CRM 2016 On premise I have a field on an entity that I want to copy to another entity.
This field has a lot of functionality attached to it, and I do not wish to have to make it again (and again and again).
I have attempted with the XrmToolBox and its Attribute Editor, as was advised from Google, but this does not have this option. Also the answers from Google are several years old.
I realize that there might be some issues of copying a field since it may have a lookup or other kinds of references that my copy (or the other entity) does not have access to for one reason or another.
But still, if anyone knows how to do this, or anything in that direction it would be a great help.
Thank you.
In addition to the Attribute Editor, the Data Import Wizard allows you to create new fields.
I am unaware of any tool that will replicate a field's participation in forms, form events, views, plugins, processes, business rules, reports, etc. so those will require either manual configuration or custom programming (and the custom programming route may be cost prohibitive unless you are doing this for many entities on an ongoing basis).
For the sake of completeness I'll mention that an unsupported possibility would be to "hack" a solution file containing the field. While this would hypothetically allow you to do some of what you're looking to do (like change the entity), I would avoid it.
Related
In all environments, there is a field MXM_RemoveMe we want gone from the Account "Information" Form (one of the Account's OOTB Managed Forms, but of course we've customized it on our own a lot by now)
In Dev, I remove MXM_RemoveMe from the Account "Information" Form.
I put that Form in an Unmanaged solution in Dev, export and import into QA. Publish all.
Problem: but the "MXM_RemoveMe" field is STILL on the form in QA.
What could cause this? Do we have to manually remove fields from Forms in all environments? I don't think that's the case normally.
I've verified this behavior in a specific test after the fact. If I add a field to the Account form in QA... then export/import from Dev that Form (Unmanaged) WITHOUT the field... it still stays in QA! I encourage everyone else reading this to do this simple test themselves and see the same behavior I see.
How should this be handled/understood?
I think this is because the form itself is managed. The system simply adds fields to the form on import and does not simply overwrite unmanaged changes any more. In older versions of Dynamics CRM this did not work this way though.
When you prefer to continue working with unmanaged solutions (I feel there are valid reasons to do so), a best practice would be to always copy managed forms first and modify, export and import the copy instead of it.
The copy would be in its entirety an unmanaged form. Up to now I have never seen issues with those forms when imported in target environments in an unmanaged state.
I might be wrong here but this might be changed in the modern make.powerapps.com compared to how it worked in the classic import experience. You might have the option to overwrite your customizations there(not recommended).
https://learn.microsoft.com/en-us/powerapps/maker/data-platform/update-solutions#overwrite-customizations-option
Probably the safest way is to manually go about and delete the components.
Could have to do with solution layering and using the accounts OOTB managed form. Usually, id say it is better to use a custom form
We have a website application that stores data and pictures for a specific customer. We are about to release the same application for use by another customer. The second application will eventually be customized for the second customer. Eventually we hope to have several customers using their own versions of the application.
We are using ASP.NET in Visual Studio 2012. Should we:
clone the existing application and maintain separate code bases?
add a project to the existing solution for the new customer?
We have searched for an answer to but this seems to be a rare situation.
Thanks.
I dont think its rare at all. SAP and Maximo use this a a businiess model. Same core but each package customized to the clients specifications. I have done this (on a much much smaller scale) with some of the programs that we have.
We always start a new project rather than just copy the old. No telling what is in the old one that references the old client. Sort of embarasing when an About window that you forgot about is for someone elses company.
All the code, forms, reports that are customizeable should be in the project for that customer. All of the code, forms, reports that are standard should be in a library.
It really depends on the scope of the application. I've had to do this internally with the company I'm working for; I wrote one solution for one company, then the sister company found out and wanted the same and had to implement it there.
I had a fairly small project to work on, so it was easy to make it universal (while also keeping things rooting from the same code base). All i did was:
break out the unique setting [page title?] using appSettings or similar.
add a new configuration to your solution. Then take advantage of the *.config migrations to:
set connectionStrings
specify appSettings values
When it comes to unique business logic, I had the luxury of using the *.config migrations (most of the data I gathered came from WCF endpoints of services local to the company)--so I lucked out. However, you could make generic interfaces within the app then break out implementation for each company in to separate libraries.
I am looking for some advice on how to allow easy customisation and extension of a core product on a per client basis. I know it is probably too big a question. However we really need to get some ideas as if we get the setup of this wrong it could cause us problems for years. I don't have a lot of experience in customising and extending existing products.
We have a core product that we usually bespoke on a per client basis. We have recently rewritten the the product in C# 4 with an MVC3 frontend. We have refactored and now have 3 projects that compose the solution:
Core domain project (namespace - projectname.domain.*) - consisting of domain models (for use by EF), domain service interfaces etc (repository interfaces)
Domain infrastructure project (namespace -projectname.infrastructure.*) - that implements the domain service-EF Context, Repository implementation, File upload/download interface implementations etc.
MVC3 (namespace - projectname.web.*)-project that consists of controllers, viewmodels, CSS, content,scripts etc. It also has IOC (Ninject) handling DI for the project.
This solution works fine as a standalone product. Our problem is extending and customising the product on a per client basis. Our clients usually want the core product version given to them very quickly (usually within a couple of days of signing a contract) with branded CSS and styling. However 70% of the clients then want customisations to change the way it functions. Some customisations are small such as additional properties on domain model, viewmodel and view etc. Others are more significant and require entirely new domain models and controllers etc.
Some customisations appear to be useful to all clients, so periodically we would like to change them from being customisations and add them to the core.
We are presently storing the source code in TFS. To start a project we usually manually copy the source into a new Team Project. Change the namespace to reflect the clients name and start customising the basic parts and then deploy to Azure. This obviously results in an entirely duplicated code base and I’m sure isn’t the right way to go about it. I think we probably should be having something that provides the core features and extends/overrides where required. However I am really not sure how to go about this.
So I am looking for any advice on the best project configuration that would allow:
Rapid deployment of the code – so easy to start off a new client to
allow for branding/minor changes
Prevent the need for copying and pasting of code
Use of as much DI as possible to keep it loosely coupled
Allow for bespoking of the code on a
per client basis
The ability to extend the core product in a single
place and have all clients gain that functionality if we get the
latest version of the core and re-deploy
Any help/advice is greatly appreciated. Happy to add more information that anyone thinks will help.
I may not answer to this completly, but here some advices:
Don't copy your code, ever, whatever the reason is.
Don't rename the namespace to identify a given client version. Use the branches and continuous integration for that.
Choose a branching model like the following: a root branch called "Main", then create one branch from Main per major version of your product, then one branch per client. When you develop something, target from the start in which branch you'll develop depending on what you're doing (a client specific feature will go in the client branch, a global version in the version branch or client branch if you want to prototype it at first, etc.)
Try the best to rely on Work Item to track features you develop to know in which branch it's implemented to ease merge across branches.
Targeting the right branch for you dev is the most crucial thing, you don't have to necessary define some hard rules of "what to do in which occasion", but try to be consistant.
I've worked on a big 10 years project with more than 75 versions and what we usually did was:
Next major version: create a new branch from Main, dev Inside
Next minor version: dev in the current major branch, use Labels to mark each minor versions Inside your branch.
Some complex functionnal features was developped in the branch of the client that asked for it, then reversed integrated in the version branch when we succeeded in "unbranded" it.
Bug fixes in client branch, then reported in other branches when needed. (you have to use the Work Item for that or you'll get easily lost).
It's my take on that, other may have different point of view, I relied a lot on the Work Item for traceability of the code, which helped a lot for the delivery and reporting of code.
EDIT
Ok, I add some thought/feedback about branches:
In Software Configuration Management (SCM) you have two features to help you for versionning: branches and labels. Each one is not better nor worst than the other, it depends on what you need:
A Label is used to mark a point in time, using a label, for you to later be able to go back to that point if needed.
A Branch is used to "duplicate" your code to be able to work on two versions at the same time.
So using branches only depends on what you want to be able to do. If you have to work one many different versions (say one per client) at the same time: there's no other way to deal with it than using branches.
To limit the number of branches you have to decide what will be a new branch or what will be marked by a label for: Client Specific Versions, Major Version, Minor Version, Service Pack, etc.
Using branches for Client versions looks to be a no brainer.
Using one branch for each Major version may be the toughest choice for you to make. If you choose to use only one branch for all major versions, then you won't have the flexibility to work on different major versions at the same time, but your number of branches will be the lowest possible.
Finally, Jemery Thompson has a good point when he says that not all your code should be client dependent, there are some libraries (typically the lowest level ones) that shouldn't be customized per client. What we do usually is using a separated branch tree (which is not per client) for Framework, cross-cutting, low level services libraries. Then reference these projects in the per client version projects.
My advice for you is using Nuget for these libraries and create nuget package for them, as it's the best way to define versionned dependencies. Defining a Nuget package is really easy, as well as setting up a local Nuget server.
I just worried that with 30 or 40 versions (most of which aren't that different) branching was adding complexity.
+1 Great question, its more of a business decision you'll have to make:
Do I want a neat code-base where maintenance is easy and features and fixes get rolled out quickly to all our customers
or do I want a plethora of instances of one codebase split up, each with tiny tweaks that is hard (EDIT: unless your a ALM MVP who can "unbrand" things) to merged into a trunk.
I agree with almost everthing #Nockawa mentioned except IMHO dont substitute extending your code architecture with branches.
Definitely use a branch/trunk strategy but as you mentioned too many branches makes it harder to quickly roll-out site wide features and hinder project-wide continuous integration. If you wish to prevent copy/pasting limit the number of branches.
In terms of a coding solution here is what I believe you are looking for:
Modules/Plug-ins, Interfaces and DI is right on target!
Deriving custom classes off base ones (extending the DSL per customer, Assembly.Load())
Custom reporting solution (instead of new pages a lot of custom requests could be reports)
Pages with spreadsheets (hehe I know - but funnily enough it works!)
Great examples of the module/plugin point are CMS's such as DotNetNuke or Kentico. Other idea's could be gained by looking at Facebook's add-in architecture, plugin's for audio and video editing, 3D modeling apps (like 3DMax) and games that let you build your own levels.
The ideal solution would be a admin app that you can choose your
modules (DLL's), tailor the CSS (skin), script the dB, and auto-deploy
the solution upto Azure. To acheive this goal plugin's would make so
much more sense, the codebase wont be split up. Also when an
enhancement is done to a module - you can roll it out to all your
clients.
You could easily do small customisations such as additional properties on domain model, viewmodel and view etc with user controls, derived classes and function overrides.
Do it really generically, say a customer says I want to a label that tally's everyone's age in the system, make a function called int SumOfField(string dBFieldName, string whereClause) and then for that customers site have a label that binds to the function. Then say another customer wants a function to count the number of product purchases by customer, you can re-use it: SumOfField("product.itemCount","CustomerID=1").
More significant changes that require entirely new domain models and controllers etc would fit the plug-in architecture. An example might be a customer needs a second address field, you would tweak your current Address user-control to be a plug-in to any page, it would have settings to know which dB table and fields it can implement its interface to CRUD operations.
If the functionality is customised per client in 30-40 branches
maintainability will become so hard as I get the feeling you wont be
able to merge them together (easily). If there is a chance this will
get really big you dont want to manage 275 branches. However, if its
that specialised you have to go down to the User-Control level for
each client and "users cant design their own pages" then having
Nockawa 's branching strategy for the front-end is perfectly
reasonable.
My enterprise is about to start a somewhat complex project in which we will probably use Domain Driven Design for the business layer. The project will be developed using Visual Studio 2010, and managed via TFS 2010 using the CMMI 5.0 team project template.
I think that it would be a good idea to use TFS work items to track and manage the definition of the domain entities and the value objects in the business layer. However is seems that the CMMI project template does not have any suitable work item for this. I have tought of the following workarounds:
Use the Requirements work item,
modifying it so that the
Requirement type field has one more possible value, such as "Domain
Entity".
Add a new work item to the project
template.
Give up and do not use TFS to manage domain entities, tracking them on a separate document instead.
My questions are: What would be in your opinion the most appropriate approach? And, has anyone done something similar (managing domain entities using TFS work items) in the past?
Note: I've not heard of anyone trying this before, so YMMV :-)
I'd be inclined to add a new work item type, and link requirements to the domain entities so that you can see which requirements impact which entities, and you can also link domain entities to other entities.
I'd also be inclined to include other informaiton on the work item such as context, aggregate root, etc so that the entity work item has a little more information around it.
Doing it with TFS work items gives you history and tracking, which may well make it may be worth doing, however I'd also ensure I have links from the entity work items to the domain doco as well, assuming it's stored in something like the project portal or other repository.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My company has been using JIRA as a requirements tracking tool as well as a bug tracker, and it's been working pretty well while we've been working on one project at a time.
We now have a scenario where we have three different project proposals whose requirements partially overlap (e.g. requirement 1 applies to projects A and B, requirement 2 applies to projects B and C, etc.). I'd like to be able to enter a single JIRA issue for each requirement, but that doesn't appear to be possible since JIRA issues and projects have a one-to-one relationship.
Has anyone found a way to do this in JIRA, or maybe with some other tool that integrates with JIRA ?
While there's no single correct answer, I can offer an idea. I don't have enough information about your work process, but you mention that you have project proposals. So I'm assuming projects A, B and C are in early stages. Requirements gathering and such, no bugs yet.
Set up a single JIRA project, say, "Early Requirements". Put all the requirements for projects A, B and C into that JIRA project. To allow many-to-many relationship between requirements and real projects, set up a custom field of type "multiple checkboxes" or equivalent, and configure "project A", "project B" and "project C" as its values. For any requirement you can check which project it applies to.
Now - and I am making more assumptions here - let's say some proposals move on and some die away. You will need a process to a) extract all the requirements for real project A into a newly created JIRA project for A - this can be done via search & bulk clone issue; b) purge all requirements that have no live project associated with them - search & bulk delete.
Caveats: if you need to share requirements with different customers, it will get tricky. Permissions are configured per JIRA project & issue type.
Having said all that, JIRA lacks features for decent requirements management, such as baselines and traceability. But it may be ok for just collecting data for further work.
We use the "duplicates" or "relates to" function of jira.
So you raise an issue in each project, but you relate them together. That way you can have one issue "owned" by a project and you can close out all related projects once the changes are tested on each.
You could even use depends on linkage if this makes sense in your project setup.
We have the same problem. In the case where you have an issue (a bug or new feature) which involves multiple products and that have dependencies between them. (As an example lets say we have a server, a connection api and a client application). If there is a new idea about extending the client application in a certain way, it is quite possible that also the connection api and server need some kind of extension. Probably they are developed by different teams... So not handled in the same sprint / iteration, but as a product owner you want to keep track of all these new features as a group.
What we did was actually created a few custom fields. The first field we introduced was a 'Cascading Select', as 'Program' and 'Phase'. This gives the product owners the possibility to group the issues under a program and do some rough long term planning (several iterations).
Then we added another field (Text Field) for 'Epic' (or 'Theme') this bundles the issues related to a certain Epic / Theme. The idea is to use 'Epics' within a 'Program'. In case of an larger 'Program', you can probably separate it into different parts, which then get reflected in these 'Epics'. (A kind of storyline. A group of stories (which can spread over multiple products) which add value as a hole to the series of products).
Both fields make it now easy to filtering out issues, that cross multiple products, based on Program (with or without its Phase) and the Epic.
Indeed with linking enabled, you can now also create dependencies between the different issues, in the different products. And it is completely separated from default Jira product versioning. Which is great, so the normal release process stays as it is.
Another idea I'm thinking about to introduce is the field 'Iteration'. When going into the planning session (or just after it). This field could be updated with the name of that sprint (Jira is great in multiple issue editing / updating). Which then makes it easy to filter out all the issues for that sprint.
What I like most about using Jira also as a Scrum planning / Sprint tracking tool, is that you do not have a separate planning and backlog tool. Bugs are more visible. No double administration of bugs into planning tool and or planning items into Bug tracking tool (for the correct cvs/svn/etc commit numbers). Or the generation of release notes.
You're probably better of using confluence in addition to jira, in this case.
Use Jira for what it's best at, and use Confluence for everything else.
Divide your various projects into shared "sub modules" if you feel that is useful, however I would be inclined to suggest using Jira mostly for tracking actual implementation and associated bugs.
Another approach is create a multi-select custom field with hyper links (like 'XYZ-123') to issues as options.
Better way is to distinguish issues used for development tracking and requirements that often are the same at 80% for all your projects.
Solution exists: Rmsis a JIRA plugin: