[#6410] - Added a method to make JAssetRules responsible for its own storage
- Closed
- 28 Sep 2015
- Medium
- Build: staging
- # 6410
- Diff
- Mathewlenning:JAccessRules
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
Something like this would allow us to pull all the JTable::getInstance('asset') dependencies out of the components.
I also added self cleaning, so we aren't writing null values as denied.
joomla-cms-bot
- | Labels |
Added:
?
|
||
zero-24
- | Category | ⇒ | Libraries |
@compojoom Sorry for the delayed response.
The exact use case that this current implementation addresses is in the com_config models, but I'd also like to remove the ref in JTable.
If we look at the code, before saving the rules we always call the JAccessRules class, push the rules array into it, call JTable::getinstance('assets'), bind the rules to the table, then store the rules.
Which IMO requires classes that handle ACL storage to have too much knowledge of the ACL system.
So hiding the details behind the JAccessRules interface will make it easier to maintain ACL without refactoring classes that use it.Does that make sense?
This is how it is meant to be used.
$rules = new JAccessRules();
$rules->storeRules('com_content', $data['rules']);
// We don't need this anymore
unset($data['rules'])The JTable implementation is a little more complex (as it fixes parent/child relationships), but I'm working on a solution too.
Joomla isn't ready for this yet. I'll close it for now and when the core is cleaner I'll revisit it.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-09-28 01:59:23 |
| Closed_By | ⇒ | Mathewlenning |
Hey Matthew!
Could you please explain what your use case exactly is & how we can test this?
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/6410.