Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Comment | File | Size | Author |
---|---|---|---|
#150 | 699252-150.patch | 17.37 KB | Rassoni |
#148 | interdiff-147-148.txt | 12.43 KB | Rassoni |
#148 | 699252-148.patch | 20.39 KB | Rassoni |
#147 | interdiff_130-147.txt | 2.3 KB | ravi.shankar |
#147 | 699252-147.patch | 10.02 KB | ravi.shankar |
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedtagging
Comment #2
dawehnerWe could add a if in the query method which calls another function. But this would need a lot of code changes for existing handlers.
So we have to execute it from the view::_build i guess.
To the design of the patch:
The field handlers gets a new method:
field_filter_alias:
return the field alias of the field, to be able to filter later.
returns FALSE if A the definition of the field data has a bit OR if the handler don't want it, for example views_handler_field_prerender_list
not sure yet about this returns TRUE for the admin settings, there might be no field alias at this point.
The filter handler gets new methods and settings:
query_field()
Attaches the query to filter by a field.
new settings: select the field to filter from, this will go over the existing fields of this display and checkwhether it returns a field_filter_alias
Thats it :)
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedHmm. What if we add:
Have this as TRUE by default. Have prerender_list set it to FALSE so that quickly eliminates most of the many to ones. Do a quick scan of other filter objects to see if any of them need to change their value.
Comment #4
dawehnerHere is a initial hackish version
TODO:
Find out how to call another query method. Currently its a quite hacky bit of code:
Any kind of suggestions are welcomed!
I had to move the build for filters under the build of fields.
Comment #5
rjdjohnston CreditAttribution: rjdjohnston commentedthanks
Comment #6
dodorama CreditAttribution: dodorama commentedI'll have a look
Comment #7
YK85 CreditAttribution: YK85 commentedsubscribing
Comment #8
infojunkieUpdating the patch to the latest dev. No other work done on it.
EDIT: There's an extra
dsm()
call in there. Sorry!Comment #9
infojunkieUpdated my patch at #8 to handle cases where
views_handler_field::get_field_alias()
is called on an uninitialized handler. This happened when using a summary argument action.Comment #10
AndyZhang CreditAttribution: AndyZhang commentedsubscribing
Comment #11
bsandor CreditAttribution: bsandor commentedSubscribe
Comment #12
david.fzs CreditAttribution: david.fzs commentedI do not have enough knowledge of the views module to make a relevant review of this patch, so I just tried to write a small module providing such a filter.
If you want to give it a try here it is : http://drupal.org/sandbox/david.fzs/1467698.
Comment #13
MHLut CreditAttribution: MHLut commentedsubscribing
Comment #14
haydeniv CreditAttribution: haydeniv commentedJust tried david.fzs module in #12 and it work great. You should really just publish it as a full module.
Comment #15
bradjones1Doing some ticket cleanup - I will echo the sentiment in #14 - this functionality is really helpful in certain use cases and the david.fzs's sandbox module does the trick.
@merlinofchaos - do you think the sandbox code is a candidate for a merge? Seems to be a generalized enough function that it rightly belongs in views as opposed to an add-on module.
Marking needs review since there is working code for this use case that might be a candidate to merge in. Also marking 7.x.
Comment #17
rudiedirkx CreditAttribution: rudiedirkx commentedThe sandbox module from david.fzs is perfect! Only the fields that already have been added to the fields are candidates. Perfect! I'm totally using this forever.
@merlinofchaos @dawehner You should just merge this in.
@david.fzs If they don't merge it in, promote it to a full module, like @haydeniv suggests.
Comment #18
dawehner@rudierdirkx
You totally get how opensource development works. In general we should first provide a patch against views, not an additional module,
and probably do some automatic testing for this feature, as you never want to break existing working views.
Comment #19
rudiedirkx CreditAttribution: rudiedirkx commentedYeah I get that =) Just saying: his solution is excellent, so let's use that one. No need to create it yourself.
I'll create a patch against 3.x-dev.
Comment #20
rudiedirkx CreditAttribution: rudiedirkx commentedCleaned up code and created a patch against 3.x-dev (f776088). All credits to @david.fzs.
It won't break existing Views, unless another module has defined data/filter
[views][fields_compare]
in which case the fields data collection fromhook_views_data
implementations will be corrupt. An acceptable risk IMO.Comment #21
dawehnerIf you would just not maintain all existing code ... it's really common in drupal to just commit code which is actually working fine.
Please use spaces instead of tabs.
should be better views_handler_filter::option_definition() or maybe overrides
Not equal should be probably <> instead.
In general we should find a better way to find out whether a field actually maps to a field in the database. This seems to be a dirty hack
We should probably document what this code is doing.
Can't we use $left_handler->table_alias directly?
Comment #22
rudiedirkx CreditAttribution: rudiedirkx commentedI don't know what this means:
I've updated the patch:
views_handler_filter
in this case). Most Views classes and methods don't do this though...!=
to<>
.field
,real_field
,table
etc don't mean anything untilhandler->query()
is executed. I'm all for a better way (like adding ais_db_field()
method to all handlers), but since there isn't any now... Something to think about for D8.$left_handler->table_alias
is empty at that point... Don't know why. After$this->query->ensure_table(...)
it's still empty btw. Not connaisseur enough.Comment #23
rudiedirkx CreditAttribution: rudiedirkx commentedComment #24
IWasBornToWin CreditAttribution: IWasBornToWin commentedAm I safe to apply this patch to my current views? Or has it been committed yet?
Thanks
Comment #25
IWasBornToWin CreditAttribution: IWasBornToWin commentedJust applied patch...works excellent...LOVE!
Comment #26
IWasBornToWin CreditAttribution: IWasBornToWin commentedDid this patch make into latest dev dated Oct 6?
Comment #27
IWasBornToWin CreditAttribution: IWasBornToWin commentedPatch doesn't seem to work with date fields - unless I have something set wrong. Here's the query - (field_data_field_date_criteria.field_date_criteria_value > users_flagging.created)
I'm trying to compare a date type node field to the date a user was created. If I choose less than, all user's are showed. If I choose greater than, none are showed.
Comment #28
rudiedirkx CreditAttribution: rudiedirkx commentedThat's probably because
field_data_field_date_criteria.field_date_criteria_value
andusers_flagging.created
have different formats.field_date_criteria_value
is probably a full datetime.created
is a timestamp (int).Comment #29
IWasBornToWin CreditAttribution: IWasBornToWin commentedSounds correct. Is there a way to compare with formats? I ran into this again yesterday - tried to compare a custom user field (tried decimal, integer, text) to a geocoded field. The geocode filed outputs miles or km in distance....but I assume this is just a format and your patch compares raw values? Is this correct?
I also tried to create a math field in views, multiply the miles by *1 and the compare math field to my custom field, but math filed wasn't an option for comparisons. It sounds like I'm wanting to compare formatted values not raw, and your code is for raw?
Thank you
Comment #30
keyiyek CreditAttribution: keyiyek commentedFIXED
I apologize for my dumbness, but once the patch is applied, in the UI where do I find the options to make the comparison?
EDIT: I found the "global field comparison", now I have to understand why it says the handler is missing
EDIT 2: run update.php and way fine : )
Comment #31
rudiedirkx CreditAttribution: rudiedirkx commented@IWasBornToWin Yes, this patch compares raw values. Directly from the database. (Inside the database even.) There's also no way to reformat pre-comparison on the fly. That would require a query alter.
In case of date fields: if you always want to compare timestamps (int), you can create your date fields with that format. Date fields have 3 available formats I think.
About the patch: can someone test, review, verify & change status to rtbc?
Comment #32
IWasBornToWin CreditAttribution: IWasBornToWin commentedpatch works good.
Comment #33
JMOmandown CreditAttribution: JMOmandown commentedThere is an issue with pulling the fields through a separate sql query. This renders fields that are calculated in the view field after the initial query to throw an error. It would be better if the addition pulled the data value from the $row->data directly..
For example lets say you allow a user to view a gambit x number of times. Well the gambit only stores a value of the max number of views allowed. The field times viewed would effectively query the user and calculate how many times a user has viewed gambit. In this case, pulling the value from the row output would render the intended result. Under the current approach, you would get the following:
Comment #34
rudiedirkx CreditAttribution: rudiedirkx commented@JMOmandown What you want is even more advanced and could be seen as an edge case. I think the last patch handles most of the cases, which would be a great improvement. You could create another comparison field for more advanced comparisons. Agree? Disagree?
Comment #35
JMOmandown CreditAttribution: JMOmandown commentedWhile I do agree that it would require a great deal of structure change that arguably may not be worth the use case coverage, I don't think it is as far an edge case as you think. Comparing a value against a calculated value is pretty common among modules and would be as well among views if available.
The last patch does provide significant improvement! I may later, when I get sufficient time, delve into creating another comparison field for comparisons that steal the value from the view output and then filter (via ajax maybe) or at least a custom module as a place to start for others. However, I figured I'd bring up the procedural issue to you, who is much more familiar to the module, in case I was missing something.
Comment #36
rudiedirkx CreditAttribution: rudiedirkx commented@JMOmandown You mean the path from #22? Still all credits to @david.fzs, who created the module.
So, does is still need work?
Comment #37
el_toro CreditAttribution: el_toro commentedHi guys,
I'm trying to achieve the same thing, only that the left field is not being pulled from the database but rather is calculated based on some user input in an exposed views filter. Could someone tell me, theoretically, what I would have to do to achieve this.....
Thanks!
EDIT: Or i guess my question should be...how can I ignore the query process and do arbitrary calculations with the results of the left and right fields?
Comment #38
rudiedirkx CreditAttribution: rudiedirkx commented@el_toro You'll need
hook_query_alter()
orhook_views_query_alter()
to add custom conditions. Do aget_class($query)
to look up what methods it has in the api.Comment #39
el_toro CreditAttribution: el_toro commentedHi rudiedirkx, thanks for the quick response.
Now being naive to the ways of views, this is how I'm expecting this to work.
1. I have the filter exposed with grouped filters.
2. When I set $this->value['value'] = $x; I'm expecting that the numerical field will be evaluated against $x and if the condition (e.g. > 5) is not satisfied then the row will be removed from the results.
Am I totally in the wrong domain here, in trying to achieve what I want?
EDIT: support request and code moved here http://drupal.org/node/1972146
Comment #40
rudiedirkx CreditAttribution: rudiedirkx commented@el_toro This isn't the issue/thread/place for a support request like that. This issue is about a db field comparison filter. You should create a new issue (and remove the code in your last comment). You can send me the link so we can talk about it there.
Comment #41
IWasBornToWin CreditAttribution: IWasBornToWin commentedI assume this patch has never been committed to views? If I want to use latest version of views I need to reinstall patch after updating to latest views?
Comment #42
merlinofchaos CreditAttribution: merlinofchaos commentedThis patch is currently marked 'needs work' meaning that the community has deemed it not ready to be committed. This it not only hasn't been committed, but it won't be committed until someone is able to fix the patch (or remove the blocker that had it called needs work). The last move to needs work was in #33, so you should read that and the following comments to see what still needs to be done.
Comment #43
IWasBornToWin CreditAttribution: IWasBornToWin commentedThanks, I have zero knowledge on "fixing patches". Can I update to latest views and then reinstall the current patch that is working for me?
Comment #44
rudiedirkx CreditAttribution: rudiedirkx commentedWhat @JMOmandown requested was too edge case and since @IWasBornToWin rtbc'ed it before, it's now rtbc again. Patch in #22 should work fine.
Comment #45
dawehnerI like the fact that this is implemented in a way that it can't break any existing view, so I committed it. Thank you very much! One less issue tagged with views 3.x roadmap :)
Committed and pushed to 7.x-3.x
I will port this patch to drupal 8 which requires for example a good test coverage.
Comment #46
dawehnerFirst totally untested version for drupal 8.
Comment #47
rudiedirkx CreditAttribution: rudiedirkx commentedWhere does
FilterPluginBase
come from? Shouldn't there be ause
statement for that? (Technically maybe not if it's in the same namespace, but I think it's better to always explicitlyuse
your classes (even global/root classes), but I don't know Drupal 8's coding standards, at all.)Comment #48
dawehnerIt is in the same namespace already, so there is no need for the user statement.
Comment #49
tim.plunkettThis reminds me of DisplayPluginBase::getFieldLabels().
I don't know that this is more readable...
Comment #50
dawehnerThere we go, this time with a proper test!
Comment #51
tim.plunkettgreater, and I would put "is greater than" in quotes.
Otherwise, this is RTBC to me. And since its to maintain feature parity with D7, I'd call this a task.
Comment #52
Les LimIs it too late to consider also being able to compare a field against an argument value? I've drawn up a working patch against 7.x-dev to illustrate what I'm talking about, but haven't yet looked at what a D8 conversion would entail.
EDIT: it occurs to me that being able to compare fields to arguments isn't strictly necessary, since the same argument expression can also just be added to the view as a field. Nifty.
Comment #53
dawehner@Les Lim
This is a great idea in general, but please let us get this issue in drupal 8 first. Then we can backport the tests to be sure things still work.
Comment #54
Les Lim@dawehner: of course!
Comment #55
dawehnerThere we go.
Comment #57
dawehner#55: vdc-699252-55.patch queued for re-testing.
Comment #58
tim.plunkettThis is SO COOL and it has tests. And it keeps us up to date with D7
Comment #59
alexpottA couple of minor nits...
You're getting the right table and field field here... although I would argue that the code is expressive enough and the comment is superfluous.
Unnecessary empty line (only because I'm setting this back to needs work)
Comment #60
dawehnerComment #62
tim.plunkettFatal error: Call to a member function setDisplay() on a non-object in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/lib/Drupal/views/Tests/ViewUnitTestBase.php on line 222
The other is random.
Comment #63
dawehnerOh we recently moved the test modules to tests/modules ....
Comment #64
emkay CreditAttribution: emkay commentedI've tested this patch and all seems well. Screen shot attached.
Comment #65
R.Hendel CreditAttribution: R.Hendel commentedI have tested this patch with a few combinations of float- and text-fields and tried to compare single- with multiple-value fields.
In my conclusion this feature/patch works very well but you have to know some properties about its behaviour:
It works as expected and self-declaring if you compare single-value fields with each other. If you use text fields which contain html-markup you should consider, that it treats html as content: "
abc
" is less than "
"
If you compare a single-valued with a multiplevalued field with (e.g.) the condition "field left is less than field right", it will return TRUE, even if there is only one value in field right which is less than field left. In my opinion this is not a bug, but you must consider that this can lead to unexpected results.
If you compare two multiple valued fields with each other, the view will return one single record for each combination of having a less value in left field than in right field regardless of delta of field. E.g. you compare a field containting values "0", "1", "2" and "3" with "1", "2", "3" and "4" you will get 10 records as a result set.
So I think this feature works well, but is not advisable using with multi-instantiable fields.
P.S.
Before you can use fields to compare, you first have to select fields them. But that is normal views-behaviour.
Comment #66
damiankloip CreditAttribution: damiankloip commentedThis is looking good, and works nicely. Just a couple of things..
We could just replace this lot with an array_map, it's fine how it is though really.
This can use String::checkPlain()
Builds
Do you think we should test the less than, and less than or equal operators too?
Maybe this should be 'Compare two fields to filter the result of a view', Also, can't we just ditch having help in the base array and in the filter array, and just go with the base?
Comment #67
dawehnerAs you have to unset values, this makes it indeed harder to read.
There we go.
Comment #68
nicxvan CreditAttribution: nicxvan commentedI'm testing the patch in 7.x version and encountered a bug:
Not entirely sure this goes here or if I should change the version of the issue.
The use case I have in mind is check if a date on a node is between subscription dates set on a user.
I initially had one date field with an end date on the user, and checked to see that the subscription start was less than the node date. However when I checked to see if the node date was also less than the subscription end date I got no results. The test data is within the dates. I checked both configurations nodedate < subenddate and subenddate > nodedate but neither worked. I suspected that it was having trouble because the subscription was one date field so I separated it into two separate date fields.
However, checking against the first date works, but checking against the end date does not.
Even having the one filter on the end date returns no results.
Further testing both greater than and less than didn't return results.
I have a custom date format yyyymmdd and a sample of the data.
Node Date
20130529
Subscription Start
20130401
Subscription End
20140717
Plaintext version of the filter.
Subscription Start <= Node Date (Works alone)
Subscription End >= Node Date (Does not work)
Views export attached.
Comment #69
damiankloip CreditAttribution: damiankloip commentedLooks good, reviewed #67, and my previous points have been fixed.
Comment #70
nicxvan CreditAttribution: nicxvan commentedAfter further testing it's not checking the values, I have just the one compare fields filter checking that the date on the post is after the subscription start date and it shows all values ignoring the dates set on the nodes.
Comment #71
nicxvan CreditAttribution: nicxvan commentedAfter even further tinkering it was user error, date fields weren't set as plain text. Setting them as plain text allowed the comparisons to work.
Comment #72
alexpottI think we're missing the associated config schema.
Comment #73
dawehnerI am sorry but I had to fix the combine entry at the same time.
Comment #74
blattmann CreditAttribution: blattmann commented@keyiyek, I'm having the same problem you did. Where is the global field comparison?
Thanks!
EDIT: Okay, I found it myself. The field that needs to be added as a filter is "Global: Fields comparison", not the fields you want to compare.
Thanks for all the work everyone has done on this!
Comment #75
haydeniv CreditAttribution: haydeniv commentedJust tested #73 on simplytest.me and checked "Global: Fields comparison" and then tried to "Add and configure filter criteria" and the spinner popped up for a second and disappeared but nothing happened.
Firebug says:
Comment #76
dawehnerThank you for the manual testing ... this time this should work.
Comment #77
damiankloip CreditAttribution: damiankloip commentedI don't think it makes sense for this filter to have groupBy enabled?
Comment #78
dawehnerGood catch.
Comment #79
damiankloip CreditAttribution: damiankloip commentedNot a part of this patch, but would be nice to tidy up how we deal with operators in filters, as it's generally all over the place.
Otherwise, I think this patch is good to go now.
Comment #80
haydeniv CreditAttribution: haydeniv commentedDon't know if head is just broken right now because I had some issues with the installer but this is what I am getting right now when trying to compare fields.
Steps to reproduce:
SimplyTestMe Standard install
Try to edit the People View.
Try to Add a Global Compare field.
Comment #81
dawehnerGood catch, thank you!
Comment #82
haydeniv CreditAttribution: haydeniv commentedThe latest patch address the notice that came up in my testing and I tested against member for and last access which are date fields that had issues in the past that seem to be resolved now as well. Setting this back to RTBC as it was before I found my error and it looks like all other issues have been addressed. If bot is green, I think good to go.
Comment #83
Xano#81: vdc-699252-81.patch queued for re-testing.
Comment #84
Xano#81: vdc-699252-81.patch queued for re-testing.
Comment #85
alexpottThe issue exposed by #80 shows that there is untested code being added by this patch. The UI form being added needs to be tested by a WebTest.
Comment #86
dawehnerWe are all friends ...
Comment #88
dawehner#86: vdc-699252-86.patch queued for re-testing.
Comment #89
dawehnerLet's see whether it still applies.
Comment #90
Bojhan CreditAttribution: Bojhan commentedThis looks nice, lets get it in :)
I sadly can't get the actual D7 patch to work, has this been tested? Because it doesn't work as a contextual filter, therefor you can't actually do the use case described in the summary. Of depending what page you are on filtering the list. I am for example comparing two date fields, to show the files of only that day. These are two different content types.
Comment #91
jibranSome minor suggestion.
I don't think hyphen is required here.
I don't think we can mix these two yet.
Extra white space.
Comment #92
damiankloip CreditAttribution: damiankloip commentedAs nitpicking is already happening, Full stop.
Aside from that, I think this is ready to go.
Comment #93
bohemier CreditAttribution: bohemier commentedWonderful! Thanks to all patchers and testers, this is excellent work.
Comment #94
gilsbert CreditAttribution: gilsbert commentedHi.
May this feature be backported to D7?
Regards,
Gilsberty
Comment #95
dawehnerFixed the reviews!
@gilsbert
Feel free to try out the dev version.
Comment #97
gilsbert CreditAttribution: gilsbert commentedI'm a rookie and it might be real simple to fix but I could not test the patch because views is not in core in D7.
I tried to find a way to replace /core for /contrib/views but I believe D7's views has a different directory structure...
Anyway, if the patch can be backported I'm a volunteer to test it out.
Regards,
Gilsberty
Comment #98
dawehner@gilsbert
Better read https://drupal.org/node/699252#comment-7513087
Comment #99
gilsbert CreditAttribution: gilsbert commentedHi.
ouch!!!!
I did not read the full thread.
I'm sorry for my stupid mistake.
Yes the D7 dev version of views has the "global: field comparison" filter working like a charm.
Thanks.
Gilsberty
Comment #102
dawehnerJust a start of a reroll, the patch though is still broken from a functional perspective.
Comment #104
klabautermann_ CreditAttribution: klabautermann_ commentedWorks for me on comparing two date fields.
Comment #106
dawehnerLet's fix the actual patch
Comment #108
LendudeThis should probably check isComputed() on the field handler once #2349465: Add an isComputed method to field handlers is in, or clickSortable() like the combine filter currently does. The new compare filter currently also throws a SQL error then using complex/dummy fields.
Comment #110
Grayside CreditAttribution: Grayside at Phase2 for Norwegian Cruise Line commentedComment #113
GAMe CreditAttribution: GAMe commentedHi Guys,
Sorry if this is slightly off topic but I have been trying to use this filter in views for D7 to compare 2 paths (Commerce Display Path and Node path) I set both fields to rewrite as node/1 etc so they were formatted the same however the filter just isnt working. Am I missing something or does this not work with rewritten fields? I cant seem to find any documentation on this filter. Whatever I find to resolve my issue though im definitely going to blog/write about it as its been a tricky one.
Any help would be great
Thanks
Comment #115
daggerhart CreditAttribution: daggerhart commentedRe-rolling this patch against 8.4.x.
Difference:
- Line number & short-array syntax change in views.views.inc
Comment #117
daggerhart CreditAttribution: daggerhart commentedAttempting to fix the test.
Comment #118
daggerhart CreditAttribution: daggerhart commentedAnother attempt at re-rolling the 105 patch for 8.4.x and fixing the test... feeling good about this one.
edit: nvm, I give up. patch works great for me, no clue how to fix the test.
Comment #120
tacituseu CreditAttribution: tacituseu commentedComment #121
daggerhart CreditAttribution: daggerhart commentedThanks @tacituseu!
Patch applies cleanly. Tested with various fields and relationships.
Comment #122
tacituseu CreditAttribution: tacituseu commentedComment #123
tacituseu CreditAttribution: tacituseu commentedBack to needs work per #108.
Comment #128
W01F CreditAttribution: W01F commentedThought it was probably a longshot - but tried patch #120 on 8.8-beta2 and it couldn't apply ><. Looking forward to this one though!
Comment #129
jonathanshawComment #130
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedHere is re-roll of patch #120
Comment #132
jonathanshawComment #133
vacho CreditAttribution: vacho commentedI think that this feature can cover the case where field A and B have multi values | field A or B have single value Vs another field comparison have multi values. I mean a "IN" "NOT IN" relation should be cover here. This is covered?
Comment #135
AnybodyReally important issue and great work! Thank you all! Just ran into this.
@vacho is right, the functionality should also support comparison on multi values. Currently it does NOT support that, see the following code in the patch:
So I guess we need to add logics for value sets:
And vice versa (or perhaps not, you can simply switch fields).
Comment #136
lolcode CreditAttribution: lolcode commentedI have been following this one for a while and would love to see this feature implemented. Therefore if this is getting close IMHO I would like to see the extra features in #133 and #135 postponed to a separate issue.
Comment #137
jonathanshawComment #138
thomasmurphy CreditAttribution: thomasmurphy at Xequals commented#89 and #120 see like good progress, it's good to have an applyable patch for a subset of functionality even if it's not stable in all circumstances. What's the rationale behind having https://www.drupal.org/project/drupal/issues/2349465 as a dependency?
Comment #140
nattyweb CreditAttribution: nattyweb commentedApplied patch at #120 on Drupal 8.9.13 and it did exactly what I needed - comparison of two fields as a filter. Very valuable, thank you.
Comment #141
liquidcms CreditAttribution: liquidcms commentedJust thought i'd throw this out there; but how difficult is it to have this work on re-written / processed field rather than just the base field as stored in the db?
My current example of this is trying to compare a date field to the created date of an entity. The date field (date range) stores the data in the db as YYYY-MM-DD whereas entity created property is stored as a timestamp. It is easy to get the date field to display as a timestamp; but the comparison is only done on the db stored value.
Beyond my case i would have to assume the uses cases on processed fields far exceeds those on unprocessed.
Comment #144
tce CreditAttribution: tce commentedApplied patch at #120 and worked pefrectly for me. Thanks.
Comment #146
abx CreditAttribution: abx commentedTested patch #120 with Drupal 9.3.15 and works to compare between fields.
Comment #147
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedFixed Drupal CS issue of patch #130.
Comment #148
RassoniFixed Drupal CS issue of patch
Comment #149
RassoniComment #150
RassoniFixed custom command failed.
Comment #154
mohithasmukh CreditAttribution: mohithasmukh commentedHi there,
#150 patch not working on 9.5.8 core. Keeps failing. Could someone help out please?
Thanks.