- **status**: review --> in-progress
- **Comment**:
This doesn't work for me. To test it properly you should disable caching
inside `def can_merge`, like this:
~~~~
+# if cached is not None:
+# return cached
~~~~
This way task will be fired on every page hit.
I think to properly fix this we should set `skip_mod_date == True` in the
beginning of the `repo_tasks.can_merge` and set it back to `False` in the end.
Maybe it can even go inside `set_can_merge_cache()`, so that no matter from
which place cache is updated it will not trigger `mod_date` update.
Also, we should consider adding context manager helper for this to the Allura,
similar to one we use in SF internal code:
~~~~
@contextmanager
def skip_mod_date(model_cls):
skip_mod_date = getattr(session(model_cls)._get(), 'skip_mod_date', False)
session(model_cls)._get().skip_mod_date = True
try:
yield
finally:
session(model_cls)._get().skip_mod_date = skip_mod_date
~~~~
---
** [tickets:#7894] Don't update merge request timestamps incorrectly**
**Status:** in-progress
**Milestone:** unreleased
**Labels:** merge-requests sf-2 sf-current
**Created:** Tue Jun 09, 2015 08:44 PM UTC by Dave Brondsema
**Last Updated:** Tue Jun 16, 2015 11:39 AM UTC
**Owner:** Heith Seewald
Merge request's "updated" timestamp changes when you view it and it calculates
if a one-click merge is possible. That shouldn't happen. Make sure no other
operations incorrectly update the timestamp either.
---
Sent from forge-allura.apache.org because [email protected] is subscribed
to https://forge-allura.apache.org/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
