Closed (outdated)
Project:
Tour
Version:
2.0.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
19 Feb 2013 at 12:15 UTC
Updated:
17 Sep 2024 at 18:30 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
nick_schuch commentedHere is a patch that adds permissions to tips (and test coverage). It sets up the following:
1) Automatically adds a permission per module that implements a tour.
2) Tour module now has a "View all tips" (same approach as nodes modules "View all content").
3) Modules can also add in there own permissions and assign them to the tip like so:
This now means that modules can provide tips to varying levels of user base. While I don't see this as being required in our core tip implementations (we should keep them as simple as possible). I do see this as a big deal for contrib.
Comment #2
larowlanthese can be in one if imo
Correct me if I'm wrong but this permission would show up in the 'Tour test' module section in the permission ui whilst the other permissions would show up in the tour module permissions section. I think we would also get a 'view tour_test tips' permission too - so which wins in that case? Looking at the code I can see the permission defined by the module wins, but that isn't clear to the user from the permissions ui.
Can this be cached (in memory), one module might define two tours - no need to parse the info file twice.
This means this code runs on every page now, not sure if that is desirable, or if we can get around it.
Comment #3
nick_schuch commentedThanks larowlan.
I will do the following:
1) Consolidate the if statement.
2) Basically this would provide specific permissions for a specific few tips within a tour. Think of it like a "View expert views ui tips". I will update the test_module for the permission to read better.
3) Ill take advantage of this: drupal_container()->get('keyvalue')->get('system.schema')->getAll() (keeping in mind that this is now service::).
4) Im not sure how to keep this simple either. I guess in the end we have to check for which users can access what tips.
Comment #4
oresh commentedComment #5
nick_schuch commentedThe following patch fixes the items identified by @larowlan in #3.
Comment #6
nick_schuch commented#5: 1921144-5-tour-tip-permission.patch queued for re-testing.
Comment #8
nick_schuch commentedRerolled vs current HEAD.
Comment #19
ridhimaabrol24 commentedComment #20
ridhimaabrol24 commentedRerolled patch for 9.1.x!
Comment #22
hardik_patel_12 commentedFailed tests are because of undefined method user_access().
user_access() replaced with a method on the user/accountInterface, kindly see Change Record.Solving failed test cases. Kindly follow a new patch.
Comment #30
quietone commentedThis extension is being deprecated, see #3336033: [Meta] Tasks to deprecate Tour module. It will be removed from core and moved to a contrib project, #3376099: [11.x] [Meta] Tasks to remove Tour.
This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
Comment #31
smustgrave commentedWorth exploring.
Comment #32
smustgrave commentedComment #33
smustgrave commentedTalking to @thejimbirch and @rkoller and this doesn't seem like something we need in tour contrib.