Adoxio / xRM-Portals-Community-Edition

The definitive edition of Microsoft Open Source Portals, supported by the experts in portals.
MIT License
107 stars 60 forks source link

Mid-level breadcrumb node does not retain query string parameter #62

Closed bernadonh closed 6 years ago

bernadonh commented 6 years ago

Setup the following elements:

  1. Web page (My Organisations) with Account entity list
  2. Account entity list uses a 2nd web page (Organisation Details) to view item details
  3. Web page (Organisation Details) uses Account entity form to display item details
  4. Account entity form has sub-grid of Contacts. This sub-grid has a Create action that redirects to 3rd web page (New Organisation Contact)

When viewing an Organisation details, the URL is as follow:

/my-organisations/organisation/?id=475b158c-541c-e511-80d3-3863bb347ba8

The breadcrumb appears as: Home - My Organisations - Organisation Details. This is fine.

From this page, clicking Create on the Contacts sub-grid takes user to the New Organisation Contact page. The breadcrumb on this page appears as:

Home - My Organisations - Organisation Details - New Organisation Contact

The URL of the 2nd last node (Organisation Details) on the breadcrumb is /my-organisations/organisation/ - which is incorrect as it is missing the query string parameter. Clicking on this node results in a "The record you are looking for couldn't be found" error.

Reproduced on the MS Online CRM Portal (8.4.1.80).

amervitz commented 6 years ago

You will need to submit a support request to Microsoft for issues with the online portals. That aside, I wouldn't consider this to be a bug, instead the sub-grid should be configured with a create action to create the new contact in a modal entity form, rather than redirecting to a new web page. It would not be straightforward to try and retain the parent record in the breadcrumb link.

bernadonh commented 6 years ago

Just for clarification, this issue occurs on Portal CE. What I meant is that I have also tested it on Online Portal and it is also reproducible there.

We had a reason for going to a web page instead of using a modal entity form - but I have to admit I can't remember the exact details now. It might be because we need to run some JS on the Contact entity form, and the JS is not invoked when loading as modal?

amervitz commented 6 years ago

Understood that this would be present in both versions. We would not want to change the behaviour in community edition though to be different than what online does.

I think JavaScript should work in the modal entity form, but if you find the scenario that doesn't work and it only affects community edition, it may be worth exploring.

bernadonh commented 6 years ago

OK cool.

Just for my understanding, is the strategy moving forward is to keep Portal CE and Portal Online aligned as much as possible? Including the bugs?

amervitz commented 6 years ago

At present, maintaining feature parity is not part of the objective, and we wouldn't add new features that Microsoft adds to the online version. There are already new features in online that aren't in this version; this version is locked to the features as of the 8.3 version of code that Microsoft released.

Using Microsoft's online version should be the primary goal, and using this version is primarily intended for those with special circumstances where they need to stay on premise for a longer time period while preparing to move online. Everyone will have their own reasons to use this version, but online is the recommended long term solution that this project provides a bridge to.

If there were a bug in community edition and online, we would want to fix it if we can, but depending on the nature of the issue it might be warranted to delay putting a fix in place until it were addressed in the online version to make sure the same end resulting behaviour is achieved.