Randomized User Field Positions

[iteamme]

Anyone have this happen?

I created a new tab for Opportunites, adding a number of user-defined fields with meticulous placement within the tab. Then, after exiting CommitCRM and returning to my user-defined tab, over half of the fields I added are in random locations within the tab! So ... I move the fields back where they belong, exit Commit, go back and ... user-field chaos again. What a pain!

This is a serious, deal-breaker problem in that these user-defined fields are critical and I can't have them flip-flopping around the page, sometimes stacked one on top of the other, obscuring the underlying data in other mission-critical fields. Anyone seen this kind of behavior before?

Any help or insight would ne much appreciated!

[Support Team]

iteamme,

We're not sure why this happened (we don't have an open issue for this and we used lots of customized tabs ourselves).

Here's what I recommend (if you haven't tried it yet):

Design the fields in "normal" mode where the Window that holds the customized tab is not maximized. Try not to resize it and use the scrolling options that appears when you drag a field component out of the window area. Then close the field management console and then close the main Window you added the tab to. Close RangerMSP, log in again and see whether the fields are in place.

Hope this helps.

Dina

[iteamme]

I've been able to reproduce this behavior.

It appears to happen when two circumstances come together; the vertical poition of a field is relatively far down the page, and you modify the position of a field by right clicking on it (or double clicking), opening the field properties and then manually entering the "top" or "left" field positions. When I do this, fields I positioned in this manner will not be where I left them before restartingCommitCRM. The "top" line of demarcation for this problem seems to be around 450-500. Above that and there's no problem. Below that, and the field positioned like this will not be in the proper position when CommitCRM is exited and subsequently restarted. It's almost like clock work.

When using the Tools->Field Management ... feature to position fields, this problem doesn't occur. I don't use that to precisely position fields becuse it's far too clunky to do so. Without any sort of "snap-to" grid, or the ability to use the keyboard arrow keys to precisely aligh fields, using the mouse to do so is a challange ... no matter how considerable you mose skills may be. That whole feature needs work ... way too twitchy.

If a support person wants to see this, I'd be happy to do a GoToMeeting session and show you.

[Support Team]

iteamme,

Thank you for posting this. I'll forward it to our QA team so they will try to reproduce it.

I guess that for now you'll need to use the mouse option and drag/drop the fields to the desired location on the tab while in Field Management mode.

Thanks again,
Dina

[iteamme]

While we'ere on the subject of field positions ... why is there an arbitrary limit to the positioning of fields? For example, it appears that fields have a horizontal ("left") position limit of 680. If you manually enter a position greater, it will switch back to 680. We all use larege-format wide screen monitors, and almost half of the available horizontal screen can't be used becasue of this limitation. This leads us to have to stack user-defined fields vertically, which isn't optimum, but the only other alternative is to add another tab to hold the fields we're working with. I also notice there's a vertical limit as well, but that's not as much an issue as the horizontal one.

Any ideas if this limitation will ever go away?

[Support Team]

iteamme,

This is a good point. I'll have to consult this with our development team. Maybe it's an old limitation that we can remove or change (increase) in a future release.

Thanks,
Dina

[Support Team]

iteamme,

Update - The issues you found (field position limits and not being able to position fields in some scenarios) were taken care of will be included in our next release.

Thank you for reporting this.

Dina