Hi, I am blamed for an hour of not following the rules of their system.
I have created a find function to search for things, I have asked them which global fields should I use or creating new global fields? They told me to use the same fields as the XX layout.
I found that they have not cleared the global fields after search.
Other layouts follow the same rule and I found that there is bug when the users do a search in my layout then go to other layouts which same global field is used and perform find without change of the global field, then they may not find the expected result, the clients may ask why they cannot see expected result.
As I cannot control other parts so I decided to clear the global field after search. And they ask me why I break the consistency of the system.
I think the bug is a higher priority than consistency in this situation.
I am responsible for this part so at least I do as much as I can.
So I should report the bugs to the managers and let them consider to fix or not? but not fix the bug first?
P.S. it is still under testing, the clients do not know the function yet.
I am sorry to hear that you may feel caught in a bind. The politics and protocols for how your team expects bugs to be communicated and addressed is something that I can't speak to with conviction, as I don't know the full picture, and even if I did, my words would simply express one opinion.
Something that I can speak to is that I am pleased that you have the FMP experience and wisdom to spot the bug, understand it, and that you have the motivation/intent to not let it go un-addressed. A developer who can focus on completing the task at hand while at the same time keeping an eye open to the implications of their work on other parts of the solution is a valuable player on the team.
In every setting that I've worked in, I've had to learn the best way to communicate/address concerns that I have with the existing code, and sometimes this has meant taking the initiative to make changes without first seeking approval or authorization to do so, and other times this has meant submitting my findings and then deferring to a manager or another team member. (And not always do I get it right the first time.)
So, the only thing that I can say with certainty here is that, beyond learning how to comfortably work within the framework of your company: I hope you will take pride in your ability to catch errors such as you have described and also take pride in your dedication to seeing such errors tracked and addressed.
first of all I don't like to be brought into situations like the one you describe. It's quite difficult to not step on anybodys toes
Since the systems seems to have gone live the users are accustomed of the behaviour you call a bug but this implementation may have had some reason. So calling this a bug may have been to strong?!
In your case I would keep my footprint as small as possible: why not store the state of the global fields before starting your routine and restore afterwards. Some JSON in a global variable could achieve this and everybody should be happy...
Yes, you are right. If possible, I don't want to be brought into this situation either.
In this situation, I even haven't been told the reason behind this. They just told me to follow the original system so I finally remove the clear field content step.
Storing the state of global fields seems a great way to solve the problem, thank you for your tips.
Yes, after all, it wasn't a bug until you introduced your code and no-one is going to thank you for identifying the legacy costs of their quick-and-cheerful coding shortcuts.
@harvest's suggestion is good. Store the values of those fields before you clear them and replace the values afterwards. Depending on the way in which your users interact with the search it can be a little tricky to determine when they have finished, and so it's difficult to know when to reset the field values.
If you have full control of the layouts on which your search is used you could use this workflow:
on LayoutEnter
set $$staticGlobalData to global field value
clear global field
on user action
set $transientData to global field value
use $transientData within your scripts
as soon as the global field is no longer visible to the user set global field to $$staticGlobalValue
Thank you. I should ignore the manager's suggestion and create new global fields.
I have followed their rules and use the existing field to create the function and be blamed for an hour as a result.
Thank you. Indeed, no-one is going to thank you for my detection.
In fact, it seems that they refuse to use the script trigger and if I add the trigger on my layout, it will come into the same situation which is in-consistent to other layouts.
I think because of the bad management skill of the manager. They should state clearly what I can do and what I cannot do.
You could generate an outline of your proposed changes and get them OK'd by your manager. It doesn't have to be a thesis, just enough for them to have a sense of what you're doing. Are you going to touch existing objects? If so, identify them. Are you going to create new objects? If so, itemise them.
I would add to @Malcolm suggestion to identify the purpose shortly and preface the whole thing with your strategy.
Eg. In order to implement xyz functionality, I use cvl and will do abc in the scripts so that fyf can dothis while preventing thatthing.
Scripts
check.userPermission
Purpose:
Parameters:
Result
reset.mySearchTerms
Purpose
Parameters
Result
That way you can get the okay before you start coding but after you have a concrete plan to approve, rather than riding a long while on general directives that may not be very clear or present exceptions or implementation challenges.
Below are some of the global fields that I am using.
Easy to see what tables and fields they each search on.
The "F_" prefix is for grouping this type of global fields together.
The "_gT" suffix reads global Text field...and is there to increase code readability when working in scripts and on layouts.
Hey, there are good suggestions here, so I won't get technical.
It's more important to stay consistent at first. But make notes of issues you find and then offer your suggestions for how to fix the problems. This builds trust with your coworkers and managers, and once you have their trust, they will allow you more autonomy.
AND if you have a proposal to fix the problem globally, you can maintain consistency anyway, because your fix will be applied everywhere.
The goal is to reach a level of trust where they will encourage you to take ownership of the code, as you have started to already, and you'll have even more opportunity to improve it.
Just keep doing good work and keeping good notes about what kind of improvement opportunities you see in the system.
Caveat: I should clarify that consistency is only more important in non-mission-critical situations. If you know you are adding a bug or exacerbating a really important problem, then make sure it gets solved or at least make clear that you see a big unsolved problem.
This thread while having a technical branch is really about management and communication.
How do I integrate new developers into a running team?
How do I achieve teamplay or teamgeist?
How do I establish openmindedness?
How do I create a climate for open communication and discussion?
Since I'm working projects like this with teams from 2 to 6 FM-developers for 20 years now I know both sides. I try to take it from what is best for the customer. On either side. I gain nothing by defending what I have done 10 or 15 years ago. If this blocks innovation, breaks workflows, costs hours of work, demotivates collegues - trash it.
Sometimes you really need management to make decissions on these topics. I go with Cecile in that this can only be based on documentation. While it is timeconsuming it also is a great opportunity for reflecting my own doing.
Is there any advice in this? Communicate, document, try not to be resentful ( I know this is sometimes the hardest part). I hope this doesn't sound to esoteric
Have you read "Debugging the Development Process", or "Code Complete 2"? Both excellent books and point out major pitfalls companies still do on almost every project...
Excellent reflection, @harvest.
Communication and documentation are crucial to the success of a project. The need for an adequate communication and documentation budget ( in addition to the typing-code budget) may require senior management appreciation and sponsorship, depending on the maturity of an organisation.
and no-one is going to thank you for identifying the legacy costs of their quick-and-cheerful coding shortcuts.
