I think we are talking about two different concepts here. Heinz is talking about the Oracle RLS which is a concept to add security on data level and does not involve any changes in IFS code: https://docs.oracle.com/database/121/TDPSG/GUID-72D524FF-5A86-495A-9D12-14CB13819D42.htm#TDPSG94446 The IFS concept “IFS Row Level Security” is done in the IFS code. If it is in Core it will still be there after an upgrade, if not STD has removed the security but that is very unlikely to happen. If you have added “IFS Row Level Security” in a customization that is not handled in the STD upgrade and you need to upgrade and re-install your customization, like all the other things you have customized. Most probably the concept of “IFS Row Level Security” is the same and you do not need to do anything for that part of the customization. Of course it also depends on what you are upgrading from and to. Thanks Tomas for the clarification between Oracle and IFS. In the initial request, Eric meant IFS r
Hi Eric, Oracle RLS does not modify any objects delivered by IFS. That’s a kind of an additional layer. Therefore: RLS settings will still be active after installing changes in IFS code. Best regards Heinz Hello Heinzthere are two natures of row level security : https://docs.ifs.com/techdocs/22r1/060_development/027_base_server_dev/050_security/030_row_level/first is at Business component level and is part of Base server development the other one is related to permission set filter configurationIt sounds strange that a Base server development would not be overwritten by an IFS upgrade. Did you mean both cases are evergreen? Or only the 2nd one? Thanks
thank you Thomas, we’ll try this out.
Hello, no IFS update about above impacts?
Hello Mathias, thanks for the quick reply.About duplicate detection, it was asked for some time ago by a prospect during a RFP since they had large, distributed, project teams and it was quite common for them to save key documents (which was including pictures, videos...) and mails exchanged with customer on shared folders. Their concern was that these documents are quite big and if you take dozens of photos, or several vidoes during a review of a contract, it can be difficult to check manually for duplicates.It can be addressed by a rigorous upload process, or as you mention by a periodic cleansing job which would have to handle detection of duplicates and suggesting fixes to some admin (e.g. move connections from duplicate doc to main doc and remove duplicate). There might be some tricky situations (ex: duplicating a specific document might be a workaround to provide access to a same document for two group of users with mostly distinct accesses, without having to restructure document
Thanks @PATNSE we indeed did identify that a CRIM could cover the requirement, but were wondering if we were missing some standard setup capability enabling it.Best regards
Hello, sorry for not answering as I am indeed searching for solutions about the same kind of requirement: including freigh costs into the material cost, as “freight in” costs are part of the costs which can be validly included in stock value according to IFRS standard (the only caveat I see is that if adding “freight in” costs results in overestimating your inventory, then you should reduce the value to “NRV”, net realisable value).By managing freight costs in the purchase order process, I guess you mean adding charge lines to the purchase order? The problem is also that for many companies “freight in” is spread over many purchase orders and invoiced separately as a whole.Delivery overheads are supported in costing to estimate standard costs, but for actual stock value I’m not sure there is an easy way to integrate the freight.The main difficulty I see is that if you gross up the value of your actual inventory (e.g. with a mix of % / fixed amount rule), justifying the stock value towar
Hello, thanks for your replies. @Chguus what you assumed was my expectation indeed.
Sometimes from the DB admin point of view, you can keep these lob data in a separate tablespace for better housekeeping. By doing that you can even split your storage options between not so expensive storage for the documents and high-speed storage for other data. Also, you can exactly monitor which tablespace is growing in order to make better decisions. Yes, and I would have hoped that we could do more of that but I think that “something” in Azure, makes it hard or impossible. Yes, as a general rule (not pertaining only to IFS), it should not be assumed blindly that what is possible “on prem” is possible on the Cloud. Big disappointment can result some times.
As @Srikanth said, .... So, if database size is not a problem, either because you don't check in that many documents, or many large documents, or because you have a backup and recovery strategy that can handle it, then database storage is the most functional, most secure, most convenient and most reliable option, in our view. These are some of the reasons why it is currently the only option in IFS Managed Cloud offering. Hello Mathias, a lot of interesting inputs in your message. When you write “currently”… is FTP repository excluded now but could come in later upgrade? Or are there today no plans for this? Thanks Olivier
Thank you Srikanth, I had indeed identified through the search very interesting comments in this thread (impact on document search, on backup/restore...) even if indicative metrics are not discussed.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.