Important to know about. Read the details here.
Community members and Claris staff make different observations as they are attempting to reproduce the different context this can apply to.
7 Likes
WOW. Thanks for posting.
(It'll be fixed in FMP 20... LOL.)
I just can't figure out how that's possible such an issue makes its way in what was working fine before - or was it 
?
Claris insists that FileMaker is very secure, that using FileMaker server is much more robust . . .
Suddenly, all my troubles seem so close to me . . . Beatles revisited .
2 Likes
Man I setup accounts with temp password all the time for my clients. I hope they have a fix soon.
Sky Willmott replied with a decent workaround (presuming you only used custom privilege sets): Set a minimum password length > 0, and the password will not be removed when the user presses cancel.
1 Like
@nihm thanks for sharing. This is the kind of info that is good to know in the context. Obviously, hoping that Claris will fix that soon. In the meantime, sharing ways to circumvent the problem may be the best thing we have.
Ditto. Providing a temp-password (was) a reliable and secure method that allowed the user to control the process.
Hey, we will see if they can react faster and publish 20.01 now that the 'release once a year' came to an end.
1 Like
They already said they will attempt pushing the JS things that were supposed to make the release of 19 soon. I don't know if they will put other items in there are the same time or if they will publish 2 packages back-to-back, but security related bugs should get their attention. It sure got mine.
Security fixes have always be a good enough reason for a dot point release.
2 Likes
+1.0
I was wondering the same thing. Features that supposedly underwent no changes get broken from release to release? How does that happen?
There really isn't a mystery around that, is there? It's in regression testing; I'm sure we've all released new versions where we introduced breakage in things that used to work just fine.
The way to catch them is to test. Now obviously the stuff we make is easier to test since we don't create a platform that is the jumping-off point for what our clients can build on it. We have a finite set of use cases / unit tests to run through. For them it is different - although this particular one should have been somewhat easy to test for.
Claris relies on a healthy and lengthy ETS cycle to help catch these. The one for 19 was flawed with lots of start-and-stop given all the internal changes that were happening. Nobody in ETS caught this either. So if you are looking for blame or responsibility there is plenty to go around, including many of us here.
If you want to help prevent this and help make your own solutions more robust then sign up for ETS and contribute to the overall health of the platform.
2 Likes
No, not really.
I'm thinking professional IDE.
In my case, I use JUnit and other automated testing tools that run tests each time I do a build. If a (regression) test fails, the build fails. Period.
I would assume (hope?) FMI's developers would have the same type of test-build set up that's more or less automated in Maven.
Thanks,
Since none of the ETS testers caught it either, and the behavior is pretty specific, I imagine the engineers will be adding a new unit-test for this piece of code. They do have a pretty impressive testing setup.
It is a little funny that you think you have not released a new version of something that didn't possibly introduce a bug on something that worked before.
1 Like
I track those things. I guess that’s why.
Claris tracks them also.
Hi @anon45965781 I don't know how the wires are connected on the fmp login side of things, but I'm not sure I would conclude the feature underwent no changes. If I had to guess, they probably had to do some work to allow logins with Claris IDs, something akind to external authentication yes, but I'm pretty sure they did not just extend what they had for AD here.
The bottom line is there can be a gap in what we perceive and where the actual explanation may be.
Just like with anything else, I'm not looking back too much. I'm sure everyone gets to learn from this and it will minimize the chances of something similar happening going forward. I'm just glad the communication is open, we get to benefit from what another user reported and can now expect this to get the attention it deserves. I think we all look forward to that.
Like they say, it's not about how you fall, it about how you get back up. My disappointment will be greater if they fail to address this properly compared to any disappointment that can be coming from some error here or there. All that is ahead of us for now. Let's wait and see what Claris will do next.
5 Likes
Fair points all. Thanks.
I've actually been very happy with FMP 19.
FMI finally fixed a long-standing "design" bug. That design bug was where they designed the debugger watch expressions to be in the volatile plist file. Then, when FMP crashed you lost all your watch expressions as the plist file regenerated. That design bug was still a problem in 16 but appears fixed now.
As I mentioned previously, the product's layout loading performance is so much improved in 19 that was almost worth the upgrade right there.
I also tried the file functions (nice to have those locally so I didn't have to code yet another micro-service method) a week ago and was also pleasantly surprised both by how easy they were to use and how fast they were. I was only outputting about a 10 MB file, but it was quick.
Thanks again for your reply.
2 Likes
Keep in mind when you start dealing with data around 64 MB, there may be some unexpected behavior ( that you just need to back the writing of data in 64 MB chunks ).