Folks,
UPDATE: I did end up having to create an extensibility request for this and it is supposed to be in 8.1.3. Thanks so much for everyone's responses!
I've seen the post by Ievgen on how to override a form data source field method:
I wanted to apply the same approach to override a table method, say validateWrite() on the TSTimesheetFavorites table, but wasn't certain how to go about doing that.
Here are the methods available on that table, but they all could be called multiple times, and would not be good candidates for calling registerOverrideMethod(), as I believe that will cause an error, as per this blog post:
https://shyamkannadasan.blogspot.ca/2016/08/registeroverridemethod-was-called-twice.html
Let's say that that issue was solved, the next issue is the syntax used by Ievgen doesn't seem to apply to tables:
[DataEventHandler(tableStr(TSTimesheetFavorites), DataEventType::ValidatingWrite)] public static void TSTimesheetFavorites_onValidatingWrite(Common sender, DataEventArgs e) { var overrides = TSTimesheetFavoritesEventOverrides::construct(); sender.registerOverrideMethod(tableMethodStr(TSTimesheetFavorites,validateWrite),methodStr(TCK_TSTimesheetFavoritesEventOverrides, validateWrite),overrides); }
This will build, but during runtime, it will error out when it hits this method:
Error executing code: TSTimesheetFavorites table does not have method 'registerOverrideMethod'
Any ideas on how to override built-in table methods using the extension approach?
Thanks!
I don't say that you should do this, but you can add a post event handler to TSTimesheetFavorites::exist method and always return false. From the cross references you see that it's only called from this one validateWrite method.
Then, add your own MyExists method with your additional fields, and call it in the post event handler of the validateWrite method.
However, if you change the uniqueness of something in the standard application, you will break everything that assumes that this uniqueness still exists. And you should analyze after each application update if something new has emerged that trusts it. So I would say this is an invasive customization, even though implemented by extensions. So you can't avoid the fact that you will have to worry about it when Microsoft deploys updates.
Hi Nikolaos!
In the case of the TSTimesheetFavorites table, it does not have a unique index, instead Microsoft has put in a validation in the validateWrite() method, which is what we are trying to change.
We could create a new table, however, there would be a fair bit of effort to hook it up to the existing infrastructure... plus it would be an extra thing to worry about when Microsoft deploys updates.
Martin,
There is a webinar about this topic tomorrow, if I'm not able to get it resolved then, I will put in a request to Microsoft.
Thanks again for all your responses!
You can't change the unique index of standard tables with extensions, so please check first if your changes to the table should be redesigned. Then you might notice that you don't need to change this validation that you are referring to.
If you want to have multiple records for one TableGroupAll, Resource, ProjId, CategoryId and ActivityNumber combination you should consider creating a new table for this purpose, and linking all such records of your table to the one unique record of the standard table. Or copying the standard table and then modifying it to suit your needs. Really depends on the case.
If you need to extend Microsoft code that isn't extensible, please create an extensibility request.
There is always bad and dirty way. Like in pre of validate write set global flag, then in post of exist check this flag and return true instead of false.
But again doing this you creating lots of issue that would be hard to debug and fix, so try to avoid dodgy solutions like this.
Hi Ievgen!
Thanks so much for your original post!
As I mentioned to Martin, we are trying to prevent the standard validation from firing, seems like neither events or CoC will work, as they both will still call the standard validation...
For the pre handler, it doesn't seem like there is a lot that we have to work with:
[PreHandlerFor(tableStr(TSTimesheetFavorites), tableMethodStr(TSTimesheetFavorites, validateWrite))] public static void TSTimesheetFavorites_Pre_validateWrite(XppPrePostArgs args) { }
I know that you wouldn't recommend this approach, but if you were to do it, how would you go about it?
Thanks!
Hi Martin!
Thanks for all your posts over the years!
We need to disable the standard checks in validateWrite() as we have extended the table to include more fields, beyond the ones Microsoft is using:
if (TSTimesheetFavorites::exist(this.TableGroupAll, this.Resource, this.ProjId, this.CategoryId, this.ActivityNumber)) { result = checkFailed("@SYS343246"); }
Ideally, we'd write our own validation, which includes the additional fields, to ensure they are unique.
If we cannot use this approach, what would you suggest as an alternative?
Thanks!
You cannot override it, so you have to use either events or CoC to add stuff. Sometimes you can prevent standard code execution paying with parameters in pre handler but I would not recommend to do this as well because it can cause issues if source code would be changed by update or hot fix.
This approach isn't applicable to tables. And disabling standard checks in validateWrite() doesn't sounds like an extension.
Hi Sukrut!
Ah, the problem is, I do not want the standard code in validateWrite() to fire... I can definitely hook up to the onValidateWrite or onValidatedWrite, but this will only ADD logic on top of the standard code, which is not what I would like.
Any other ideas?
Thanks!
André Arnaud de Cal...
291,969
Super User 2025 Season 1
Martin Dráb
230,842
Most Valuable Professional
nmaenpaa
101,156