Closed Bug 823561 Opened 12 years ago Closed 12 years ago

Prefilled values for the Version field don't work correctly

Categories

(Cloud Services :: Server: Product Announcements Campaign Manager, defect)

defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tracy, Assigned: jrconlin)

References

Details

(Keywords: regression)

Before the version field was pre-filled, this feature was working correctly.  Now if I select a version, for example; 18, Fx 18.0 builds do not get the message.

I believe we'd want more granular control in this field anyway. For example, marketing may want to send a message to 18.0 users but not 18.0.1. They may also want to send messages to specific versions of beta builds like 19.0b1 but not anything newer on beta.

Perhaps a combination of both with a preset list of major versions 18.0, 18.0.1, 19.0, 20.0, etc. AND the ability to specify manually? (note: there doesn't need to be versions earlier than 18 in the pre-filled list) This can be accomplished with and editable combobox.

Like I said, this feature was working when I could manually specify version.  At the moment, it's broken.
This is indeed a bug, but one that needs a bit more of an explanation/work. 

Talking with product about this, they want more "fuzz" around version matches, so that they can match a range of versions, (less than x, greater than x, between x and x+n). That's a tall order and a bit ugly to do. My plan is to alter the way that matching is done to only work on root versions (e.g. match "18" instead of "18.a.012.foo") 

I'll push out a quick patch to stage that does the version stripping this morning.
oy!  yeah, agreed, if admin sets the record to 18, any version of 18.x.x should get the message. Fancy magic for later iterations.
Remember that we discussed wildcard or prefix matching? 


Remember that one of the advantages of explicit wildcards was in allowing targeting of non-upgraded users (18.0 but not 18.0.1).
rnewman: Yep. I was in the process of working on that. Prefix matching is expensive during lookup calls, so I'd like to avoid it if need be. (I can't use both like and coalesce to capture campaigns that do not have versions associated, and since we have no idea how many campaigns are actually going to be run, I can't presume that storing and sorting them in memory is feasible or possible)
There's also the concern that Product has about making things "too complex" for the end customer. Having selectable lists is preferable to complicated wildcards since there's less chance that they will screw up.
Version now uses "floor" of major version number (e.g. "18")
Previous records currently in DB that have extended versions, sadly, will not match.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
verified against stage
Status: RESOLVED → VERIFIED
QA Contact: twalker
You need to log in before you can comment on or make changes to this bug.