Hi, our NSC had a technique in Navision for DOS. We used this technique to avoid editing exported objects in design mode. We edited values in exported files (*.fob). These files has ability to run after import into db, but nobody can design them. I tried same way to “lock” objects exported from NF 2.60 or NA 3.60, but with no effect. Can anybody help me how create similar protection without using licence file to avoid editing objects by other NSC? Thanks,
quote:
our NSC had a procedure to avoid editing exported objects in design mode by editing values in exported files.
Could you maybe ask the question again but then described differently?
Translation: The NSC where he’s working is changing some bytes in the file .fob after exporting the objects from navision 3.5x (DOS version) so the objects work fine when imported into the database but if you try to modify the objects with the object designer they’re unable as the objects are having changes onto the bytes and will give you an error when trying to change them. He’s asking if there’s is a similar way on Navision 2.x (financials) and Navision 3.x (attain) so he can avoid people from modifying the design on the objects by changing some bytes on the .fob file. I’ve to tell that i don’t feel that that “technique” his NSC is using it’s really ethical, as it’s a someway of “kidnapping” the customer not allowing him to make changes on the objects and not allowing them to easily change to another NSC as they won’t be able of fixing errors or changing things on those objects. Regards,
I can not agree with strategies as the one described. You’re selling the customer Navision objects which should be open source ! Otherwise you have to sell him an OCX or something so at least the customer knows he is buying closed source ! NTR’s should react to this, since it is not good for our reputation.
The way I see it this is a violation of the NSC Agreement. We as an NSC does not have the right to stop our customer in any way if he want’s to change Solution Center. //Lars
Hi I must confess sometimes I miss such a tool to avoid changes in objects by our own personnel [;)]. But - I don’t agree with the way done by the NSC! If I have bought a designer licence it must be sure that I can change / edit all objects (within my licence range). bye André
I agree. I have worked on SCADA/MES projects for the Czech Repulic and it seems to be be common over there. There was a company called Mius (which also does Navision), they had developped an OCX for Intouch (Wonderware) which : - completely closed the source code - limited the use to 64 tags (license cost…). How would you feel if Navision would close their code for you as an NSC ? I strongly believe that one of the reasons customers choose Navision is because (if they buy the proper license) they can manage the code themselves or get ANY NSC do to the job for them. This is misleading the customer ! Don’t tell me you write in their contract that they or anybody else can no longer change the objects themselves. This probably means that even standard Navision objects are closed by this tool. Standard Navision objects are certainly not your objects so you can not just close objects which have been created by Navision. Is there no way to adress this to Navision Czech Republic ? [:(!]
Unfortunatelly… if you say that’s something common in the Czech Republic probably Navision Czech Republic is already aware of it but it’s not doing anything as long as the customers don’t complain… and they won’t if they think that’s the normal thing… [:(]…
Rudolf is writing about a small function during the “save”-process of any object type in the DOS version of Navision. With a check mark you can “protect” the object against editing with other licenses than the license which had saved it. At that time we have not had any personal license files. There was only one developer license file for the NSC. However, it was a stupid function because with on other developer licens you were able to debug and you got access to the code (you can at least copy it from there, past, modify and save it!). With editing an .obj file (.fob named now) you protected the object against editing (like the function I decribed above). The only problem was that this tool sometine calculated the checksum wrong and you were not able to import the obj anymore. But we still have this with all the add-on’s. If the developer of the add-on do not want to let you modify the objects with your developer license, they do not grand you the right. That’s live. Regards Walter
I agree with all of you… It must be hard explaining your customer they can’t modify objects while they did purchase a designers license. Plus, I really don’t thing changing bytes is the right way to secure objects.
quote:
Originally posted by apertierra
Unfortunatelly… if you say that’s something common in the Czech Republic probably Navision Czech Republic is already aware of it but it’s not doing anything as long as the customers don’t complain… and they won’t if they think that’s the normal thing… [:(]…
Dear Alonso and other hung up developers. I’m not really owner of my work schedule. My chief said me:“Make this work.” I can’t resist him, because he gave me this job and wage. You know, that in Czech Republic some thing are normal. You have to know, that in Czech Republic is 10% unemployment, commodity prices are at the same level as in EU, but wages are at 1/3 of wages in EU.
I’m not responsible judge some steps of my chief. I make anything he say.
I’m sorry to forum admins for this Off topic article.
Eh, Rudolf… (BTW… it’s Alfonso [:)]) nobody was blaming at you, but at the NSC’s politics. It’s not your fault if they do in that way…
@Rudolf: I agree with Romein. This is not a personal thing [;)]. @All: Back to the topic! Is there no other chance to avoid changes in objects? I’m searching for a possibility to block changes in table data within the designer (e.g. a read-only modus for developers). How often it happens - one wrong Return and you have changed the data. [:(] Other example: I created some controlling forms with data which are not for everybody (also not for every super user). In OnInitForm there is check of a role. If the user has not a specified role an error occurs and the form doesn’t open. Therefore I have two questions: How can I avoid changes in this form by unauthorized people = other super users? How can I avoid changes in roles by unauthorized people = other super users? bye André
by using standard navision security…
Probably my answer was not as specific as it should… you can set superusers with permissions in all forms/reports/tables but not with design permissions… or you can set super users with permissions in all forms/reports/tables/system functions but not in a few objects (yup… it’s a lot more work to setup). Regards
Good Morning Alfonso
quote:
Originally posted by apertierra
by using standard navision security…
Did you forget a smiley [;)]? Or what do you try to say … bye André PS This thread is on fire! I love this little icon [:D].
Andre, what Alfonso was trying to say is that you can grant a role read/write/etc. permissions not only for table data, but for application objects as well. For example, you can create a role that can design forms only and thus create super users who are responsible for maintaining forms, others for maintaining reports only etc., without giving them permission to change tables or codeunits.
Hi Heinz
quote:
Originally posted by xorph
Andre, what Alfonso was trying to say is that you can grant a role read/write/etc. permissions not only for table data, but for application objects as well. For example, you can create a role that can design forms only and thus create super users who are responsible for maintaining forms, others for maintaining reports only etc., without giving them permission to change tables or codeunits.
Ok. Now I understand! But our NSC has advise us against creating roles for every object. They said it would be to difficult. Therefore my question [:(]! Thank you. bye André
Hi Andre!
quote:
Originally posted by Andre DDB
But our NSC has advise us against creating roles for every object. They said it would be to difficult.
Well, IMHO creating a role for every object would be not only too difficult, but a sheer nightmare [:0] Roles for each object class would make more sense [;)] Anyways - I think you should give designer access only to users with appropriate qualifications. In addition, these users should all know what each of them is doing. Having more than one person develop in a production environment without proper coordination is the road to chaos [xx(] So, if there’s someone you don’t trust enough to give him, say, access to designing tables, you better not give him design access at all. In my personal opinion, of course…
Hi Heinz Thank you for the input. It seems we are going OFFTOPIC [}:)]. One of my main problems is to avoid unintentional changes of table data within the designer. You are always in a ‘Write’ - modus. Of course - you can set each field in each table Editable = No [xx(]. But this can’t be the only solution. In the good old times ‘BLUE’ there was a property in each table to set Editable Yes / No. IMHO this should on the agenda for MBS. bye André